[oe] release-2010: when & what to do

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Wed Dec 1 13:33:23 UTC 2010


2010/12/1 Stefan Schmidt <stefan at datenfreihafen.org>:
> Hello.
>
> On Wed, 2010-12-01 at 10:06, Frans Meulenbroeks wrote:
>>
>> I wanted to raise the issue of when to do the release. I seem to
>> recall dec 1 was coined in the past (which is today in most of the
>> timezones at the time of writing).
>
> Thats correct.
>
>> It seems to me that we still some areas needing attention (uclibc, the
>> multiple provides for a few packages and probably some more things).
>> What about if we try to get these resolved this week, plan an
>> additional testing session over the weekend and decide early next week
>> on how to proceed?
>
> Doe we already have patches for the issues? If not I think delaying the release
> for issues we don't even have fixes for is not a good idea. If we have fixes
> delaying some days for more testing would be ok imho.
>
> We need to keep in mind that none of our releases will be without issues.
> Striving for perfection is good but we should not start to delay releases just
> in the hope more time will fix more issues. That just does not work.
>
> Our next release would be targetted for 1th March. That means three months time
> to fix the issues with uclibc and getting it in good shape in master.
>
> So my opinion would be in short: Get in all fixes that we have today, test and
> release on friday. That would only make a two day slip and still a pretty solid
> release. The last word on this should be by Khem I think as he has the release
> manager hat on this time.
>
> regards
> Stefan Schmidt
>
I'm fine to make it Khems' call when to do the release
Wrt the uclibc/binutils: there is a patch, so Id' say go for bumping
versions. That at least gives a better baseline.

Wrt the multiple DEPENDS issue:
It is not too difficult to fix these. E.g. for mysql nuke the old
version, for modutils decide which package delivers depmod. (modutils
or modutils-cross) and for bluez retire bluez-libs_3* (or maybe pin
bluez-libs_4* in distros that do not pin bluez)
But of course this does carry some political implications.

Frans




More information about the Openembedded-devel mailing list