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

[Khem Raj]

On Wed, Dec 1, 2010 at 5:33 AM, Frans Meulenbroeks
<fransmeulenbroeks at gmail.com> wrote:
> 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.
>>

I planned it for this coming friday. There still are some patches
for micro that needs to go in.

>>> 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
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>