review / comments / merge protocol

review / comments / merge protocol

[Daiane Angolini]

It was not the first time that one merge was considered "too fast", and 
that other one was considered "too slow".

In fact, we do not have a protocol, so, it was not "too fast" or "too 
slow".

I know protocol may be boring. But, I believe some formalism can avoid 
misunderstood.

One week after meta-fsl-arm dylan announcement I will sent a protocol 
proposal. And I will give 2 weeks for voting and discussion. I believe 
we need at least 10 participants in the discussion for the protocol aproval.

(do we have 10 active members in the ML?)

If you disagree we need a protocol, it's time to say it. With no 
protocol, nothing can be considered "too slow" or "too fast" because 
there is no way to measure it.

If you have any protocol idea, please, let me know. I will study the 
review/merge protocol used in kernel, u-boot and yoctoproject, and adapt 
it to our "reality".  But if you have an "easier" protocol, it's time to 
say it.


Regards,
-- 
Daiane

Re: review / comments / merge protocol

[Eric Bénard]

Hi Daiane,

Le Thu, 11 Apr 2013 10:33:01 -0300,
Daiane Angolini <daiane.angolini@freescale.com> a écrit :
> It was not the first time that one merge was considered "too fast", and 
> that other one was considered "too slow".
> 
> In fact, we do not have a protocol, so, it was not "too fast" or "too 
> slow".
> 
> I know protocol may be boring. But, I believe some formalism can avoid 
> misunderstood.
> 
You don't have a protocol but most open source projects doing time
based releases are following a similar release cycle (see at the
end of this mail for a summary of some projects I'm using on a regular
basis).

> One week after meta-fsl-arm dylan announcement I will sent a protocol 
> proposal. And I will give 2 weeks for voting and discussion. I believe 
> we need at least 10 participants in the discussion for the protocol aproval.
> 
> (do we have 10 active members in the ML?)
> 
> If you disagree we need a protocol, it's time to say it. With no 
> protocol, nothing can be considered "too slow" or "too fast" because 
> there is no way to measure it.
> 
> If you have any protocol idea, please, let me know.

- there is a mailing list for patch review : peoples with commit right
  could allow ML subscribers the time to review and test the patches
  sent, else it's even not necessary to post the patches to the ML you
  can commit directly as no discussion is permitted. One week seems
  reasonable for version changes or removal or big recipe reworks in
  order to be able to do real tests, for small fixes maybe one
  tested-by is reasonable before the commit.

- there is a mailing list for discussions : it can be used to discuss
  about the versions targeted for the release and the real need to get
  the latest one which is due to be released a few days before Yocto's
  release vs the previous one which is obviously the most tested on
  real hardware.

- the stable release occurs only every 6 months, so at least during the
  3 or 4 weeks before the release I think we should freeze the versions
  and only get bug fixes so that the release can be as stable as
  possible (not only on the autobuilder point of view but also on the
  targeted hardware) and this allows peoples to get time to do real
  tests on the targeted hardware. Moreover this allows people having
  layers based on meta-fsl-arm to be able to also stabilize their
  layers without risking to get a version removal / change a few days
  before the release which will break their bbappend and their patches.
  Of course, a next branch can be opened during the freeze period so
  that new patches can be applied there for the next release.

> I will study the review/merge protocol used in kernel, u-boot and yoctoproject, and adapt 
> it to our "reality".  But if you have an "easier" protocol, it's time to 
> say it.
> 
Of course we don't need to reinvent the wheel so here is a summary with
links if that can help you :

* u-boot :
	http://www.denx.de/wiki/U-Boot/ReleaseCycle
	- fixed release very 3 month
	- ~2 weeks of merge window (patches are reviewed on the ML and
	there are custodian who take care of specific parts of the
	project)
	- after the merge windows closes : "no new features may be added
	to allow for a release candidate phase which is intended to fix
	bugs and regressions"
	http://www.denx.de/wiki/U-Boot/DevelopmentProcess

* barebox : http://barebox.org/
	- release every month
	- 2 branches : master / next
	- master gets fixes, next get other patches after ML review
	- each month master is tagged as a release and next is
	merged into master for preparing the next release which means
	there is one month to stabilize it

* Linux :
	- release when ready (something like every 3 month)
	- merge window until -rc1 (something like 2 weeks)
	http://en.wikipedia.org/wiki/Merge_window
	- patches are reviewed on the ML, several subsystem tree
	dedicated to specific parts of the kernel exist with their
	responsible developer which review and apply the patches before
	sending pull requests
	- then several -rcX to fix bugs and regressions (but no new
	features)
	http://go.linuxfoundation.org/who-writes-linux-2012

* Yocto :
	- initial schedule with goals to reach for the release
	- several milestones and here again 1 month of stabilization
	before the release
	https://wiki.yoctoproject.org/wiki/Development_Methodology
	https://wiki.yoctoproject.org/wiki/Yocto_1.4_Schedule

* buildroot : http://buildroot.uclibc.org/news.html
	- release every 3 month
	- here again several -rc to stabilize with a next branch to
	collect new patches for the next release

And you can find more here :
https://live.gnome.org/ReleasePlanning/TimeBased
http://techbase.kde.org/Schedules/Release_Schedules_Guide
https://fedoraproject.org/wiki/Releases
https://wiki.ubuntu.com/TimeBasedReleases
https://wiki.ubuntu.com/FeatureFreeze

Hope this helps,

Best regards,
Eric