On Wed, Dec 1, 2010 at 5:33 AM, Frans Meulenbroeks <fransmeulenbro...@gmail.com> wrote: > 2010/12/1 Stefan Schmidt <ste...@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@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel