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

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

Re: [Gnu-arch-users] Re: gnuarch 1.2.1 released! (reannouncement)


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: gnuarch 1.2.1 released! (reannouncement)
Date: Mon, 16 Aug 2004 11:31:09 -0700 (PDT)

    > From: Miles Bader <address@hidden>

    > Aaron Bentley <address@hidden> writes:
    > >> Does Tom's devo branch contain all these changes?  I'm personally using
    > >> a branch tagged off of "address@hidden/tla--devo--1.3".

    > > No, but Blackwell's tla--devo--1.3 branch contains all Tom's changes. 
    > > You can use apply-delta to switch.

    > Is there any particular plan for the future relationship of these
    > branches (Tom's and James'), and the bug system?  If James is likely to
    > do most of the bug merging in the near future, his branch would seem the
    > best to base my branch on (so that any bug fixes I send will merge
    > easily), but really I have no idea what's going on behind the scenes at
    > arch central... :-)


James' branch (and his role) is supposed to be a temporary hack.

Asuffield's voting-based pqm is supposed to replace jblack and
jblack's branch.  Jblack is replaced (in his role as branch
bookkeeper) by PQM scripts.  The archive the PQM owns replaces
jblacks'.

When asuffield's branch comes on line, asuffield, abentley, jblack,
jivera, lord, and rbcollins will have (voting-mediated) commit access
to that branch.

At that point, the PQM-managed branch will become the development
branch for FSF releases.  The FSF maintainer (me, in this case) has a
little bit of absolute release-management authority, but mostly it
will be a team-maintained project at that point;  overall that's a lot
like the way that GCC works.

In the meanwhile, if you are very anxious and don't mind risking
getting tangled up, you could branch from Jblack.   If you want to be
a little more cautious, branch from address@hidden and wait a few more
hours for me to catch up to jblack.   

(Incidentally, there is some value to this delay:  should any "fires" 
show up in the release, at least the FSF series of releases is
buffered against that.)

-t





reply via email to

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