Re: [Gnu-arch-users] [ANNOUCEMENT] gnuarch-1.2.2rc2 release

[Tom Lord]

All that's great. 

Mostly I want to emphasize this:

In theory, I have the right to raise a red flag and interrupt the
co-maintainer process.

I have no intention of doing that in any serious way if things
continue roughly along the current lines (though I expect steady,
incremental improvements to the quality of the process).

So: the primary accidental failure mode here is if we have a
disconnect --- if I appear to be blowing off the process when, really,
I don't intend to.

So: should it appear I'm missing some point -- please make the
first...third order attempts to sync with me (through any of our many
channels of communication) before deciding to toss me overboard. 
So to speak :-)

I.e.: I *am* using ancient email software;  I *am* very busy these
days; etc.   If I miss a GNU maintainer cue -- odds are it is a
correctable accident rather than a cause to go apeshit on me.

Thanks,
-t




    > X-42-Pre-Check: Attempted
    > Date: Fri, 10 Sep 2004 18:17:00 -0400
    > From: address@hidden (James Blackwell)
    > X-BeenThere: address@hidden
    > X-Mailman-Version: 2.1.5
    > Precedence: list
    > List-Id: a discussion list for all things arch-ish 
<gnu-arch-users.gnu.org>
    > List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/gnu-arch-users>,
    >   <mailto:address@hidden>
    > List-Archive: <http://lists.gnu.org/pipermail/gnu-arch-users>
    > List-Post: <mailto:address@hidden>
    > List-Help: <mailto:address@hidden>
    > List-Subscribe: <http://lists.gnu.org/mailman/listinfo/gnu-arch-users>,
    >   <mailto:address@hidden>
    > Sender: address@hidden
    > X-Spam-Checker-Version: SpamAssassin 2.64-42mail (2004-01-11) on 
    >   mail.42inc.com
    > X-Spam-DCC: sgs_public_dcc_server: mail 1199; Body=2 Fuz1=1 Fuz2=2
    > X-Spam-Status: No, hits=-3.5 required=4.5 tests=AWL,BAYES_00 
autolearn=ham 
    >   version=2.64-42mail
    > X-42email-MailScanner-Information: Please contact 
http://www.42inc.com/support.html for more information.
    > X-42email-MailScanner: Found to be clean
    > X-UIDL: d7b0b850b840dca96365e6274fb8678b
    > 
    > 
    > jblack wrote:
    > >> I have just cut and released 1.2.2rc2. This release candidate fixes a
    > >> 1.2.1 regression that caused get-changeset to refuse get-changeset.
    > >> Thanks goes to Aaron Bentley who stayed up extra late to fix it.
    > 
    > -t wrote:
    > > Could you please be a little bit more proactive about alerting me to 
    > > the impact of such things on making GNU releases?
    > 
    > I intended to. Real life stepped in just after I had mailed the list,
    > but before I could mail you. You'll get a private email from me on the
    > same day an rc comes out. Promise. ;)
    > 
    > > For example, I was assuming we were counting down two weeks from
    > > 1.2.2rc1 before I was supposed to either make a release (expected
    > > case) or raise a red flag (unlikely but that's part of what I'm there
    > > for).
    > 
    > We were, but now that rc2 came out today, the clock restarts, and now
    > I'm hoping for a Sept 24 release. Though it may seem silly to throw away
    > three days of testing time just for one lousy patch, its a consistant
    > process so that everybody's on the same page, that makes sure that
    > anything that goes out as an official release had a fair shot at
    > testing.
    > 
    > > Now I'm a little confused where I should be in my part of the process,
    > > in your view.  I gather the clock is slightly reset by rc2 but I'm not
    > > sure precisely what the co-maintainers' expectations are regarding the
    > > status of their work in relation to GNU releases.....
    > 
    > You can review the rc at any time you like, but I suggest you give
    > everyone ~ a week to catch the obvious stuff. After a week (7 days +- 1
    > day), I'll send you an email with a subject along the lines of "RC 1
    > WEEK OLD". At that point, I recommend you figure out when during the
    > next week that you can audit the code.
    > 
    > As with always, if anybody finds an rc regression, we'll either A) pull
    > the regressing patch or B) fix the regression. Then, I'll cut a new rc
    > and the clock starts over. 
    > 
    > If we find a bug during the rc process, that goes straight into the
    > development line, but doesn't go into the rc process. Instead, it'll
    > wait for the next rc, which will be coming along in about 2-3 weeks. As
    > with anything, there *can* be exceptions. If a really horrid bug comes
    > along, then I can be convinced to pull it into the rc, and treat it as
    > if it were an rc regression.
    > 
    > Btw, you're eligible for the prize too. If you find an rc regression and 
    > spend 20 minutes hacking up a test case and fix, then you get to have
    > a night out at the movies on someone else's tab. 
    > 
    > The day before release (sometimes two if real life causes me to have to
    > postpone release by a day) I'll send you an email with a subject along
    > the lines of "IMMINENT FULL RELEASE for x.y.z"
    > 
    > 
    > -- 
    > James Blackwell          Try something fun: For the next 24 hours, give
    > Smile more!              each person you meet a compliment!
    > 
    > GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400
    > 
    > 
    > _______________________________________________
    > Gnu-arch-users mailing list
    > address@hidden
    > http://lists.gnu.org/mailman/listinfo/gnu-arch-users
    > 
    > GNU arch home page:
    > http://savannah.gnu.org/projects/gnu-arch/
    > 
    >