gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] GCC v. Arch address@hidden: Regressions on mainline


From: Tom Lord
Subject: Re: [Gnu-arch-users] GCC v. Arch address@hidden: Regressions on mainline]
Date: Wed, 23 Jun 2004 12:16:37 -0700 (PDT)

    > From: Colin Walters <address@hidden>

    >> Yes, I think you hit an inside-the-park home run with pqm.

    > Thanks.

It sounded silly and improbable to me when I first read about it but,
obviously, it has utility.


    > > I.e., we have some running to do to make it real (a feature here or
    > > there, etc.)

    > Anything in particular?

Polish, some basic configurability and security features, and bundling
with arch.   For something like GCC, integration with higher-level
tools for personal-archive and project-tree management including
making it easy to form new branches, have pqm mail sent to the right
places automatically, be able to quickly and easily reconfigure on the
occaision of things like upstream version or revision cycling, the
ability to signature check messages to the pqm before acting upon
them, finer grained access control w/in pqm based on known signatures
and associated rights, teaching it more merge techniques and making
those nicely configurable.....


    > > The PQM idea is simple enough (reimplementable enough) that I doubt
    > > any current implementation will be recognizable as the ancestor of
    > > what eventually we bundle with tla.  But you demonstrated this
    > > important idea and gave us a nice handy name for it.

    > I would be very interested in further tla integration.  A command like
    > "tla submit-merge" or the like would be handy, at least.

Right, that's (the kind of thing) that some of the FEATURE PLANS are
aimed at.

The ideal command set for contributors to established projects is
probably just something like:

        fork            (make local archives/branches)
        get
        checkpoint      (local commit)
        pull            (merge from upstream)
        push            (submit to upstream)
        status          (general reporting of what's going on)

("status" being a place-holder for probably several different
commands, the others being close to literal commands.)

-t






reply via email to

[Prev in Thread] Current Thread [Next in Thread]