Op dinsdag 02 november 2010 13:13:17 schreef Michael Scherer: > Le mardi 02 novembre 2010 à 09:20 +0100, Maarten Vanraes a écrit : > > I read the full meeting logs from 25/10, and i noticed tmb saying: > > > > "pretty much a cooker snapshot" > > > > > > I donno how far you're going to take this; but i thought we would be > > getting a new version out ASAP. > > > > in my understanding, we would get a 2010.1 snapshot and use it to build > > the first ISO. > > > > and use the cooker snapshot to get a cauldron. > > > > imo the cooker is sooo unstable and broken, we will not be able to get a > > working ISO from it, that is more or less stable in this timeframe. > > > > eg: > > * KDE > > * glib > > * perl > > * python > > * RPM > > * ... > > > > most of these will get fixed, in time; but what about ALL the packages > > depending on that? most of the packages aren't even maintained... > > They are not more maintained on 2010.1 than on cooker.
exactly, but on 2010.1 those might still "work". > > personally, i'm against using cooker to make a stable ISO 0. > > why that's what we do all the time, after a stabilisation period. It > worked fine for the last 7 years, and that's a part of the process that > is used by lots of distributions. ( have a devel tree, fork it for > release, bug fix, release it ). There is slightly different variations > ( fedora and no frozen rawhide, debian and testing/stable/unstable ), > but all do the same, basically. i am not against a stabilisation period > > rebranding a 2010.1 will be lots more stable; and maintime we will have > > the time to make cauldron (from cooker) into something good, so we will > > be able to make a release based on cauldron on the 18th of september. > > But it would be less appealing, and this would make the life of the > communication team slightly difficult. It would also mean getting older > hardware support, older versions of various components ( like python, > for example ). that is true > And this would not save anything, as the bugfix work will have to be > done anyway sooner or later. also true > More ever, the experience showed that if you give more time to fix bugs, > bugs just take more time to be fixed ( aka, we are lazy ). The more > visible evidence is the activity in Mandriva when a deadline appear "we > will now freeze the version update", where suddenly everybody update > everything ( while we could have done sooner ) i didn't think of this, i suppose you have a valid point here > And postponing to september ( ie 6 months later ) will be imho more > problematic, as this will add the current cooker breakage to the one > introduced by all the changes that people will want to push in the 6 > months ( gnome 3, etc, etc ). We have already experience with the > current 6 months cycles, but we do not really have with a 1 year cycle, > and this may cause trouble. > > So it is better to split the work into small time based chunks, because > that's something we know, and we should avoid surprise to start the > distribution. this is why i proposed using 2010.1 as basis
