Post-RC1 merging criteria (was Re: [PULL] cleanups)

[Peter Hutterer]

On Tue, Jun 22, 2010 at 08:36:04PM +0300, Vignatti Tiago (Nokia-D/Helsinki) wrote:
> On Tue, Jun 22, 2010 at 04:21:42AM +0200, ext Keith Packard wrote:
> > On Mon, 21 Jun 2010 16:04:51 +0300, Tiago Vignatti <tiago.vignatti at nokia.com> wrote:
> > 
> > > The problem is that people are creating patches but they got lost somewhere
> > > and/or take so many time to go upstream.
> > 
> > Am I still dropping patches on the floor somehow?
> 
> I don't think so. You've been doing the work pretty good in my opinion. 
> 
> But I'm mostly worried with patches not related with bugfixing, that will
> appear while we're in the huge bugfixing time-frame. I'll discuss bellow...
> 
> 
> > > In my opinion, reducing the release schedule now would improve the throughput
> > > of patches going in. Probably three months for the whole release would be
> > > better with the majority of time being gates opened for merge window - two
> > > months maybe?
> > 
> > Daniel's point here is that a shorter release cycle will increase the
> > number of releases that we as a community need to maintain as upstream
> > and in distributions. Having to do security updates for one release is
> > hard enough, having to do them simultaneously for many releases would be
> > even harder.
> 
> Right, seems developers are opposing to shorten the release schedule time and
> I perfectly understand the reasons. Mostly surrounds the goal of regular
> vendors that needs to keep a big range of devices working (almost all Linux
> distributions), which means big time to stabilize all drivers and, mainly,
> support them after X is released. On the other hand, MeeGo-like distributions
> supports just a few devices and can quite easily "follow the shiny",
> paraphrasing Dave. Different goals within the same product :/

> Even so, our problem remains: while we'll be living inside these three months
> of bugfixing phase, patches will come to the list, reviewing will be made and
> very few patches are going to be queued on developers' trees. Mostly will be
> floating in the list for _three_ _huge_ months.

well, this is what should be fixed then, right? have maintainers to take the
patches into their trees.

> I can consider two options that fits for me while we are in this bugfixing
> mode: either a xserver-meego or a xserver-staging.
> 
> - xserver-meego would be what I particularly care for MeeGo devices in a near
>   future.
> 
>   Could be my work or any other patches floating in the mailing list that I
>   care. When the upstream merge window opens, I will definitely want to merge
>   this tree there (by any chance we want a fork!).
> 
>   I'm the only one committing there and I'd be selfish because other parallel
>   works that I don't care won't be applied there.

well, this is a distribution tree. which all distributions already
have. And one of the things with distribution trees do is they generate a
lot of pain once you start shipping things that don't go upstream.
That pain won't be today or tomorrow. But have fun forward-porting all those
patches that didn't go into 1.9 for a 1.10 server, then a 1.11 server, then
a 1.12, etc.

My point here is that you _will_ need a meego tree. but patches applied
there should be the exception and meego-specific only, and that's in your
best interest.

> - xserver-staging would be a tree for everyone interesting in development
>   while upstream are in bugfixing. This tree (well, -meego also) stays opened
>   only when the merge window is closed.
> 
>   The administrators of -staging would pull basically *everything* reviewed in
>   the mailing list there. Besides pulling minor patches, any developer with a
>   given work that is ready to be merged upstream (Keith's tree) and it doesn't
>   fit as "fix", is encouraged to push there.

where do we take the administrators for staging from?
we're running out of manpower as it is, opening another tree that's
centrally managed won't help much. we could abandon the idea of personal
trees to free up manpower but at least for my area I find it immensely
useful to see and test most patches, it allows me to stay on top of what's
happening.

>   When upstream open the gates again, we sync both trees and close -staging.
>   This tree should aid Keith only, so the "sync" part should be done very
>   carefully. For instance, I'm not sure that a single pull req on the
>   beginning of the merge window is enough because Keith would be overloaded.
> 
>   One single guy running it won't make sense. For instance Jamey, Mikhail and
>   other guys running fast development could use / administrate the same tree.
> 
>   It resembles just in a bit the linux-staging. It resembles a bit also the
>   idea of swap RMs in each versioning, which now would be sort-of 3 months.
> 
>   There would be more people working, thus more confusing. In general is more
>   complex also.
> 
> 
> xserver-meego will not solve the issue of floating patches at mailing list,
> while xserver-staging solves. xserver-meego requires less work from me.
> xserver-staging requires more work from me and will be successful only if
> there would be a real collaboration between developers. Real consumers, i.e.
> people testing, is by far not the goal of both trees. The goal is to fasten
> development while upstream stays in freeze mode.

So the thing is - with git you don't need permission to start a staging
tree. You can just keep it as -staging in your $HOME for a release cycle and
see how we go. but I think it'll require a lot of time for maintainance and
once you get started with it, you'll notice you dont have a lot of time
writing the patches that the tree was created for in the first instance ;)
 
Cheers,
  Peter