Re: What's queued for 2.6.24

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

On Sun, Sep 23, 2007 at 07:24:08PM -0700, Kristoffer Ericson wrote:
> On Sun, 23 Sep 2007 19:02:42 +0200
> Sam Ravnborg <sam@xxxxxxxxxxxx> wrote:
> > Hi rmk.
> > > 
> > > Merged and pushed out.  However, there's still things I'm not too happy
> > > about in your patch.  I merged it anyway because I didn't want you to
> > > wait another three months until the next merge window opens.
> > > 
> > > (Let me say now that I think mainline folk are utterly misguided by *now*
> > > requiring git tree owners to merge their work during the first few days
> > > after the merge window opens.  As has just happened, the result of this
> > > policy is that I've now merged code which I'd actually prefer to have
> > > another spin.)
> > 
> > The subsystem maintainers needs to secure quality of the
> > code they request merged. What we have now is just a time-window
> > for the git treies that are a few weeks before the mainline window.
> > The only difference is that the mainline merge window gets far
> > more publicity than the individual subsystem 'merge' windows.
> > 
> Since there is a timeline, Russells choices atm are either to merge
> non-100% code or let all code wait three months.
And why do you beleive this code is getting any better waiting two weeks
before hitting Russell's tree?

It seems that some people in ARM land fail to understand the process.
For each kernel release there are a merge window of two weeks, and
people sending in stuff via gti-trees (like I and Russell does) are
suppsoed to send in the "please pull" within the first week.

So this is getting simple. If Russell shall have any way to
secure just a decent quality he put demands on his controbutors.
Translated "merge with Russell around -rc5".

And there are ONLY this merge window per. relase so when you

> Of course the contributor should have submitted it earlier so
> it had more chance of getting in, but I still think that
> sub-maintainers should get another chance after the initial
> merge window. If stuff is 99% ready to be merged, it seems
> silly to have to wait 3 months.

You say in other words that you had not understood the process.
And if sub-maintainers cannot get the stuff finished for -rc5
then again I see no reason why they suddenly can fix it up by

To repeat: There is only a single merge window. And that merge
window is one week for git users. And the merge window are not
for final development - that border was passed roughly at -rc5.
Simple - yes?


List admin:

[Site Home]     [Linux Arm]     [Fedora ARM]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [PDAs]     [Linux]     [Linux Book List]     [Linux MIPS]     [Yosemite Campsites]     [Photos]

Powered by Linux