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

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

Re: [Gnu-arch-users] Re: File naming conventions


From: Thomas Lord
Subject: Re: [Gnu-arch-users] Re: File naming conventions
Date: Wed, 27 Oct 2004 14:59:18 -0700 (PDT)

    > From: Miles Bader <address@hidden>

    > On Mon, Oct 25, 2004 at 01:34:20PM -0700, Thomas Lord wrote:
    > >     > It seems like a huge mess to me...  E.g. what's the status of all 
the
    > >     > stuff merged into the "prerelease" by James -- and the 
corresponding
    > >     > bugs closed?  Does all that have to be re-submitted now?  Where?  
How?
    > >     > When?  [What?]

    > > Yeah, 1.2.2 crashed and burned.  Get over it.   Certain persons may have
    > > given the mistaken impression that they had a lot more to say about
    > > design decisions than they do and more than they should --- but we're
    > > mostly past that, now.

    > Er, yeah, OK, but could you give a brief answer to the questions above?

    > I presume that we have to re-submit everything?


The plan is to create a testing candidate release next week with just
a few key changes in it.   This candidate certainly won't have every
change that went into 1.2.2.

The priorities after that testing candidate, apart from any new
regressions it reveals will be driven to some extent by community
energy and to a lesser extent by what Matthew and I feel like working
on.

When I say that priorities will be driven by community energy, here is
what I mean: 

I expect that people will grouse that this or that change in 1.2.2
isn't in there yet or that this or that issue hasn't been fixed.  It's
a little bit hard, from my perspective, to sort out which are the
serious complaints from which are the trolls and casual flames.  There
are a fairly large number of change submissions (as opposed to just,
say, bug reports) --- yet, I'd like the quality standards for merging
changes to be a bit higher than they have been recently, and the
review requirements to enforce those standards divided by the amount
of available labor gives a bandwidth limitation on the rate at which
submitted changes can be processed.

To make the best use of whatever review and integration bandwidth is
available, I'd like to ask the cooperation of change submitters in
making the life of reviewer/integrators easier.  By asking each
submitter to do a /little/ bit more work, hopefully the
bandwidth-limiting review/merge process can be a /lot/ more efficient.

The best way I can think of, right now, to make the job of our
singular reviewer/integrator (Matthew) easier is to ask contributors
to be very strict and formal about the format and management of their
submissions.   Matthew should be able to "mirror the archive and view
the changeset" at the push of a button, and so forth.   He shouldn't
have to decipher scribbles describing what kind of hairy merge to
perform to get the changes.  He shouldn't have to spend hours chasing
around after people to sign their archives and so forth.   He
certainly shouldn't have to spend an hour resolving trivial conflicts
that arose because the submitter hasn't updated his submission for
three weeks.

Hence, the process document I posted:  casual submission branches and
cascades please.  

As for the resubmission process: let's take that up upon the release
of the first 1.3 testing candidate.   We'll make it as easy as
possible.

-t






reply via email to

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