2010/12/1 Stefan Schmidt <[email protected]>: > 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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
