2011.03 release testing, starts soon!

2011.03 release testing, starts soon!

[Tom Rini]

Hey all,

I'd like to start getting a testing branch for the 2011.03 release going 
in place of the usual testing-next branch.  My plan is to use the 
testing-release-2011.03 branch for this and go weekly for the 10th and 
17th and then "play it by ear" and see if we need to update maybe twice 
a week until early march.

As I just mentioned in another email, I've created 
http://wiki.openembedded.org/index.php/Release-2011.03 which is where we 
can store who tested what (and against what hash).

Thanks all!

-- 
Tom Rini
Mentor Graphics Corporation

Re: 2011.03 release testing, starts soon!

[Aeschbacher, Fabrice]

Hi all, 

There are two things which could be useful (IMO) for OE users:

1. a small README file (or wiki page) just highlighting the main
   changes since last release (2010.12), e.g. something like
   "Prominent features (the cool stuff)" on http://kernelnewbies.org/LinuxChanges
   This would help us OE users to decice whether it is worth rebasing on the latest
   release now, or if it can wait 

2. Do not delete the release branch after 2011.03 will be released (just like
   it was done for 2010.12), but let it live and allow developpers committing
   bug-fixes (backporting choosen things?) reported back by OE users (some would
   would be happy to contribute this way)
   
With kind regards,
Fabrice Aeschbacher


> -----Ursprüngliche Nachricht-----
> Im Auftrag von Tom Rini
> Gesendet: Dienstag, 8. Februar 2011 20:42
> Betreff: [oe] 2011.03 release testing, starts soon!
> 
> Hey all,
> 
> I'd like to start getting a testing branch for the 2011.03 
> release going 
> in place of the usual testing-next branch.  My plan is to use the 
> testing-release-2011.03 branch for this and go weekly for the 
> 10th and 
> 17th and then "play it by ear" and see if we need to update 
> maybe twice 
> a week until early march.
> 
> As I just mentioned in another email, I've created 
> http://wiki.openembedded.org/index.php/Release-2011.03 which 
> is where we 
> can store who tested what (and against what hash).
> 
> Thanks all!
> 
> -- 
> Tom Rini
> Mentor Graphics Corporation

Re: 2011.03 release testing, starts soon!

[Stefan Schmidt]

Hello.

On Wed, 2011-02-09 at 10:25, Aeschbacher, Fabrice wrote:
> 
> There are two things which could be useful (IMO) for OE users:
> 
> 1. a small README file (or wiki page) just highlighting the main
>    changes since last release (2010.12), e.g. something like
>    "Prominent features (the cool stuff)" on http://kernelnewbies.org/LinuxChanges
>    This would help us OE users to decice whether it is worth rebasing on the latest
>    release now, or if it can wait 

Good point. Getting such a high level changelog in place would indeed be a good
idea.

> 2. Do not delete the release branch after 2011.03 will be released (just like
>    it was done for 2010.12), but let it live and allow developpers committing
>    bug-fixes (backporting choosen things?) reported back by OE users (some would
>    would be happy to contribute this way)

That was already discussed. We make a tag with the release rev from which can be
branched again _if_ people are stepping up to support this branch on a mid or
long term base.

The branch Tom is using until the release is pretty useless froma history point
of view (all changes must be in master as well). When he thinks the release is
good enough the tag gets added and the old branch deleted. For the last release
nobody cared to support it afterwards with bugfixes so no release branch was
created.

I'm thinking about this for the upcoming release. If all works well we will base
a product on it which I would like to support directly from such a release
branch.

The hard part is how people could decide on pooling resources on this. Defining
goals for such a branch and stuff. E.g. only take serious fixes? What about
package updates? Security fixes? changes on the toolchain or classes?

This is up to the group who wants to support such a branch. Anyone else
interested in doing this for 2011-03?

My alternative would be to branch of from the tag and do the maintenance in a
private branch.

regards
Stefan Schmidt

Re: 2011.03 release testing, starts soon!

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09-02-11 10:56, Stefan Schmidt wrote:

>> 2. Do not delete the release branch after 2011.03 will be released (just like
>>    it was done for 2010.12), but let it live and allow developpers committing
>>    bug-fixes (backporting choosen things?) reported back by OE users (some would
>>    would be happy to contribute this way)
> 
> That was already discussed. We make a tag with the release rev from which can be
> branched again _if_ people are stepping up to support this branch on a mid or
> long term base.
> 
> The branch Tom is using until the release is pretty useless froma history point
> of view (all changes must be in master as well). When he thinks the release is
> good enough the tag gets added and the old branch deleted. For the last release
> nobody cared to support it afterwards with bugfixes so no release branch was
> created.
> 
> I'm thinking about this for the upcoming release. If all works well we will base
> a product on it which I would like to support directly from such a release
> branch.
> 
> The hard part is how people could decide on pooling resources on this. Defining
> goals for such a branch and stuff. E.g. only take serious fixes? What about
> package updates? Security fixes? changes on the toolchain or classes?
> 
> This is up to the group who wants to support such a branch. Anyone else
> interested in doing this for 2011-03?

I discussed this with Philip and Graeme and the idea is to retire
angstrom-2008.1.conf into that branch. I still have customers (you
indirectly :)) using that, so having it in that branch would be very neat.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNUmnrMkyGM64RGpERAuT/AJ9mytn+0MD+p0r5wIHO9ZGZ+faHWwCfaok8
s2oPs47xZ2Ud4um/cqA8G4U=
=JpX4
-----END PGP SIGNATURE-----

Re: 2011.03 release testing, starts soon!

[Stefan Schmidt]

Hello.

On Wed, 2011-02-09 at 11:18, Koen Kooi wrote:
> On 09-02-11 10:56, Stefan Schmidt wrote:
> 
> >> 2. Do not delete the release branch after 2011.03 will be released (just like
> >>    it was done for 2010.12), but let it live and allow developpers committing
> >>    bug-fixes (backporting choosen things?) reported back by OE users (some would
> >>    would be happy to contribute this way)
> > 
> > That was already discussed. We make a tag with the release rev from which can be
> > branched again _if_ people are stepping up to support this branch on a mid or
> > long term base.
> > 
> > The branch Tom is using until the release is pretty useless froma history point
> > of view (all changes must be in master as well). When he thinks the release is
> > good enough the tag gets added and the old branch deleted. For the last release
> > nobody cared to support it afterwards with bugfixes so no release branch was
> > created.
> > 
> > I'm thinking about this for the upcoming release. If all works well we will base
> > a product on it which I would like to support directly from such a release
> > branch.
> > 
> > The hard part is how people could decide on pooling resources on this. Defining
> > goals for such a branch and stuff. E.g. only take serious fixes? What about
> > package updates? Security fixes? changes on the toolchain or classes?
> > 
> > This is up to the group who wants to support such a branch. Anyone else
> > interested in doing this for 2011-03?
> 
> I discussed this with Philip and Graeme and the idea is to retire
> angstrom-2008.1.conf into that branch. I still have customers (you
> indirectly :))

Well aware of it. :)

> using that, so having it in that branch would be very neat.

That sounds pretty good to me. I wanted to move on after this release anyway.
Angstrom 2010 based on OE-Core would be my favourite. :)

Does this mean you would like to get some "final" fixes into such  branch as
well? If we would need to think about what we would accept in there.

regards
Stefan Schmidt

Re: 2011.03 release testing, starts soon!

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09-02-11 11:42, Stefan Schmidt wrote:
> Hello.
> 
> On Wed, 2011-02-09 at 11:18, Koen Kooi wrote:
>> On 09-02-11 10:56, Stefan Schmidt wrote:
>>
>>>> 2. Do not delete the release branch after 2011.03 will be released (just like
>>>>    it was done for 2010.12), but let it live and allow developpers committing
>>>>    bug-fixes (backporting choosen things?) reported back by OE users (some would
>>>>    would be happy to contribute this way)
>>>
>>> That was already discussed. We make a tag with the release rev from which can be
>>> branched again _if_ people are stepping up to support this branch on a mid or
>>> long term base.
>>>
>>> The branch Tom is using until the release is pretty useless froma history point
>>> of view (all changes must be in master as well). When he thinks the release is
>>> good enough the tag gets added and the old branch deleted. For the last release
>>> nobody cared to support it afterwards with bugfixes so no release branch was
>>> created.
>>>
>>> I'm thinking about this for the upcoming release. If all works well we will base
>>> a product on it which I would like to support directly from such a release
>>> branch.
>>>
>>> The hard part is how people could decide on pooling resources on this. Defining
>>> goals for such a branch and stuff. E.g. only take serious fixes? What about
>>> package updates? Security fixes? changes on the toolchain or classes?
>>>
>>> This is up to the group who wants to support such a branch. Anyone else
>>> interested in doing this for 2011-03?
>>
>> I discussed this with Philip and Graeme and the idea is to retire
>> angstrom-2008.1.conf into that branch. I still have customers (you
>> indirectly :))
> 
> Well aware of it. :)
> 
>> using that, so having it in that branch would be very neat.
> 
> That sounds pretty good to me. I wanted to move on after this release anyway.
> Angstrom 2010 based on OE-Core would be my favourite. :)

Angstrom 2010 based on yocto is looking better each day, I just fixed
the last 2 bugs preventing meta-toolchain from building. We just need
get thru the breakage associated with the yocto -> oe-core transition :)

> Does this mean you would like to get some "final" fixes into such  branch as
> well? If we would need to think about what we would accept in there.

I suspect I'll need to fix bugs in TI stuff for that branch, but I don't
want to have that branch turn in to a "oe-core is too scary, we'll
develop in here" type of thing.
I like Esbens idea of stable branch management, but that might be too
strict for others.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNUnh/MkyGM64RGpERAusnAJsHM1GVb7kosWmY69NooAnvQaNQTQCbBeqe
5/Je8zmoyp6lWwsBuxBHD68=
=hqIT
-----END PGP SIGNATURE-----

Re: 2011.03 release testing, starts soon!

[Tom Rini]

On 02/09/2011 02:25 AM, Aeschbacher, Fabrice wrote:
> Hi all,
>
> There are two things which could be useful (IMO) for OE users:
>
> 1. a small README file (or wiki page) just highlighting the main
>     changes since last release (2010.12), e.g. something like
>     "Prominent features (the cool stuff)" on http://kernelnewbies.org/LinuxChanges
>     This would help us OE users to decice whether it is worth rebasing on the latest
>     release now, or if it can wait

Great idea!  I've added a place-holder to the wiki page for the release.

> 2. Do not delete the release branch after 2011.03 will be released (just like
>     it was done for 2010.12), but let it live and allow developpers committing
>     bug-fixes (backporting choosen things?) reported back by OE users (some would
>     would be happy to contribute this way)

My _hope_ is to not have to make a branch to take from, but we shall 
see.  Beyond that, I see the discussion about keeping something that's 
not just top of tree alive as an important but only related discussion. 
  Starting from the release tag is probably the best bet, should 
something want to happen in that direction.

-- 
Tom Rini
Mentor Graphics Corporation

Re: 2011.03 release testing, starts soon!

[Khem Raj]

On Wed, Feb 9, 2011 at 2:18 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09-02-11 10:56, Stefan Schmidt wrote:
>
>>> 2. Do not delete the release branch after 2011.03 will be released (just like
>>>    it was done for 2010.12), but let it live and allow developpers committing
>>>    bug-fixes (backporting choosen things?) reported back by OE users (some would
>>>    would be happy to contribute this way)
>>
>> That was already discussed. We make a tag with the release rev from which can be
>> branched again _if_ people are stepping up to support this branch on a mid or
>> long term base.
>>
>> The branch Tom is using until the release is pretty useless froma history point
>> of view (all changes must be in master as well). When he thinks the release is
>> good enough the tag gets added and the old branch deleted. For the last release
>> nobody cared to support it afterwards with bugfixes so no release branch was
>> created.
>>
>> I'm thinking about this for the upcoming release. If all works well we will base
>> a product on it which I would like to support directly from such a release
>> branch.
>>
>> The hard part is how people could decide on pooling resources on this. Defining
>> goals for such a branch and stuff. E.g. only take serious fixes? What about
>> package updates? Security fixes? changes on the toolchain or classes?
>>

I would suggest to take only bugfixes and refrain from infrastructure
changes which usually
happen metadata wide and toolchain and classes are biggest part of
this and with time backports
into long term branches become more and more complex and painful and
it may be that you have to do
entirely different patch to solve the same issue in this branch which
has been fixed differently upstream
I think if such a branch is to be created it should be created from
the release tag after the release happens

>> This is up to the group who wants to support such a branch. Anyone else
>> interested in doing this for 2011-03?

If such a branch is expected for long term then its better to decide
its policies on patches
from upstream pov all fixes that go into this branch should first go
into master if its not
a direct backport of some sort. That way we can be sure that we dont
lose changes that should be in master.

>
> I discussed this with Philip and Graeme and the idea is to retire
> angstrom-2008.1.conf into that branch. I still have customers (you
> indirectly :)) using that, so having it in that branch would be very neat.
>
> regards,
>
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFNUmnrMkyGM64RGpERAuT/AJ9mytn+0MD+p0r5wIHO9ZGZ+faHWwCfaok8
> s2oPs47xZ2Ud4um/cqA8G4U=
> =JpX4
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: 2011.03 release testing, starts soon!

[Stefan Schmidt]

Hello.

On Wed, 2011-02-09 at 12:30, Khem Raj wrote:
> On Wed, Feb 9, 2011 at 2:18 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> > On 09-02-11 10:56, Stefan Schmidt wrote:
> >
> >>> 2. Do not delete the release branch after 2011.03 will be released (just like
> >>>    it was done for 2010.12), but let it live and allow developpers committing
> >>>    bug-fixes (backporting choosen things?) reported back by OE users (some would
> >>>    would be happy to contribute this way)
> >>
> >> That was already discussed. We make a tag with the release rev from which can be
> >> branched again _if_ people are stepping up to support this branch on a mid or
> >> long term base.
> >>
> >> The branch Tom is using until the release is pretty useless froma history point
> >> of view (all changes must be in master as well). When he thinks the release is
> >> good enough the tag gets added and the old branch deleted. For the last release
> >> nobody cared to support it afterwards with bugfixes so no release branch was
> >> created.
> >>
> >> I'm thinking about this for the upcoming release. If all works well we will base
> >> a product on it which I would like to support directly from such a release
> >> branch.
> >>
> >> The hard part is how people could decide on pooling resources on this. Defining
> >> goals for such a branch and stuff. E.g. only take serious fixes? What about
> >> package updates? Security fixes? changes on the toolchain or classes?
> >>
> 
> I would suggest to take only bugfixes and refrain from infrastructure
> changes which usually
> happen metadata wide and toolchain and classes are biggest part of
> this and with time backports
> into long term branches become more and more complex and painful and
> it may be that you have to do
> entirely different patch to solve the same issue in this branch which
> has been fixed differently upstream

Staying away from infrastructure and toolchain changes is something I really
want to see for such a branch.

From my BugLabs side I would expect bug fixes but also some package updates.
That would be stuff based on the java/osgi framework we are deploying so
hopefully it would not make problems for anyone else. I don't expect to much
problems with that.

With regards to the lifetime I don't see this as a several years branch fo our
product (thinking about oe-core for the next release). Obviously it is still
fine for other people to use it that long. The current stable branch is a good
example for this. It is still used and different companies/people are happy with
it having no updates at all for some time. :)

I would expect something else for the branch on top of the 2011-03 release. Some
more changes in the begining while fixing problems that poped up after the tag
was created but commits will slow down after some months.

> I think if such a branch is to be created it should be created from
> the release tag after the release happens

Agreed.

> >> This is up to the group who wants to support such a branch. Anyone else
> >> interested in doing this for 2011-03?
> 
> If such a branch is expected for long term then its better to decide
> its policies on patches
> from upstream pov all fixes that go into this branch should first go
> into master if its not
> a direct backport of some sort. That way we can be sure that we dont
> lose changes that should be in master.

Agreed as well. It gets a mess if we start fixing stuff in the release branch
only.

regards
Stefan Schmidt

Re: 2011.03 release testing, starts soon!

[Aeschbacher, Fabrice]

> > 1. a small README file (or wiki page) just highlighting the main
> >     changes since last release (2010.12), e.g. something like
> >     "Prominent features (the cool stuff)" on http://kernelnewbies.org/LinuxChanges
> >     This would help us OE users to decice whether it is worth rebasing on the latest
> >     release now, or if it can wait
> 
> Great idea!  I've added a place-holder to the wiki page for 
> the release.

Thank you!

BTW, it's here: http://www.openembedded.org/index.php/Release-2011.03

With kind regards,
Fabrice Aeschbacher