[oe] OpenEmbedded Release 2010.12 --- needs your help!

[Martin Jansa]

On Fri, Nov 05, 2010 at 02:32:18PM +0100, Paul Menzel wrote:
> Dear OE folks,
> 
> Am Freitag, den 05.11.2010, 11:03 +0100 schrieb Eric Bénard:
> 
> > Le 05/11/2010 10:49, Martin Jansa a écrit :
> > >>> I know it could lower number of people using this future release branch
> > >>> during testing period before release, but still seems better then pushing 3
> > >>> weeks of commits from my local branch as soon as release is branched and
> > >>> master open for new recipes again.
> > >
> > >> That's the way linux, u-boot&  co are running and when the new merge window
> > >> opens several thousand of patches can be merged in a few days.
> > >
> > > And also why there is linux-next, but I agree that in our scale we can keep new
> > > recipes and features in local checkouts/out-of-tree branches without too
> > > much pain in merging them after 3 weeks.
> >
> > a temporary next branch could be open to host new big patches and then merged 
> > to master once stable is out.
> 
> I certainly would encourage to push your changes to the OE repository as
> soon as possible to share your work so other can use it or improve it.
> Be it `master` or some different branch.

I have gitorious repo for my patch queue (but that's always rebased on
top of master - to keep the diff small and changes ready for easy
cherry-pick from it).
 
> > This way most peoples getting oe during the stabilization period will get 
> > master and will test it and developers will be able to follow their 
> > development in the next branch.
> > I think that during this stabilization weeks, developers have to do the effort 
> > to checkout the next branch if they want to work on it and user must get the 
> > master branch being stabilized as a default, but not the reverse.
> 
> I guess both sides have good arguments. I would decide on what the
> documentation suggests to beginners and new contributors. If it suggests
> that `master` is the development branch new contributions should be
> based on, I suggest to create a new branch for the next stable release.
> If the documentation suggests something different, then the next stable
> release can be based on the master branch.
> 
> In either case the documentation has to be correct or needs to be
> updated to reflect the changes.

Well if it goes to master-next, then will we rebase it on top of current
master (and solve ie that PR bump because of new feature in master-next
needs another PR bump, because there was PR bump in current master due
to some small fix). Or will we just merge current master to it and
resolve conflicts there and then when "stabilizing" ends, merge
master-next back to master with all those ugly "merge+resolve" commits?

On the otherside if there is "release" branch created asap it's quite
easy that cherry-picked fix from master has newer PR changed (and edit
it to change it only by 1). But it will also force "release" maintainers
to push patch first to master and then cherry-pick.

Also whoever will be using master just to test next released version
should be really carefull not to call "git pull" after it is taged as
release and branched (or he will get stuff from maybe already merged
master-next).

So both ways have pros and cons, depends if you look at it as
"master-next" developer or "release" maintainer :).

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com