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

[Vignatti Tiago (Nokia-D/Helsinki)]

Hi,

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.

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.


- 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.
 
  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.


What you think?

                    Tiago