All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: OpenEmbedded Release 2010.12 --- needs your help!
Date: Fri, 5 Nov 2010 10:49:20 +0100	[thread overview]
Message-ID: <20101105094915.GM3440@jama> (raw)
In-Reply-To: <4CD3CCDE.3080306@eukrea.com>

On Fri, Nov 05, 2010 at 10:22:38AM +0100, Eric Bénard wrote:
> Le 05/11/2010 07:52, Martin Jansa a écrit :
> > what about branching future release those 2-3 weeks ago and keep master for
> > active development?

no new recipes during at least last week of stablizing was also proposed
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-November/026552.html

> Stabilizing the master branch is active development as this allows to have
> stronger fundation for the next features you can introduce 2 or 3 weeks after 
> the stabilization weeks starts.

I agree but pushing new recipes to master and cherry-picking of fixes
from master to "next release" would also work and even allow testing of
fix.patch in master before cherry-picking it.

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

> If we don't do that, the idea of stable release which implies detecting and 
> fixing potential failures introduced by previous big changes will fail.

IMHO forcing main branch to be closed for new stuff (gcc branches after
stage1, before opening stage1 for new version) is used mostly to force
developers to use branch which is supposed to become stable without
tracking only the latest.

But as I said before I don't mind (much) keeping new recipes locally for
those few weeks or even pay more attention to my not-embedded-related daywork
instead of playing with OE :).

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com



  reply	other threads:[~2010-11-05  9:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-04 20:04 OpenEmbedded Release 2010.12 --- needs your help! Leon Woestenberg
2010-11-04 20:31 ` Khem Raj
2010-11-04 22:06 ` Denys Dmytriyenko
2010-11-04 22:33   ` Eric Bénard
2010-11-04 22:47     ` Graham Gower
2010-11-04 22:47     ` Denys Dmytriyenko
2010-11-05  6:52       ` Martin Jansa
2010-11-05  7:27         ` Stefan Schmidt
2010-11-05  9:22         ` Eric Bénard
2010-11-05  9:49           ` Martin Jansa [this message]
2010-11-05 10:03             ` Eric Bénard
2010-11-05 13:32               ` Paul Menzel
2010-11-05 13:52                 ` Martin Jansa
2010-11-04 22:14 ` Denys Dmytriyenko
2010-11-05  0:23   ` Richard Purdie
2010-11-05  9:08 ` Marco Cavallini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101105094915.GM3440@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.