[Mageia-discuss] ISO 0 specification

[Maarten Vanraes]

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