OpenEmbedded Release 2010.12 --- needs your help!

OpenEmbedded Release 2010.12 --- needs your help!

[Leon Woestenberg]

Hello all,

at OEDEM we discussed the need for OpenEmbedded releases.

- OpenEmbedded releases are planned in certain months, so that we can
plan stabilization efforts in the future.
- Each release is a point release in time.
- A release is a candidate branch point for a stable branch (which can
be maintained by those who use it).
- The next release is planned 2010.12, more specifically December 1st.
That's only four weeks from now.
- The 2010.12 release is hand-picked from a recent testing branch.

Now that our testing team has the process in place to gather test
results, please consider to build your
favorite set of distro/machine targets using tinderbox, and report your results.

One requirement is to use bitbake 1.10, as the minimal requirement
will soon be 1.10 for the OpenEmbedded metadata.


Regards,
-- 
Leon

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Khem Raj]

On Thu, Nov 4, 2010 at 1:04 PM, Leon Woestenberg
<leon.woestenberg@gmail.com> wrote:
> Hello all,
>
> at OEDEM we discussed the need for OpenEmbedded releases.
>
> - OpenEmbedded releases are planned in certain months, so that we can
> plan stabilization efforts in the future.
> - Each release is a point release in time.
> - A release is a candidate branch point for a stable branch (which can
> be maintained by those who use it).
> - The next release is planned 2010.12, more specifically December 1st.
> That's only four weeks from now.
> - The 2010.12 release is hand-picked from a recent testing branch.
>
Thanks Leon for the notice.

> Now that our testing team has the process in place to gather test
> results, please consider to build your
> favorite set of distro/machine targets using tinderbox, and report your results.

All testers please update the Testing page on wiki with the information.
http://wiki.openembedded.org/index.php/Testing

>
> One requirement is to use bitbake 1.10, as the minimal requirement
> will soon be 1.10 for the OpenEmbedded metadata.
>
>
> Regards,
> --
> Leon
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Denys Dmytriyenko]

On Thu, Nov 04, 2010 at 09:04:43PM +0100, Leon Woestenberg wrote:
> Hello all,
> 
> at OEDEM we discussed the need for OpenEmbedded releases.
> 
> - OpenEmbedded releases are planned in certain months, so that we can
> plan stabilization efforts in the future.
> - Each release is a point release in time.
> - A release is a candidate branch point for a stable branch (which can
> be maintained by those who use it).
> - The next release is planned 2010.12, more specifically December 1st.
> That's only four weeks from now.
> - The 2010.12 release is hand-picked from a recent testing branch.

- OpenEmbedded releases are planned to be time based and happen every 3 month 
(quarterly), starting with the first one on December 1st.

> Now that our testing team has the process in place to gather test
> results, please consider to build your
> favorite set of distro/machine targets using tinderbox, and report your results.
> 
> One requirement is to use bitbake 1.10, as the minimal requirement
> will soon be 1.10 for the OpenEmbedded metadata.

-- 
Denys

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Eric Bénard]

Hi,

Le 04/11/2010 23:06, Denys Dmytriyenko a écrit :
> On Thu, Nov 04, 2010 at 09:04:43PM +0100, Leon Woestenberg wrote:
>> Hello all,
>>
>> at OEDEM we discussed the need for OpenEmbedded releases.
>>
>> - OpenEmbedded releases are planned in certain months, so that we can
>> plan stabilization efforts in the future.
>> - Each release is a point release in time.
>> - A release is a candidate branch point for a stable branch (which can
>> be maintained by those who use it).
>> - The next release is planned 2010.12, more specifically December 1st.
>> That's only four weeks from now.
>> - The 2010.12 release is hand-picked from a recent testing branch.
>
> - OpenEmbedded releases are planned to be time based and happen every 3 month
> (quarterly), starting with the first one on December 1st.
>
- what about a "no major change" freeze period for 2-3 weeks before each 
release to have a enough time to stabilize a little bit the beast ?

>> Now that our testing team has the process in place to gather test
>> results, please consider to build your
>> favorite set of distro/machine targets using tinderbox, and report your results.
>>
>> One requirement is to use bitbake 1.10, as the minimal requirement
>> will soon be 1.10 for the OpenEmbedded metadata.
>

Eric

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Graham Gower]

On 5 November 2010 09:03, Eric Bénard <eric@eukrea.com> wrote:
> Hi,
>
> Le 04/11/2010 23:06, Denys Dmytriyenko a écrit :
>>
>> - OpenEmbedded releases are planned to be time based and happen every 3
>> month
>> (quarterly), starting with the first one on December 1st.
>>
> - what about a "no major change" freeze period for 2-3 weeks before each
> release to have a enough time to stabilize a little bit the beast ?

This seems like a very sane thing. Can I further suggest a "no new
recipes" freeze (perhaps only in the last week).

-Graham

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Denys Dmytriyenko]

On Thu, Nov 04, 2010 at 11:33:01PM +0100, Eric B?nard wrote:
> Hi,
>
> Le 04/11/2010 23:06, Denys Dmytriyenko a ?crit :
>> On Thu, Nov 04, 2010 at 09:04:43PM +0100, Leon Woestenberg wrote:
>>> Hello all,
>>>
>>> at OEDEM we discussed the need for OpenEmbedded releases.
>>>
>>> - OpenEmbedded releases are planned in certain months, so that we can
>>> plan stabilization efforts in the future.
>>> - Each release is a point release in time.
>>> - A release is a candidate branch point for a stable branch (which can
>>> be maintained by those who use it).
>>> - The next release is planned 2010.12, more specifically December 1st.
>>> That's only four weeks from now.
>>> - The 2010.12 release is hand-picked from a recent testing branch.
>>
>> - OpenEmbedded releases are planned to be time based and happen every 3 
>> month
>> (quarterly), starting with the first one on December 1st.
>>
> - what about a "no major change" freeze period for 2-3 weeks before each 
> release to have a enough time to stabilize a little bit the beast ?

I thought Leon kind of mentioned it in the first bullet point above, but 
probably not very clear. And yes, we definitely need a 2-3 weeks "feature 
freeze" period for stabilization. Thanks for pointing it out.

>>> Now that our testing team has the process in place to gather test
>>> results, please consider to build your
>>> favorite set of distro/machine targets using tinderbox, and report your 
>>> results.
>>>
>>> One requirement is to use bitbake 1.10, as the minimal requirement
>>> will soon be 1.10 for the OpenEmbedded metadata.

-- 
Denys

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Martin Jansa]

On Thu, Nov 04, 2010 at 06:47:52PM -0400, Denys Dmytriyenko wrote:
> On Thu, Nov 04, 2010 at 11:33:01PM +0100, Eric B?nard wrote:
> > Hi,
> >
> > Le 04/11/2010 23:06, Denys Dmytriyenko a ?crit :
> >> On Thu, Nov 04, 2010 at 09:04:43PM +0100, Leon Woestenberg wrote:
> >>> Hello all,
> >>>
> >>> at OEDEM we discussed the need for OpenEmbedded releases.
> >>>
> >>> - OpenEmbedded releases are planned in certain months, so that we can
> >>> plan stabilization efforts in the future.
> >>> - Each release is a point release in time.
> >>> - A release is a candidate branch point for a stable branch (which can
> >>> be maintained by those who use it).
> >>> - The next release is planned 2010.12, more specifically December 1st.
> >>> That's only four weeks from now.
> >>> - The 2010.12 release is hand-picked from a recent testing branch.
> >>
> >> - OpenEmbedded releases are planned to be time based and happen every 3 
> >> month
> >> (quarterly), starting with the first one on December 1st.
> >>
> > - what about a "no major change" freeze period for 2-3 weeks before each 
> > release to have a enough time to stabilize a little bit the beast ?
> 
> I thought Leon kind of mentioned it in the first bullet point above, but 
> probably not very clear. And yes, we definitely need a 2-3 weeks "feature 
> freeze" period for stabilization. Thanks for pointing it out.

what about branching future release those 2-3 weeks ago and keep master
for active development?

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.

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

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Stefan Schmidt]

Hello

On Fri, 2010-11-05 at 07:52, Martin Jansa wrote:
> On Thu, Nov 04, 2010 at 06:47:52PM -0400, Denys Dmytriyenko wrote:
> > 
> > I thought Leon kind of mentioned it in the first bullet point above, but 
> > probably not very clear. And yes, we definitely need a 2-3 weeks "feature 
> > freeze" period for stabilization. Thanks for pointing it out.
> 
> what about branching future release those 2-3 weeks ago and keep master
> for active development?
> 
> 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.

I don't think this would be a good idea. Part of the problem that we haven't
been able to do releases in the past was a development style of "dumping"
everything into master all the time. If we are able to adapt a more release
driven workflow with branches for upcoming features and a period of
stabilization in the master branch I feel that we are better prepared to bring
out releases for OE.

A lot of changes that are made like new recipes, depends fixes, packaging fixes,
etc are small enough to slip in every time. The stuff we should avoid in the
last weeks are changes touching classes, toolchain changes and other core
things.

regards
Stefan Schmidt

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Eric Bénard]

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

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.

Eric

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Martin Jansa]

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

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Eric Bénard]

Hi,

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

Eric

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]

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.

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


Thanks,

Paul

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: 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@gmail.com

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Denys Dmytriyenko]

On Thu, Nov 04, 2010 at 09:04:43PM +0100, Leon Woestenberg wrote:
> Hello all,
> 
> at OEDEM we discussed the need for OpenEmbedded releases.
> 
> One requirement is to use bitbake 1.10, as the minimal requirement
> will soon be 1.10 for the OpenEmbedded metadata.

I'm hearing that TSC made a decision today to NOT require 1.10 for the 
upcoming release. Can we get any clarification and the official announcemnt, 
please. Thanks.

-- 
Denys

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Richard Purdie]

On Thu, 2010-11-04 at 18:14 -0400, Denys Dmytriyenko wrote:
> On Thu, Nov 04, 2010 at 09:04:43PM +0100, Leon Woestenberg wrote:
> > Hello all,
> > 
> > at OEDEM we discussed the need for OpenEmbedded releases.
> > 
> > One requirement is to use bitbake 1.10, as the minimal requirement
> > will soon be 1.10 for the OpenEmbedded metadata.
> 
> I'm hearing that TSC made a decision today to NOT require 1.10 for the 
> upcoming release. Can we get any clarification and the official announcemnt, 
> please. Thanks.

There was a feeling it was too soon to the release to make a change like
that. I've emailed out a pointer to a summary of the results of the
discussions.

I have to admit I'm a little frustrated by some of the decisions but I
respect the processes we have in place.

Cheers,

Richard

Re: OpenEmbedded Release 2010.12 --- needs your help!

[Marco Cavallini]

Leon Woestenberg ha scritto, Il 04/11/2010 21:04:
> Hello all,
> 
> at OEDEM we discussed the need for OpenEmbedded releases.
> 
> - OpenEmbedded releases are planned in certain months, so that we can
> plan stabilization efforts in the future.
> - Each release is a point release in time.
> - A release is a candidate branch point for a stable branch (which can
> be maintained by those who use it).
> - The next release is planned 2010.12, more specifically December 1st.
> That's only four weeks from now.
> - The 2010.12 release is hand-picked from a recent testing branch.
> 
> Now that our testing team has the process in place to gather test
> results, please consider to build your
> favorite set of distro/machine targets using tinderbox, and report your results.
> 
> One requirement is to use bitbake 1.10, as the minimal requirement
> will soon be 1.10 for the OpenEmbedded metadata.
> 
> 
> Regards,


Thank you Leon
I am going to insert my KaeilOS distro tests ASAP


Cordiali Saluti / Kindest Regards / mit freundlichen Grüssen
--
Marco Cavallini | KOAN sas | Bergamo - Italia
 embedded and real-time software engineering
   Atmel third party certified consultant
Phone:+39-035-255.235 - Fax:+39-178-22.39.748
      http://www.KoanSoftware.com
        http://www.KaeilOS.com