[oe] 2011.03 release testing, starts soon!

[Khem Raj]

On Wed, Feb 9, 2011 at 2:18 AM, Koen Kooi <k.kooi at 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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>