Re: [Mageia-dev] Release cycles proposals, and discussion

[Dexter Morgan]

On Sun, Jun 12, 2011 at 10:46 PM, Michael Scherer  wrote:
> Hi,
>
> so , with a little bit delay due to various things ( like everybody
> asking stuff to us on irc on a hourly fashion ( people will I hope
> recognize themselves )), Anne and I have reviewed the various proposals
> made through years during the early period of the distribution, and
> before at Mandriva. We took in account the feedback of people on forum,
> on ml, nd those we have seen during events. We also discussed with
> others distributions developers we know from Opensuse, Fedora, Debian,
> Ubuntu about their release cycle, the choices they made and their
> reasons.
>
> Before going to the proposal, a few point of vocabulary :
>
> Release cycle mean the time between 2 releases.
>

 Hello, i would be in favor of proposal 2.

For not beeing in sync with upstream projects ( gnome, kde, ... ) this
is for me a "false problem"  because we won't provide the first
release ( like gnome 3.2 or kde 4.7 ) but we will be able to release a
bugfix release ( gnome 3.2.x , kde 4.7.5 ) which means less work for
QA team during stable release.

This proposal allow us to do more "long term" projects too.

I think that with proposition 3 we will have less visibility because
ppl will have real news of us only once per year.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Angelo Naselli]

In data domenica 12 giugno 2011 22:46:33, Michael Scherer ha scritto:
> Proposal 1: 
> 6 months release cycle -> 12 months life cycle
> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> 
> Proposal 2: 
> 9 months release cycle -> 18 months life cycle  
> ( ~ opensuse and the one we used for Mageia 1 )
> 
> Proposal 3: 
> 12 months release cycle -> 24 months life cycle
> ( Mandriva > 2010.1 )

Well imo extending too much release cycle means also to
have a lot of backports and patches for fixings.

So 1 or 2 are better, more upstream packages than fixings.

If we cannot afford 6 mo release cycle because we're all volunteers for 
instance, 9 mo one is the right compromise, i believe.

Cheers, 
-- 
Angelo


signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Sander Lepik]

12.06.2011 23:46, Michael Scherer kirjutas:

Proposal 1:
6 months release cycle ->  12 months life cycle
( Fedora, Ubuntu, Mandriva<  2010.1&&  Mandriva != 2006.0 )

Proposal 2:
9 months release cycle ->  18 months life cycle
( ~ opensuse and the one we used for Mageia 1 )

Proposal 3:
12 months release cycle ->  24 months life cycle
( Mandriva>  2010.1 )
From those options i would go with the second one. Third is way too much wanted from users 
(and first has too short life cycle). They are always eager for new stuff and waiting one 
year ain't option for them. We could also try to have some LTS versions. But in a bit 
different manner than Ubuntu. Like if we notice that some release is good and stable we 
could extend its support period (ie mdv2008.1 was really stabel and also mdv2010.1 was 
pretty good - for me neither had too many problems and i would have keeped 2008.1 for longer 
but its support ended).


One more thing i didn't like with Mageia 1. Official launch date that you know is coming and 
you see that not all things are ready for prime time but you go anyway as there is launch 
date announced. Ubuntu has failed with that at least few times.
Debian (Mozilla somewhat too) does better job here. They don't release if they see critical 
problems and they don't announce release too far away.

In that hurry we probably missed ATI graphics problem and could have solved it 
better.

Maybe we should try to have 9 months but if it will be 10 with more stable release i would 
go with 10 (or mabye final freeze in 8 months and then we'll see how fast we can make it 
stable).


(And we have to keep up the good job with upgrading smoothness - in the future it must be 
tested even more, that way users who want longer cycle will complain less if they can 
upgrade their system w/o big problems.)


--
my 0.02€ (or a bit more :P)
Sander

Re: [Mageia-dev] Release cycles proposals, and discussion

[Zé]

Em 2011/6/12 Michael Scherer  escreveu:
> Proposal 1 :
> ---
> Pros:
> - better hardware support
> - up to date versions / upstream projects (must have for developers)
>
>
> Cons:
> - very tight schedule: must include brainstorm, specifications,
> developments, development releases
> - feeling to be releasing all the time
> - short lifecycle ( nothing long term )
>
>
> Proposal 2
> 
> Pros:
> - compromise between proposal 1 and proposal 3
> - development release more manageable to include all steps
> - allow to release when no others distributions , so we can be sure to
> have enough communication
>
>
> Cons:
> - not synchronized with gnome or others that use a 6 month cycle
> - potentially release when there isn't much activity ( like during
> Holidays )

I think proposal 3 would not be the best option since as commnity
users expect things faster, so i think they would in favour of
proposal 1 or 2.
But since this its distro vollunteer-based would be more real to have
9 months between a release, this considering we have the backports and
update sections to handle beetween apps releases and to please those
more impatient users.
So in conclusion my preference goes with proposal 2.

-- 
Zé

Re: [Mageia-dev] Release cycles proposals, and discussion

[Dick Gevers]

On Sun, 12 Jun 2011 22:46:33 +0200, Michael Scherer wrote about
[Mageia-dev] Release cycles proposals, and discussion:

>Out of theses 3 propositions, Anne was in favor of the version 2 ( 9
>months ), based on her experience with 1 ( Mandriva ) and 3 ( Mandriva
>2006.0 ). 

I personally prefer a quick turnaround and keep it exciting: proposition #
1, but otherwise I follow the leader. One whole year release cycle (# 3)
appears to dull for me: we are cooking the Cauldron and not granny's tea
kettle.

Viva Mageia !

Re: [Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

Op zondag 12 juni 2011 23:38:48 schreef Angelo Naselli:
> In data domenica 12 giugno 2011 22:46:33, Michael Scherer ha scritto:
> > Proposal 1:
> > 6 months release cycle -> 12 months life cycle
> > ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> > 
> > Proposal 2:
> > 9 months release cycle -> 18 months life cycle
> > ( ~ opensuse and the one we used for Mageia 1 )
> > 
> > Proposal 3:
> > 12 months release cycle -> 24 months life cycle
> > ( Mandriva > 2010.1 )
> 
> Well imo extending too much release cycle means also to
> have a lot of backports and patches for fixings.
> 
> So 1 or 2 are better, more upstream packages than fixings.
> 
> If we cannot afford 6 mo release cycle because we're all volunteers for
> instance, 9 mo one is the right compromise, i believe.
> 
> Cheers,

+1

allthough, _perhaps_ there is another option: (i didn't think about the effect 
this would have on life cycles):

i was thinking, that maybe we want 9months now, because of big changes coming, 
but maybe in the future we would do less big changes for instance.

Proposal 4:
JIT-fixed months release cycle -> ? months life cycle

explanation:
the idea is to have the following things happen after release:
1. postmortem
2. discussion of features
3. decision of features
4. making planning and deciding time based on the featurelist and an educated 
guess on time required to implement and bugfix. (generally between 6 and 12 
months)


pro:
 - allows to plan release taking into account everything:
- list of features to be done (and amount of packagers)
- holidays
- releases of other distros
- stuff i hadn't thought of

con:
 - there could be a pitfall that we ALWAYS don't fulfill the planning
 - unknown months life cycle


in general, it would mean, what we do right now, there's a separate decision 
every time.

thinking specifically on this time:
 - 8months: 1st febr, bad idea: because of christmas holidays there will 
likely be no good testing.
 - 9months is 1st march? (sounds like a busy time for other distros)
 - 10months:  1st april (april fools joke? not good)

I'm thinking 10,5 months for this one: April 15th. perhaps next time most big 
changes will be done, and we could go for a short 6 or 7month release if we 
have more resources at that time.

just my personal opinion,

Maarten

Re: [Mageia-dev] Release cycles proposals, and discussion

[Colin Guthrie]

'Twas brillig, and Michael Scherer at 12/06/11 21:46 did gyre and gimble:
> Proposal 1: 
> 6 months release cycle -> 12 months life cycle
> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> 
> Proposal 2: 
> 9 months release cycle -> 18 months life cycle  
> ( ~ opensuse and the one we used for Mageia 1 )
> 
> Proposal 3: 
> 12 months release cycle -> 24 months life cycle
> ( Mandriva > 2010.1 )

I'll take 1 or 2 please! 3 would would be sacrificing too much IMO.

Between 1 or 2, I think I'd likely prefer option 1, but there is not a
massive swing either way for me.

Col

-- 

Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [Mageia-dev] Release cycles proposals, and discussion

[Zézinho]

Em 12-06-2011 22:46, Michael Scherer escreveu:

- all proposals must be justified ( and why they are better than the
current ones ).

9 months means no yearly loop. Humans are used to seasons, and except 
for things that do not happen yearly, this is inside our genetics ;-) 
Think olympic games, etc.


So either 6 or 12 or 24 months seems a good release time IMHO. Then 
looking at other main distributions, 12 months means "loosing" users 
(future contributors) every time we don't release near others release.

So 6 months ends up as the only way to keep the head out of water...

Re: [Mageia-dev] Release cycles proposals, and discussion

[Renaud MICHEL]

Hello
On Sunday 12 June 2011 at 22:46, Michael Scherer wrote :
> To simplify the discussion, the proposals are all based on the fact that
> 2 or 3 releases could be supported at a time. We could have different
> schemes for that ( LTS every X release ( ubuntu ), different level of
> support ( mandriva )), but as this is a slightly different discussion,
> let's assume 2 supported releases for now, and let's discuss later for
> that ( ie next week, once this one is finished )
> 
> And roughly, to start the discussion, we have 3 potential releases
> cycles, based on all inputs we had :
> 
> Proposal 1: 
> 6 months release cycle -> 12 months life cycle
> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> 
> Proposal 2: 
> 9 months release cycle -> 18 months life cycle  
> ( ~ opensuse and the one we used for Mageia 1 )
> 
> Proposal 3: 
> 12 months release cycle -> 24 months life cycle
> ( Mandriva > 2010.1 )

From a long time mandriva (and now mageia) user POV, for myself I was quite 
fine with 6 month release cycle, but at work I'd rather not update too 
frequently and same goes for the rest of the family who generally don't care 
much for newer versions. And I know that for some people, a big upgrade 
every 6 month is a lot of work (and skipping a release is more risky).

So I think either proposal #2 or #3 would do, my preference depending on how 
much could be backported to the latest stable release.
What I mean is, if it is possible to have backports of newer releases for 
big projects, like KDE (and other DEs), libreoffice, firefox, samba 
(important at work), ..., then I am fine with a 1 year release cycle of 
proposal #3.

If the maintainer of such big projects (especially the DEs) think it would 
be too hard to backports newer versions to the 8-10 months old stack of the 
latest stable release (as I have seen recently such discussions on KDE MLs), 
then I would prefer proposal #2 to not be lacking behind too much.

cheers
-- 
Renaud Michel

Re: [Mageia-dev] Release cycles proposals, and discussion

[magnus]

>From a long time mandriva (and now mageia) user POV, for myself I was quite
> fine with 6 month release cycle, but at work I'd rather not update too
> frequently and same goes for the rest of the family who generally don't
> care
> much for newer versions. And I know that for some people, a big upgrade
> every 6 month is a lot of work (and skipping a release is more risky).
>
I agree and think this the the sight of most of the "normal" users.

Proposal #2 is the right time to discuss, to do greater changes and to
test.
Especially testing-time should be a focus to get a standing as very stable
distri.

Other hand, we should not hang too close to the nine month.
The release date could be a good "human readable" date:

Mageia 2 = Spring time (2012-03-20)
Mageia 3 = Nicolas (2012-12-06)
Mageia 4 = Revolution (2013-07-14) or Birthday (2013-09-18)

or someting like this

Proposal #3 is too long, for the patience of the users and developers

Magnus

Re: [Mageia-dev] Release cycles proposals, and discussion

[Dick Gevers]

On Mon, 13 Jun 2011 00:58:36 +0200, Zézinho wrote about Re: [Mageia-dev]
Release cycles proposals, and discussion:

>Em 12-06-2011 22:46, Michael Scherer escreveu:
>> - all proposals must be justified ( and why they are better than the
>> current ones ).
>>
>9 months means no yearly loop. Humans are used to seasons, and except 
>for things that do not happen yearly, this is inside our genetics ;-) 

Nine months is genetically very human: the average human female carries
it's offspring for that length of time. So why not Mageia ?

Re: [Mageia-dev] Release cycles proposals, and discussion

[Andres Kaaber]

...
I wold go for the 9 mo cycle (most probably I will use cauldron for
myself ;) ) 9 mo release gives enoug time for developers and its not
so long time (for me, my wifes pregnancy went so quckly :) ) and for
users with a need for a longer support LTS. I dont remember who said
it but I liked the idea that we decide wich release will be LTS.
Another thing ... for me A new "release" devides into two. First -
upgraded software, KDE, GNOME, LibO, kernel etc. software that is not
made by Mageia developers and second software that is made by Mageia
developers drak* etc. For me the real value of distro comes from these
tools wich are made by distro developers. There where lots of Mandriva
releases with no noticeable changes in Mandriva tools. So the 9 mo
release will give more time to make better / bugfree distro specific
tools.

-- 
A. Kaaber

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 03:07 -0700, Ron a écrit :
> I made another post in a different thread about the way I feel the release 
> cycle should go. After more thinking
>  I do think that I really have the right idea and here is why...
> Going the route of release cycles really does not make this distribution fit 
> into anything. You going to try 
> and appeal to new people? Ubuntu has that covered and you will never steal 
> that role. Hoping to become a geek type 
> distro? There are many that have that covered. 
>
> The best thing you can do as a team is try to come up with something that 
> makes you stand apart from the crowd.

There is a limited set of options, and as you can see, none of your idea
was not already explored by someone else.

>  I never understood the release cycle model anyhow, whats the goal of that? 

If everything move all days, you cannot :
- translate software ( as the string will change every day )
- create documentation ( for the same reason )
- communicate ( as everything ca be broken at any time )
- ensure stability ( as each change can bring unstability )

And for user, some do not want to redo training every week for their
users, because libreoffice got updated, because ff 4 just arrived and
75% of extensions do not work, etc. 

In fact, the whole release model is basically what is used all over the
place, from lower level like kernel to higher level like kde. So you can
get lots of feedback on it.

> To show off the latest tech in the open source world? Really? With Slackware 
> and Fedora and 
> Suse and hosts of other flavors of GNU/Linux all doing the same thing?

So basically, you suggest that since everybody is already doing it, this
is useless. So the logical conclusion is we should drop the
distribution ?

> What do we have that others don't? 

We have the same thing, this is the strength of free software. We
basically all work together.


> We have something new that can be great 
> if planned right. There are 100's of distros releasing in cycles, let's get 
> out of that and truly showcase the best of open source through:
> Unstable branch - absolute latest software here...

like cauldron ? or debian unstable, fedora rawhide, opensuse factory,
mandriva cooker ?

> Rolling unstable - Still risky but not on the lines of unstable

like debian testing ( and CUT ) ? suse tumbleweed ? arch linux ?


> Rolling stable - everyday use and very stable 

Very stable for a distribution mean "that do not change". That's
incompatible with the idea of rolling per definition. And in order to
have stable software, you have to freeze them and fix bugs. So to have
that on the whole distribution, you need to freeze the whole
distribution for a time, and then ask for test, fix bugs and then
release. Which is exactly what we currently do since years. 

> You could throw in "snapshots" and support those for X amount of time 
> as I have posted in the other place if you wanted (based on rolling 
> unstable). 
> You could also have LTS releases based on Rolling stable It's up to you.
> I don't believe we need yet another "burn new disk every X months for" 
> distribution. 

So basically, you just reinvented the concept of release, and the way
Mandriva, Debian, Fedora work since years. 

-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thorsten van Lil]

Am Sonntag, 12. Juni 2011, 22:46:33 schrieb Michael Scherer:
> Proposal 1: 
> 6 months release cycle -> 12 months life cycle
> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> 
> Proposal 2: 
> 9 months release cycle -> 18 months life cycle  
> ( ~ opensuse and the one we used for Mageia 1 )
> 
> Proposal 3: 
> 12 months release cycle -> 24 months life cycle
> ( Mandriva > 2010.1 )

Has there already been a discussion about the general release model (static, 
rolling, light rolling, ...)? I only saw one on the forum but not a (official) 
discussion on the ml.

Greetings,
Thorsten

Re: [Mageia-dev] Release cycles proposals, and discussion

[P. Christeas]

On Monday 13 June 2011, Michael Scherer wrote:

> > What do we have that others don't?
> 
> We have the same thing, this is the strength of free software. We
> basically all work together.


Well, what I've always enjoyed about Mandriva (as implemented by some people 
of a company called "Edge-IT") was they worked a little different than other 
major distros (see. Debian) :
- they would take any latest minor number of upstream projects, based just on 
the promise that minor releases were bugfix ones on otherwise stable series.
- lacking the luxury of a huge community and extensive tests, they would 
immediately package that and push it to Cooker, at least.

Most of the time, that strategy worked marvelously. We had all the upstream 
bugfixes, truly imported with their release number. 

-- 
Say NO to spam and viruses. Stop using Microsoft Windows!

Re: [Mageia-dev] Release cycles proposals, and discussion

[Radu-Cristian FOTESCU]

> Unstable branch - absolute latest software here...
> Rolling unstable - Still risky but not on the lines of unstable
> Rolling stable - everyday use and very stable 

May I add my bit of unrequested thoughts?

This discussion seems to only differentiate between "degrees of unstability and 
risks", but nothing about "user roles". 
IMHO, a distro is not only about "risk vs. features", but also about what 
people are expecting from it.

I could imagine for user roles:

"rolling-user" branch: 
-- KDE4, GNOME3, XFCE, LibreOffice, Firefox/Thunderbird, Chromium are always 
kept to the latest _stable_ (not development) version;
-- other applications might be kept (or not) to the latest _stable_ (not 
development) version; 
-- other libraries are to be upgraded _only_ if they're required by newer 
applications.

"rolling-user-risky" branch: 
-- KDE4, GNOME3, XFCE, LibreOffice, Firefox/Thunderbird, Chromium are always 
kept to the latest _development_/_unstable_ version;
-- other applications might be kept to the latest _development_/_unstable_ 
version, otherwise most are kept to the latest _stable_ version; 
-- other libraries are to be upgraded _only_ as they're required by newer 
applications.

"rolling-developer" branch: 
-- everything updated to the latest _development_/_unstable_ versions of 
everything.

Does this make any sense?

Best regards,
R-C (aka Beranger with an e acute)

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 01:06 +0300, Sander Lepik a écrit :
> 12.06.2011 23:46, Michael Scherer kirjutas:
> > Proposal 1:
> > 6 months release cycle ->  12 months life cycle
> > ( Fedora, Ubuntu, Mandriva<  2010.1&&  Mandriva != 2006.0 )
> >
> > Proposal 2:
> > 9 months release cycle ->  18 months life cycle
> > ( ~ opensuse and the one we used for Mageia 1 )
> >
> > Proposal 3:
> > 12 months release cycle ->  24 months life cycle
> > ( Mandriva>  2010.1 )
>  From those options i would go with the second one. Third is way too much 
> wanted from users 
> (and first has too short life cycle). They are always eager for new stuff and 
> waiting one 
> year ain't option for them. We could also try to have some LTS versions. But 
> in a bit 
> different manner than Ubuntu. Like if we notice that some release is good and 
> stable we 
> could extend its support period (ie mdv2008.1 was really stabel and also 
> mdv2010.1 was 
> pretty good - for me neither had too many problems and i would have keeped 
> 2008.1 for longer 
> but its support ended).

The LTS discussion is for next week :)

> One more thing i didn't like with Mageia 1. Official launch date that you 
> know is coming and 
> you see that not all things are ready for prime time but you go anyway as 
> there is launch 
> date announced. Ubuntu has failed with that at least few times.
> Debian (Mozilla somewhat too) does better job here. They don't release if 
> they see critical 
> problems and they don't announce release too far away.
> In that hurry we probably missed ATI graphics problem and could have solved 
> it better.

Another solution is to  have a longer freeze period, so people focus
less on last minutes changes and packages upgrades, and more on bug
fixing.

And we also do not release if there is critical problem, the question is
more "what is critical". It must also be take in account that we didn't
finish the setup of infrastructure, so we will have likely more time and
less burden next time. 


> Maybe we should try to have 9 months but if it will be 10 with more stable 
> release i would 
> go with 10 (or mabye final freeze in 8 months and then we'll see how fast we 
> can make it 
> stable).
> 
> (And we have to keep up the good job with upgrading smoothness - in the 
> future it must be 
> tested even more, that way users who want longer cycle will complain less if 
> they can 
> upgrade their system w/o big problems.)

For that, I guess we could do automated upgrade testing, something
like : 
 - we setup a vm ( scriptable + tftp + pxe )
 - we install as much as possible ( auto installation )
 - we do a scripted upgrade ( auto installation + at / cron )
 - we check if it reboot fine ( a init script + a timeout somewhere ? )

this will not solve everything, but this would be a good start. The main
problem is to decide if the upgrade went well or not for all possible
case.

-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

Op maandag 13 juni 2011 13:36:07 schreef Michael Scherer:
[...]
> Another solution is to  have a longer freeze period, so people focus
> less on last minutes changes and packages upgrades, and more on bug
> fixing.

i would be in favor of that.

Re: [Mageia-dev] Release cycles proposals, and discussion

[David Sjölin]

On Mon, Jun 13, 2011 at 1:01 PM, Thorsten van Lil  wrote:
> Am Sonntag, 12. Juni 2011, 22:46:33 schrieb Michael Scherer:
>> Proposal 1:
>> 6 months release cycle -> 12 months life cycle
>> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
>>
>> Proposal 2:
>> 9 months release cycle -> 18 months life cycle
>> ( ~ opensuse and the one we used for Mageia 1 )
>>
>> Proposal 3:
>> 12 months release cycle -> 24 months life cycle
>> ( Mandriva > 2010.1 )

Hello!

I'm for proposal 2 as well. I usually use LTS of Ubuntu at work, and
at home just keep the distribution for a long time, so I would like
far between, but I know a lot of colleagues who always install the
latest so the middle ground of 9 months seems good to me.

Regards,

David

Re: [Mageia-dev] Release cycles proposals, and discussion

[Oliver Burger]

Michael Scherer  schrieb am 12.06.2011
> Proposal 1:
> 6 months release cycle -> 12 months life cycle
> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> 
> Proposal 2:
> 9 months release cycle -> 18 months life cycle
> ( ~ opensuse and the one we used for Mageia 1 )
> 
> Proposal 3:
> 12 months release cycle -> 24 months life cycle
> ( Mandriva > 2010.1 )
That's kind of a hard decison. I don't know if a 6 month cycle would 
not put too much stress on the dev/packager community. But 12 months 
are a bit much for the hordes of impatient users usually residing in 
the forums.
So I would - for now - prefer option 2, 9 months seeming a reasonable 
time span.

Especially since we would always be able to change that cycle to 
something more fitting.

As to the "rolling" and the "lts" discussion. I think it's something 
for the future. We first have to see, how much manpower we really have, 
to maintain the distro.

I woul then kind of like the idea of a special rolling repo like 
debian testing or suse tumbleweed.

Oliver

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 14:01 +0200, Oliver Burger a écrit :
> Michael Scherer  schrieb am 12.06.2011
> > Proposal 1:
> > 6 months release cycle -> 12 months life cycle
> > ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> > 
> > Proposal 2:
> > 9 months release cycle -> 18 months life cycle
> > ( ~ opensuse and the one we used for Mageia 1 )
> > 
> > Proposal 3:
> > 12 months release cycle -> 24 months life cycle
> > ( Mandriva > 2010.1 )
> That's kind of a hard decison. I don't know if a 6 month cycle would 
> not put too much stress on the dev/packager community. But 12 months 
> are a bit much for the hordes of impatient users usually residing in 
> the forums.
> So I would - for now - prefer option 2, 9 months seeming a reasonable 
> time span.
> 
> Especially since we would always be able to change that cycle to 
> something more fitting.
> 
> As to the "rolling" and the "lts" discussion. I think it's something 
> for the future. We first have to see, how much manpower we really have, 
> to maintain the distro.
> 
> I woul then kind of like the idea of a special rolling repo like 
> debian testing or suse tumbleweed.

Well, has someone looked at what they do ?

Debian testing is not a rolling release for users, but it is a base for
the release. And bigger packages updates are slow to migrate, for
example, there is still iceweael/firefox 3.X
http://packages.debian.org/testing/web/iceweasel . So I am not sure that
it will really bring what people want ( as this is not what it was
designed for in the first place ).

Gentoo model is heavily dependent on sources recompilation on user
workstation so not applicable ( even if this is the closest of what
people could want in term of package management ).

I didn't look at the tumbleweed system, but I fear this is highly
dependent on the Suse workflow, so if someone could do the research to
explain clearly what it does for the next discussion, it would surely
help. ( this also mean that people should keep such research for next
discussion and do not mix with the current one )
-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Wolfgang Bornath]

About the cycles:

The problems with 6-months have been pointed out - my main concern
would be the lack of manpower and the continuous state of
"pre-release", no real room to sit back and contemplate hwat is and
what could be and all the rest. IMHO such a "contemplating" time is
necessary to keep the whole picture in focus.

The problems with 12-months have also been pointed out and I agree
with them (too long out of public focus, too long for the main
userland applications, etc.).

The 9-months seem to be a compromise - but I start to ask why we need
such a fixed statement (which it would be, once published). We need a
schedule for each cycle, that's true. Without a schedule we would
never finish anything. But how about taking 9 months only as a "nice
to meet" target, leaving us the option to set a roadmap after setting
the specs of the next release - we could then go for a 8 or 10 months
roadmap, depending on the specs.

This being said, I am a friend of a rolling release like ArchLinux,
but I fear that our main target group is not up to this. Despite of
having to "burn yet another DVD" as somebody pointed out, the majority
seems to see this as normal and a good way. Of course I may be totally
wrong with this assessment!

-- 
wobo

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thomas Backlund]

Wolfgang Bornath skrev 13.6.2011 15:20:

About the cycles:

The 9-months seem to be a compromise - but I start to ask why we need
such a fixed statement (which it would be, once published). We need a
schedule for each cycle, that's true. Without a schedule we would
never finish anything. But how about taking 9 months only as a "nice
to meet" target, leaving us the option to set a roadmap after setting
the specs of the next release - we could then go for a 8 or 10 months
roadmap, depending on the specs.



This is somewhat like what I had in my mind to write too, but you beat 
me to it :)


It could allow us to adapt a little for upstream releases.
But should we then decide that the limit is +/- 1 month ?

Obviously there will still be people complaining that "you waited 10 
months... if you had extended with ~2 more weeks... "this" or "that"

package would have been available too... and so on


And something not to forget (this is more related to the specs):

If an estimated upstream release of kde/gnome/... seem to fit our
schedule it _must_ be in Cauldron before version freeze so we
actually get some test/qa on it and not try to force it in by
"hey it's released ~x days before final mageia release so it
 must be added" attitude that tends to pop up at every freeze.

--
Thomas

Re: [Mageia-dev] Release cycles proposals, and discussion

[Samuel Verschelde]

Le dimanche 12 juin 2011 22:46:33, Michael Scherer a écrit :
> Hi,
> 
> so , with a little bit delay due to various things ( like everybody
> asking stuff to us on irc on a hourly fashion ( people will I hope
> recognize themselves )), Anne and I have reviewed the various proposals
> made through years during the early period of the distribution, and
> before at Mandriva. We took in account the feedback of people on forum,
> on ml, nd those we have seen during events. We also discussed with
> others distributions developers we know from Opensuse, Fedora, Debian,
> Ubuntu about their release cycle, the choices they made and their
> reasons.

A restitution to us of this overview of the other distros release cycles and 
their choices, reasons, pros and cons would have been great, but I guess it 
would have required much more time to write it. It would have helped 
understand why the final decision you took was to keep the current model (not 
counting the discussion about cycle duration and LTS). I'm not saying that I 
want "rolling release", but beginning the discussion without saying much 
concerning what has been a big discussion some months ago (and still is in the 
forum) feels a bit weird to me. Especially when we kept telling people "wait, 
we will have time to discuss it after Release 1".

> To simplify the discussion, the proposals are all based on the fact that
> 2 or 3 releases could be supported at a time. We could have different
> schemes for that ( LTS every X release ( ubuntu ), different level of
> support ( mandriva )), but as this is a slightly different discussion,
> let's assume 2 supported releases for now, and let's discuss later for
> that ( ie next week, once this one is finished )

I can understand the reason for separating the discussions (simplification), 
but it's hard to give a final opinion concerning the release cycle without 
knowing whether there will be a LTS or not, when you care about the life cycle 
duration. The backports policy also has a great impact to the matter : if we 
manage to make using newer versions of popular software easy without much risk 
nor obligatory need to upgrade, extending the release cycle is easier (I could 
go with 12 months provided we find a way to improve hardware support as part of 
the maintenance).

To take an example concerning the impact of having an LTS release or not : 
- 6 months release cycle + 1 LTS every few releases => ok for me (ubuntu way, 
each intermediate release is an intermediate milestone to the LTS)
- 6 months release cycle, without a LTS => not ok for me, life cycle really 
too short

That said, as a choice has to be made, my vote goes to the compromise proposal 
: around 9 months release cycle (more or less 1 month depending on the amount 
of work to be done, adjustment to a given upstream release, KDE or GNOME for 
example, and marketing calendar considerations).

Best regards

Samuel Verschelde

Re: [Mageia-dev] Release cycles proposals, and discussion

[David Sjölin]

On Mon, Jun 13, 2011 at 2:51 PM, Thomas Backlund  wrote:
> Wolfgang Bornath skrev 13.6.2011 15:20:
>>
>> About the cycles:
>>
>> The 9-months seem to be a compromise - but I start to ask why we need
>> such a fixed statement (which it would be, once published). We need a
>> schedule for each cycle, that's true. Without a schedule we would
>> never finish anything. But how about taking 9 months only as a "nice
>> to meet" target, leaving us the option to set a roadmap after setting
>> the specs of the next release - we could then go for a 8 or 10 months
>> roadmap, depending on the specs.
>>
>
> This is somewhat like what I had in my mind to write too, but you beat me to
> it :)
>
> It could allow us to adapt a little for upstream releases.
> But should we then decide that the limit is +/- 1 month ?
>
> Obviously there will still be people complaining that "you waited 10
> months... if you had extended with ~2 more weeks... "this" or "that"
> package would have been available too... and so on
>
>
> And something not to forget (this is more related to the specs):
>
> If an estimated upstream release of kde/gnome/... seem to fit our
> schedule it _must_ be in Cauldron before version freeze so we
> actually get some test/qa on it and not try to force it in by
> "hey it's released ~x days before final mageia release so it
>  must be added" attitude that tends to pop up at every freeze.

This point and the one above ("if you had extended...") seems to be
arguments for a fixed time release cycle? With a fixed release cycle
no one would question why we didn't wait for the release of a new
gnome/kde/, since waiting the extra
weeks would go against the release cycle. I'm not sure if that is
enough of an argument against having a looser release cycle but... But
then again, I can see the point of having the possibility to be a bit
flexible.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Angelo Naselli]

lunedì 13 giugno 2011 alle 12:07, Ron ha scritto:
> I made another post in a different thread about the way I feel the release 
> cycle should go. 
Sorry i can't see why... couldn't we go on that thread?

Hard to follow, quite long, but maybe easy to summarize at the end of 
discussion.
Oh well ennael and misc have to do the big work to get info from all
input, but please let's try to make their life easier :) At least that is my 
opinion...

> After more thinking I do think that I really have the right idea and here is 
> why...
And please do not post html messages or your ideas is hard to follow as well ;)

Angelo


signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thomas Backlund]

David Sjölin skrev 13.6.2011 16:00:

On Mon, Jun 13, 2011 at 2:51 PM, Thomas Backlund  wrote:

Wolfgang Bornath skrev 13.6.2011 15:20:


About the cycles:

The 9-months seem to be a compromise - but I start to ask why we need
such a fixed statement (which it would be, once published). We need a
schedule for each cycle, that's true. Without a schedule we would
never finish anything. But how about taking 9 months only as a "nice
to meet" target, leaving us the option to set a roadmap after setting
the specs of the next release - we could then go for a 8 or 10 months
roadmap, depending on the specs.



This is somewhat like what I had in my mind to write too, but you beat me to
it :)

It could allow us to adapt a little for upstream releases.
But should we then decide that the limit is +/- 1 month ?

Obviously there will still be people complaining that "you waited 10
months... if you had extended with ~2 more weeks... "this" or "that"
package would have been available too... and so on


And something not to forget (this is more related to the specs):

If an estimated upstream release of kde/gnome/... seem to fit our
schedule it _must_ be in Cauldron before version freeze so we
actually get some test/qa on it and not try to force it in by
"hey it's released ~x days before final mageia release so it
  must be added" attitude that tends to pop up at every freeze.


This point and the one above ("if you had extended...") seems to be
arguments for a fixed time release cycle? With a fixed release cycle
no one would question why we didn't wait for the release of a new
gnome/kde/, since waiting the extra
weeks would go against the release cycle. I'm not sure if that is
enough of an argument against having a looser release cycle but... But
then again, I can see the point of having the possibility to be a bit
flexible.


Well, it was intended to point out the problem with the "flexible" 
approach, and a possible "fix" by deciding some limits to the flexibility.


--
Thomas

Re: [Mageia-dev] Release cycles proposals, and discussion

[magnus]

2011/6/13 Thomas Backlund 

> Wolfgang Bornath skrev 13.6.2011 15:20:
>
>> About the cycles:
>>
>>
>> The 9-months seem to be a compromise - but I start to ask why we need
>> such a fixed statement (which it would be, once published). We need a
>> schedule for each cycle, that's true. Without a schedule we would
>> never finish anything. But how about taking 9 months only as a "nice
>> to meet" target, leaving us the option to set a roadmap after setting
>> the specs of the next release - we could then go for a 8 or 10 months
>> roadmap, depending on the specs.
>>
>>
> This is somewhat like what I had in my mind to write too, but you beat me
> to it :)
>
> It could allow us to adapt a little for upstream releases.
> But should we then decide that the limit is +/- 1 month ?
>
> Obviously there will still be people complaining that "you waited 10
> months... if you had extended with ~2 more weeks... "this" or "that"
> package would have been available too... and so on
>
>
> And something not to forget (this is more related to the specs):
>
> If an estimated upstream release of kde/gnome/... seem to fit our
> schedule it _must_ be in Cauldron before version freeze so we
> actually get some test/qa on it and not try to force it in by
> "hey it's released ~x days before final mageia release so it
>  must be added" attitude that tends to pop up at every freeze.
>
> --
> Thomas
>
>
>
> Let the 9 months as maximum, as a general target.

Make the specs and then the roadmap with a fixed release date and a fixed
enough time for freeze and testing.

If an upstream release brings conflits, that's live.
Main focus should be a stable release for simple users not a pot of the
latest apps

Magnus

Re: [Mageia-dev] Release cycles proposals, and discussion

[Angelo Naselli]

lunedì 13 giugno 2011 alle 15:08, Thomas Backlund ha scritto:
> Well, it was intended to point out the problem with the "flexible" 
> approach, and a possible "fix" by deciding some limits to the flexibility.
If the decision of how much (+X or -X) is taken during the post release
phase (e.g. now in the pre new release working). it's not that problem.
I mean we decide for 10 mo release because gnome (chose that because i like kde 
:p)
is out in 8 months and we'd like to have 2 months testing -that allows a little 
gnome release delay- so from that point on the release plan is fixed at 10 
months.
Next release we could decide for 6 months because no great changes from the 
world
are expected

But i believe it's hard to follow, because every time we should spend
a lot of time discussing for this stuff and that could be harmless...

Angelo


signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Dale Huckeby]

On Mon, 13 Jun 2011, Wolfgang Bornath wrote:


About the cycles:

The problems with 6-months have been pointed out - my main concern
would be the lack of manpower and the continuous state of
"pre-release", no real room to sit back and contemplate hwat is and
what could be and all the rest. IMHO such a "contemplating" time is
necessary to keep the whole picture in focus.

The problems with 12-months have also been pointed out and I agree
with them (too long out of public focus, too long for the main
userland applications, etc.).

The 9-months seem to be a compromise - but I start to ask why we need
such a fixed statement (which it would be, once published). We need a
schedule for each cycle, that's true. Without a schedule we would
never finish anything. But how about taking 9 months only as a "nice
to meet" target, leaving us the option to set a roadmap after setting
the specs of the next release - we could then go for a 8 or 10 months
roadmap, depending on the specs.

This being said, I am a friend of a rolling release like ArchLinux,
but I fear that our main target group is not up to this. Despite of
having to "burn yet another DVD" as somebody pointed out, the majority
seems to see this as normal and a good way. Of course I may be totally
wrong with this assessment!


+1

The consensus so far seems to be:

6 months is too short
12 months is too long
9 months is just about right

and that applies not only to developers having a chance to catch their breath 
between versions, but
users too.  A 6-month turnaround feels like I'm constantly updating, but a 
12-month wait between
versions is like forever.  And as wobo suggests, 9 months need be only an 
average, with a target date
for the next release, taking into account upstream developments, decided on 
after each one.  Also,
the target date should be approximate at first and firmed up only as we get 
closer to release.

spock

Re: [Mageia-dev] Release cycles proposals, and discussion

[lebarhon]

Le 13/06/2011 17:37, Dale Huckeby a écrit :


The consensus so far seems to be:

6 months is too short
12 months is too long
9 months is just about right



You have to choose your public, 6 months is for geeks, 12 months is for 
everybody, these people who aren't IT technicians.
The installation of the new release is always something dangerous and 
worrying because there is always the codecs, the nets or some 
applications without rpm package. Moreover, the hardware evolution is 
slowing down and doesn't need so closed together releases.
I would prefer devs doing more different things less often that devs 
doing more often the same things, that isn't going ahead. Take care 
also, not developing things without any documentation, let this 
specialty to KDE.
I would like also that devs give more importance to the installation by 
update than to the new installation  (too much work to configure, desk, 
mail, ML, nets, backups, specific applications to be installed by hand 
like Geneanet or Rawtherapee...)

For all that, 12 months is already very short.

Lebarhon

Re: [Mageia-dev] Release cycles proposals, and discussion

[Sander Lepik]

13.06.2011 19:51, Ron kirjutas:

I will say my part and I'm gone...

I don't understand why everyone is acting like a rolling release is going to put so much 
strain on the project. What is so hard about developing in one place and allowing the 
updates to trickle down is so hard?


Well.. take Cauldron as a rolling release. It basically is :) So from that point of view.. 
why would we need another rolling release if we already have one? :)


--
Sander

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 18:29 +0200, lebarhon a écrit :
> Le 13/06/2011 17:37, Dale Huckeby a écrit :
> >
> > The consensus so far seems to be:
> >
> > 6 months is too short
> > 12 months is too long
> > 9 months is just about right
> >
> 
> You have to choose your public, 6 months is for geeks, 12 months is for 
> everybody, these people who aren't IT technicians.

That's why Debian, who release every 2 years, is such a hit in the non
geek population.

-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

Op maandag 13 juni 2011 18:51:40 schreef Ron:
> I will say my part and I'm gone...
> I don't understand why everyone is acting like a rolling release is going
> to put so much strain on the project. What is so hard about developing in
> one place and allowing the updates to trickle down is so hard? It almost
> seems to me that you want to ask the opinion of people, but don't want to
> hear. And what is this posting here? I don't even know how to use this
> thing and yet I had to signup to get my voice heard because this is the
> way you want to do things? I don't understand where the whole community
> fits into this here right now, I think I actually say a lot when I say
> that many people want a rolling release It just seems the developers
> will have the way here... Why ask in the first place? Really? I am leaving
> the list and sorry about the HTML in my emails, must be a yahoo thing
> because I did not use HTML... Again I don't know how to use this thing and
> should not have been forced to. I would also say that I, for 1 will not be
> staying if you are going to do a release cycle only... I have loads of
> options if I just want snapshots of what's going on in the Linux world
> Arch gives me so much more and I had hopes of switching to this with a
> release model that made sense... But it seems we won't and we will just
> become yet another XXX release cycle distribution with no clear anything
> that sets us apart from X. On you, I'm gone and thanks for hearing me and
> sorry if my postings were done wrong

complete rolling release would put a QA strain on each of the levels. think 
about it, it's not only the current package being updated, but also the 
combinations with other packages. (AND also all the long time supported 
versions)

This would mean that for each package being release, it'll have to work with 
the current set of other packages, but also with the packages you'll be doing 
next.

if you have this constant level of QA, you need alot of resources (which we 
don't have in QA), and as an extra result, you'll not have the same level of 
QA you could have, when you're doing a release.

it's much easier (as devs) to just choose a subset of packages, and test those 
out.

if you have X QA-devs, and you have 1 subset of versions of packages, you can 
test alot more than if you have several versions of several packages that need 
to work all with each other in almost any combinations...

not to mention that you need an extra step with QA to put a "group" of 
packages from one level to the next...

sorry, but with our current resources, i vote no. i want current resources to 
be used much more efficiently than with a rolling release.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Lee Forest]

I like the idea of releasing when ready. Its done when the team thinks its
ready and not because its being demanded by end users. In Linux Mint this
does alot of good because of having to clean up after ubuntu so much. The
releases are much more stable and polished. The way clement lefabre likes
it. And everyone who uses it is usually satisfied with the end product.
As for being in the news more, we dont have to put out a release just to be
able blog about whats going on in the mageia community and remind everyone
why mageia is special. But this must be the case because theres rarely any
new news posted in mageia blog unless a release is coming out. Thats getting
about as lame as these messages in this mailing list telling people they
sent their message to the mailing list wrong.
What is this distro really about? One upping mandriva and following the same
mechanical routines they did to piss you guys off, or building a real
community distribution of gnu/linux that cares more about keeping in touch
with the community than they do about the way someone new sent a mailing
list message. Theres more to a linux community then mailing lists.
At first I was excited about using mageia, and being a part of the
community. Now im dissappointed because I see how you treat people that are
not on the team. Basically like their opinions
(that you ask for) dont matter, and you are only concerned with the proper
submission of mailing lists messages. Get someone on the blogs and start
talking to the rest of the community the way they deserve. I agree with the
gentleman leaving the mailing list. This isn't worth sticking around for.
Time to remember why you started mageia in the first place.
On Jun 13, 2011 12:51 PM, "Ron"  wrote:
> I will say my part and I'm gone...
> I don't understand why everyone is acting like a rolling release is going
to put so much strain on the project. What is so hard about developing in
one place and allowing the updates to trickle down is so hard?
> It almost seems to me that you want to ask the opinion of people, but
don't want to hear.
> And what is this posting here? I don't even know how to use this thing and
yet I had to signup to get my voice heard because this is the way you want
to do things? I don't understand where the whole community fits into this
here right now, I think I actually say a lot when I say that many people
want a rolling release It just seems the developers will have the way
here... Why ask in the first place? Really?
> I am leaving the list and sorry about the HTML in my emails, must be a
yahoo thing because I did not use HTML... Again I don't know how to use this
thing and should not have been forced to.
> I would also say that I, for 1 will not be staying if you are going to do
a release cycle only... I have loads of options if I just want snapshots of
what's going on in the Linux world Arch gives me so much more and I had
hopes of switching to this with a release model that made sense... But it
seems we won't and we will just become yet another XXX release cycle
distribution with no clear anything that sets us apart from X.
> On you, I'm gone and thanks for hearing me and sorry if my postings were
done wrong

Re: [Mageia-dev] Release cycles proposals, and discussion

[Wolfgang Bornath]

2011/6/13 Lee Forest :
> I like the idea of releasing when ready. Its done when the team thinks its
> ready and not because its being demanded by end users.

Yes. in a world without users this is the best solution. But there are
users. Giving them a "when it's ready" as release date opens doors for
all kinds of questions about this "it's ready", like, "how can you say
it's ready when package foo is not included in it's newest version?"

> As for being in the news more, we dont have to put out a release just to be
> able blog about whats going on in the mageia community and remind everyone
> why mageia is special. But this must be the case because theres rarely any
> new news posted in mageia blog unless a release is coming out.

Oh, you haven't read the blog for some time? The blog is about what we
do, there was a release coming up on June 1st, so during pre-release
time the blog was mainly about the release. But there have been a lot
of other articles, if you miss a certain subject, tell us what you
want to read about.

> Thats getting
> about as lame as these messages in this mailing list telling people they
> sent their message to the mailing list wrong.

Yes, it is a PITA that such messages seem to be needed again and again
to keep the flow of mails readable in a thread.

> At first I was excited about using mageia, and being a part of the
> community. Now im dissappointed because I see how you treat people that are
> not on the team. Basically like their opinions
> (that you ask for) dont matter, and you are only concerned with the proper
> submission of mailing lists messages. Get someone on the blogs and start
> talking to the rest of the community the way they deserve. I agree with the
> gentleman leaving the mailing list. This isn't worth sticking around for.
> Time to remember why you started mageia in the first place.

A community has almost as many different ideas and answers as the
number of people involved. So it may be that one who gives his opinion
gets replies with different opinions - this is called "discussions".

The side question here was why Ron did not write his opinion in the
thread where the rest of the discussion already took place. I would
think this is a reasonable request to make it easier for those who
will have the task of gathering all the opinions - to do just what you
say we are neglecting. The remark about proper posting style was just
a remark to keep the flow of discussion easy to follow, also a
reasonable request.

In an ideal world the person in question would have followed the
remarks and kept up advocating his opinion where all others are
discussing the matter. But if somebody prefers to put such reasonable
requests in front instead, so be it.

-- 
wobo

Re: [Mageia-dev] Release cycles proposals, and discussion

[Anne nicolas]

2011/6/13 Lee Forest 

> I like the idea of releasing when ready. Its done when the team thinks its
> ready and not because its being demanded by end users. In Linux Mint this
> does alot of good because of having to clean up after ubuntu so much. The
> releases are much more stable and polished. The way clement lefabre likes
> it. And everyone who uses it is usually satisfied with the end product.
>
Well this is theway it seems we are going to, some people proposing 9 months
release depending on release dates of main softwares. Anyway whatever the
choice, it's obvious that we will not release final one if  this is not
stable enough.

> As for being in the news more, we dont have to put out a release just to be
> able blog about whats going on in the mageia community and remind everyone
> why mageia is special. But this must be the case because theres rarely any
> new news posted in mageia blog unless a release is coming out. Thats getting
> about as lame as these messages in this mailing list telling people they
> sent their message to the mailing list wrong.
> What is this distro really about? One upping mandriva and following the
> same mechanical routines they did to piss you guys off, or building a real
> community distribution of gnu/linux that cares more about keeping in touch
> with the community than they do about the way someone new sent a mailing
> list message. Theres more to a linux community then mailing lists.
> At first I was excited about using mageia, and being a part of the
> community. Now im dissappointed because I see how you treat people that are
> not on the team. Basically like their opinions
>
Not at all. everyone can subscribe mailing- lists. The point is Mageia is a
young project and we cannot afford for now at least to spread efforts on
forums and mailing-lists and blogs... People still sleep during the night.
It may not be perfect but it's a start. Our points is just to try to get all
opinions in a same place, that's all.

> (that you ask for) dont matter, and you are only concerned with the proper
> submission of mailing lists messages. Get someone on the blogs and start
> talking to the rest of the community the way they deserve. I agree with the
> gentleman leaving the mailing list. This isn't worth sticking around for.
> Time to remember why you started mageia in the first place.
>
Of course we are opened to any of your proposals and ideas and contributions
to improve all this :)

Cheers



> On Jun 13, 2011 12:51 PM, "Ron"  wrote:
> > I will say my part and I'm gone...
> > I don't understand why everyone is acting like a rolling release is going
> to put so much strain on the project. What is so hard about developing in
> one place and allowing the updates to trickle down is so hard?
> > It almost seems to me that you want to ask the opinion of people, but
> don't want to hear.
> > And what is this posting here? I don't even know how to use this thing
> and yet I had to signup to get my voice heard because this is the way you
> want to do things? I don't understand where the whole community fits into
> this here right now, I think I actually say a lot when I say that many
> people want a rolling release It just seems the developers will have the
> way here... Why ask in the first place? Really?
> > I am leaving the list and sorry about the HTML in my emails, must be a
> yahoo thing because I did not use HTML... Again I don't know how to use this
> thing and should not have been forced to.
> > I would also say that I, for 1 will not be staying if you are going to do
> a release cycle only... I have loads of options if I just want snapshots of
> what's going on in the Linux world Arch gives me so much more and I had
> hopes of switching to this with a release model that made sense... But it
> seems we won't and we will just become yet another XXX release cycle
> distribution with no clear anything that sets us apart from X.
> > On you, I'm gone and thanks for hearing me and sorry if my postings were
> done wrong
>



-- 
Anne
http://www.mageia.org

Re: [Mageia-dev] Release cycles proposals, and discussion

[lebarhon]

Le 13/06/2011 19:22, Michael Scherer a écrit :

Le lundi 13 juin 2011 à 18:29 +0200, lebarhon a écrit :

Le 13/06/2011 17:37, Dale Huckeby a écrit :

The consensus so far seems to be:

6 months is too short
12 months is too long
9 months is just about right


You have to choose your public, 6 months is for geeks, 12 months is for
everybody, these people who aren't IT technicians.

That's why Debian, who release every 2 years, is such a hit in the non
geek population.


Funny boy, you get me stuck here !
I would say, this people are geek enough to enjoy installing the same 
release many times.

But believe me, you have to be fluent to enjoy an OS installation.

Re: [Mageia-dev] Release cycles proposals, and discussion

[lebarhon]

From *pmithrandir 
*  
on the forum


On my side, I think mageia should do a "mix" of others idea.

I would say :
- A release every year.
- During this year, a way to update some popular stuff (firefox, chrome, 
libreoffice...)
- During this year also a way to add some new package if needed or if 
there is some instant success for a new software.


Every 3 years, the release is LTS and that mean it would be maintain for 
4 years.


So at the same time, mageia would be in 3 mode :
- The LTS
- The common release
- The cauldron.

With that kind of stuff, you should have no more than one release for 
public at a time, and just one LTS.
If you update main software(we could define a list of no more than 20 
software) people who are crasy about new function, or developper who 
need tham to develop new stuff would be happy.


BTW : I think mailing list are totally outdated and that mageia should 
have a special section in this forum for these discussion, or maybe 
another forum.
It's totally impossible for people who want to participate sometimes to 
follow you emails everydays. It's much faster to read some topic on a 
forum than dozens emails. And your final user should be able to know 
what happen easily. It would be a big + in front of others distributions.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thorsten van Lil]

Am Sonntag, 12. Juni 2011, 22:46:33 schrieb Michael Scherer:
> Proposal 1: 
> 6 months release cycle -> 12 months life cycle
> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> 
> Proposal 2: 
> 9 months release cycle -> 18 months life cycle  
> ( ~ opensuse and the one we used for Mageia 1 )
> 
> Proposal 3: 
> 12 months release cycle -> 24 months life cycle
> ( Mandriva > 2010.1 )

Here is my opinion for this discussion:

The question of the release cycle is conected with the question of the release 
model.

And all proposals we make are restricted by the manpower.

Actally there are two release models active in the linux scene:
1. a static release every X months
2. a rolling release

*But* a mix of both is also possible.

A rolling release has following advantages:
1. the distribution is always up to date (also hardware support) 
2. no re-install over and over again

and following disadvantages
1. it's a heavy load for the devs
2. we can almost only ship vanilla software. No real integration in the 
distribution. With all it's advantages and disadvantages
3. hard to guarantee the stability over the years
4. no inovations within the software (see second disadvantage)

A static releas has the following advantages:
1. less load for the devs
2. easier to support
3. patching is possible
4. most distribution use this release model

and followind disadvantages;
1. no new hardware support
2. no new software versions

This is the current situation.

Some users also wants the a mix of both (also called a light rolling release) 
and combine the advantages as far as possible.
This could look like this:
Bring up a release once a year. The core (kernel, glib, ...) will only get 
minor updates. Apllications like firefox, libreoffice, ... will always be up to 
date (rolling). Maybe also the desktop envirenments could be rolling but this 
is very heavy.

The light rolling releas has the following advantages:
1. the apps are always up to date
2. less load for devs than a full rolling release
3. patching is possible
4. innovations are possible
5. no other distribution is using such a release model
6. the stability is easier to guarentee than rolling release

and following disadvantages
1. more load than static release
2. no new hardware support (could be done via backports if needed)

If such a release model is possible, is up to the devs to decide (I can't 
evaluate the work load). But we have to bear in mind, that we have enough 
range for new inovations. 

Please keep also in mind, that a distribution doesn't or shouldn't exists for 
end in itself. It's just a operating systems and as long as there isn't a real 
need for re-installing we shouldn't. Thus, we shouldn't enforce the user for 
re-installing more than needed.

Hope this wasn't to much text ^^

Greetings,
Thorsten

Re: [Mageia-dev] Release cycles proposals, and discussion

[Renaud MICHEL]

On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
> A rolling release has following advantages:
> 1. the distribution is always up to date (also hardware support) 
> 2. no re-install over and over again

I don't get it why people think a re-install is necessary.
My current computer was installed with mandriva 2007 (don't remember if it 
was .0 or .1), it is now mageia 1 and has been updated to all intermediary 
mdv releases.
Another was not actually installed, an older was installed with mandrake 8.2 
(yes, that is as old as 2002), was updated to each subsequent release, was 
copied on a new computer (create partitions, copy, reinstall grub in MBR, 
check graphic driver, and it worked), it is now running mandriva 2010.2 
(mageia to come) without being reinstalled since.

> Some users also wants the a mix of both (also called a light rolling
> release)  and combine the advantages as far as possible.
> This could look like this:
> Bring up a release once a year. The core (kernel, glib, ...) will only
> get  minor updates. Apllications like firefox, libreoffice, ... will
> always be up to date (rolling). Maybe also the desktop envirenments
> could be rolling but this is very heavy.

If I understood correctly, that is exactly what the backports should 
provide, new versions of programs when possible (no update of half of the 
core system libraries).

cheers
-- 
Renaud Michel

Re: [Mageia-dev] Release cycles proposals, and discussion

[Colin Guthrie]

'Twas brillig, and lebarhon at 13/06/11 20:18 did gyre and gimble:
> BTW : I think mailing list are totally outdated and that mageia should
> have a special section in this forum for these discussion, or maybe
> another forum.
> It's totally impossible for people who want to participate sometimes to
> follow you emails everydays. It's much faster to read some topic on a
> forum than dozens emails. And your final user should be able to know
> what happen easily. It would be a big + in front of others distributions.

This is offtopic here. I completely disagree, incidentally. I need to
read about 30 or 40 different community lists. It's *much* quicker for
me to have a standard UI and a standard way of operating and a standard
look and feel.

Each project having a separate forum, with separate logins, with
separate style and separate features etc. makes for a very hard and time
consuming reading experience. There is a similar argument for why HTML
messages are bad too (consistent style makes everyone's life easier). So
forums are only really good if you only follow a couple of projects or
only follow projects fairly superficially. Mailing lists are better for
the rest of us who are have to follow more projects.

Col

-- 

Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [Mageia-dev] Release cycles proposals, and discussion

[David W. Hodgins]

On Mon, 13 Jun 2011 17:28:04 -0400, Renaud MICHEL  
wrote:


On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :

A rolling release has following advantages:
1. the distribution is always up to date (also hardware support)
2. no re-install over and over again


I don't get it why people think a re-install is necessary.
My current computer was installed with mandriva 2007 (don't remember if it
was .0 or .1), it is now mageia 1 and has been updated to all intermediary
mdv releases.


My currently running install started as Mdv 2009.1, updated via urpmi to
2010.2, then converted to Mageia cauldron during beta 1.

With a little over 4400 packages, the upgrade from one release to the next
takes over 8 hours, on this single core Celeron processor, so even though
it's not an actual re-install, it still feels like one. /usr alone is 13GB.

One possibly annoying part about that, is that there are many rpm packages
where the only obvious change is the version.  I understand that for many
of the packages, they have to be rebuilt due to perl/python/glib version
changes, but anyone who doesn't know that will see what seems like a lot
of unneeded updates.

One con of a rolling release has been demonstrated by Cauldron over the last
few days.  With the perl/gnome updates, it takes a few days for all of the
needed packages to get built.  For a couple of days, running urpmi with
--auto-select wanted to remove most of gnome.  I waited till the needed
packages were available, whereas a less technical user may have ended up
removing key parts of their desktop manager.

Regards, Dave Hodgins

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 14:58 +0200, Samuel Verschelde a écrit :
> Le dimanche 12 juin 2011 22:46:33, Michael Scherer a écrit :
> > Hi,
> > 
> > so , with a little bit delay due to various things ( like everybody
> > asking stuff to us on irc on a hourly fashion ( people will I hope
> > recognize themselves )), Anne and I have reviewed the various proposals
> > made through years during the early period of the distribution, and
> > before at Mandriva. We took in account the feedback of people on forum,
> > on ml, nd those we have seen during events. We also discussed with
> > others distributions developers we know from Opensuse, Fedora, Debian,
> > Ubuntu about their release cycle, the choices they made and their
> > reasons.
> 
> A restitution to us of this overview of the other distros release cycles and 
> their choices, reasons, pros and cons would have been great, but I guess it 
> would have required much more time to write it.

Given that time is already lacking, yes.

But basically, Fedora use 6 months because they want to release often
( Features, First ), according to Mathieu Bridon. That's also why they
have a very agressive update policy ( which caused some issues like
xorg/nvidia breakage, firefox breakage, thunderbird problem ). They do
also have lots of upstream developers paid by RH, who prefer to have
this model to be able to have fast feedback on their software
( especially since almost no one run Rawhide, the equivalent of Cauldron
)

Discussing with Didier Roche, Ubuntu does this because they wanted to
release with gnome, every 6 months. There was discussion 1 year ago
about keeping a minimal distribution ( plateform model ) but it seems it
didn't happened yet. He also confirmed that the pace was quite intense,
letting them push lots of features they develop ( unity, etc ).

According to Vincent Untz, Opensuse moved from 6 months to 8 months
because they feel that 6 months was too much, too frequent. The only
problem is that 1 cycle about 3, they run older software ( like Gnome ),
but that's not a big problem. 

I forgot the Debian stuff, but basically, their release model is a 3
tiered one ( testing, unstable, experimental ), with experimental is
were stuff that can break are uploaded, uploading almost everything,
unstable unstable

For obvious reason, everybody is happy of their choices :)

>  It would have helped 
> understand why the final decision

If this as a final decision, I would not explain and ask to people their
opinion. 

>  you took was to keep the current model (not 
> counting the discussion about cycle duration and LTS). I'm not saying that I 
> want "rolling release", but beginning the discussion without saying much 
> concerning what has been a big discussion some months ago (and still is in 
> the 
> forum) feels a bit weird to me. Especially when we kept telling people "wait, 
> we will have time to discuss it after Release 1".

Well, as I said, we didn't consider the "no release" option. After
looking the document you wrote
( http://mageiacauldron.tuxfamily.org/MageiaReleaseCycle ), the option
"no release" ( I ) was deemed as not realistic, and so was also our
opinion. 

Now, we also took in account the summary and all others were a
combination of release policy, backports policy, and update policy.
Basically, on the release side, it was 1y or 6m, and we have seen that
everybody was only considering theses 2 propositions, hence the proposal
for 9 months ( partially inspired by the suse one ). 

Something that was also apparent in your summary was the need to
backports lots of things on all proposals, the only difference being if
kernel/xorg would be backported or not depending on the release
frequency. 

So after reading this, my conclusion on that was that the release model
would not change much on that part, since basically, either there is a
release often, or your proposal would be to backports lots of things. So
discussing release frequency only would be enough, since the other half
of the discussion is dependent on this one.

Or, as a mathematician would say : 
backport_level(R) = stormi_constant / release_frequency(R) 

( please not that you are now half as famous as Planck, Faraday and
Boltzmann since there is a constant named after you, the other half is
having a institute named after you )

> > To simplify the discussion, the proposals are all based on the fact that
> > 2 or 3 releases could be supported at a time. We could have different
> > schemes for that ( LTS every X release ( ubuntu ), different level of
> > support ( mandriva )), but as this is a slightly different discussion,
> > let's assume 2 supported releases for now, and let's discuss later for
> > that ( ie next week, once this one is finished )
> 
> I can understand the reason for separating the discussions (simplification), 
> but it's hard to give a final opinion concerning the release cycle without 
> knowing whether there will be a LTS or not, when you care about the life 
> cycle 
> 

Re: [Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

Op dinsdag 14 juni 2011 00:08:56 schreef David W. Hodgins:
> On Mon, 13 Jun 2011 17:28:04 -0400, Renaud MICHEL 
 wrote:
> > On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
> >> A rolling release has following advantages:
> >> 1. the distribution is always up to date (also hardware support)
> >> 2. no re-install over and over again
> > 
> > I don't get it why people think a re-install is necessary.
> > My current computer was installed with mandriva 2007 (don't remember if
> > it was .0 or .1), it is now mageia 1 and has been updated to all
> > intermediary mdv releases.
> 
> My currently running install started as Mdv 2009.1, updated via urpmi to
> 2010.2, then converted to Mageia cauldron during beta 1.
> 
> With a little over 4400 packages, the upgrade from one release to the next
> takes over 8 hours, on this single core Celeron processor, so even though
> it's not an actual re-install, it still feels like one. /usr alone is 13GB.

I have a similar machine, but updated through the applet, which means it only 
takes about 1hour and you can work in the main time and reboot when you want. 
i don't understand why users would be expressly wanting rolling release when 
you don't need to reinstall, or "upgrade" in a traditional sense at all...

> One possibly annoying part about that, is that there are many rpm packages
> where the only obvious change is the version.  I understand that for many
> of the packages, they have to be rebuilt due to perl/python/glib version
> changes, but anyone who doesn't know that will see what seems like a lot
> of unneeded updates.
> 
> One con of a rolling release has been demonstrated by Cauldron over the
> last few days.  With the perl/gnome updates, it takes a few days for all
> of the needed packages to get built.  For a couple of days, running urpmi
> with --auto-select wanted to remove most of gnome.  I waited till the
> needed packages were available, whereas a less technical user may have
> ended up removing key parts of their desktop manager.
> 
> Regards, Dave Hodgins

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
> Wolfgang Bornath skrev 13.6.2011 15:20:
> > About the cycles:
> >
> > The 9-months seem to be a compromise - but I start to ask why we need
> > such a fixed statement (which it would be, once published). We need a
> > schedule for each cycle, that's true. Without a schedule we would
> > never finish anything. But how about taking 9 months only as a "nice
> > to meet" target, leaving us the option to set a roadmap after setting
> > the specs of the next release - we could then go for a 8 or 10 months
> > roadmap, depending on the specs.
> >
> 
> This is somewhat like what I had in my mind to write too, but you beat 
> me to it :)
> 
> It could allow us to adapt a little for upstream releases.
> But should we then decide that the limit is +/- 1 month ?

There is 2 problem :
- for release of what software ?
- what if the upstream planning is wrong, and their releases is late
( as it happened when I was a trainee in Mandrakesoft, with xfree being
3 months late and the distribution still shipping a broken pre release )


> Obviously there will still be people complaining that "you waited 10 
> months... if you had extended with ~2 more weeks... "this" or "that"
> package would have been available too... and so on

Yes, there will be. 
So let's be realist, 9 months with +/- 1 month is just 10 months +
people complaining to have 10,5 months.

We will never use the -1 month, because there will always be something
worth waiting.

-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 14:20 +0200, Wolfgang Bornath a écrit :

> The 9-months seem to be a compromise - but I start to ask why we need
> such a fixed statement (which it would be, once published). We need a
> schedule for each cycle, that's true. Without a schedule we would
> never finish anything. But how about taking 9 months only as a "nice
> to meet" target, leaving us the option to set a roadmap after setting
> the specs of the next release - we could then go for a 8 or 10 months
> roadmap, depending on the specs.

As I said to Thomas, we will never use the 8 months option. If we say
"we have selected less features to finish sooner", people will just ask
for more features, and will say "why do you want to finish sooner, I
prefer to have feature and wait 1 month more". 

In fact, the same would go for 9 to 10 if we start to propose the
possibility. 

And deciding that we will decide later is not really deciding. We should
select features based on time needed to implement them and how much time
we can devote, not the contrary especially since no one will ever be
able to give precise timing for anything, so one month of difference
would be difficult to justify.  

And I think we can already decide to release 1 week later if a
release_critical bug appears. Fedora 15 for example was 2 weeks late,
because they changed the release date twice after having seen some
problem (http://fedoraproject.org/wiki/Releases/15/Schedule ).

And we did it more than once at Mandriva.

> This being said, I am a friend of a rolling release like ArchLinux,
> but I fear that our main target group is not up to this. Despite of
> having to "burn yet another DVD" as somebody pointed out, the majority
> seems to see this as normal and a good way. Of course I may be totally
> wrong with this assessment!

Maybe people should maybe start to trust more mgaonline to do upgrade,
there is nothing that pacman does that urpmi don't regarding upgrade,
there is no magic involved : 
- people should test before the release and fill bug reports.

That's the secret behind debian upgrade, people just do lots of tests
for that either automated ( using something like piupart
( http://wiki.debian.org/piuparts ) ), or manual and lots of people do
full system upgrade long before the release ( and not only after ).

-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Sam Bailey]

On Mon, 13 Jun 2011 10:37:25 -0500 (CDT), Dale Huckeby wrote:


+1

The consensus so far seems to be:

6 months is too short
12 months is too long
9 months is just about right

and that applies not only to developers having a chance to catch 
their

breath between versions, but
users too. A 6-month turnaround feels like I'm constantly updating, 
but a

12-month wait between
versions is like forever. And as wobo suggests, 9 months need be only 
an

average, with a target date
for the next release, taking into account upstream developments, 
decided

on after each one. Also,
the target date should be approximate at first and firmed up only as 
we

get closer to release.

spock


+1

9 months seems to create a nice stable base - with enough time to add 
new
developments and breathe between releases (along with kernel updates 
for

new kit).

My suggestion is that for those who want faster access to new versions 
of

apps will be able to create a larger focus on backports for large and
common apps (from cauldron) without taking the focus away from the 9mth
release cycle.

This slightly extra use of backports may also help with the LTS 
proposals.


--
Sam Bailey
(cyprix)

Re: [Mageia-dev] Release cycles proposals, and discussion

[Bruno Cornec]

Michael Scherer said on Tue, Jun 14, 2011 at 01:31:46AM +0200:

> And I think we can already decide to release 1 week later if a
> release_critical bug appears. Fedora 15 for example was 2 weeks late,
> because they changed the release date twice after having seen some
> problem (http://fedoraproject.org/wiki/Releases/15/Schedule ).

I think that the level of flexibility that is really useful. Fixing a
target is nice for all projects. Now, if a blocking point happens, it's
wise to delay a bit.

I personaly find ridiculous the Ubuntu approach to release at fixed
dates, whatever happens, becasue it's 11.04, it should be in April 2011
!! But then their community is just angry because of the lack of
quality due to that.

So maybe what would be interesting is to have something like:
M1-M8: break and fix cauldron with lots of new stuff.
M8-M8.5: freeze period. Only bug fixes or HW support improvements goes 
through or mageia tools. In particular, no new KDE, Gnome, LibreO, FF, 
...
M8.5-M9: test period. Only bugs found there are fixed. As the cauldron
is closed, people have more time to upgrage with an already stabilized
distro, to make it really stable at the 9 months date.

Bruno.
-- 
Open Source & Linux Profession Lead EMEA   / http://opensource.hp.com
HP/Intel/Red Hat Open Source Solutions Initiative  / http://www.hpintelco.net
http://www.HyPer-Linux.org  http://mondorescue.org http://project-builder.org
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 05:04 -0700, Ron a écrit :
> > There is a limited set of options, and as you can see, none of your 
> > idea was not already explored by someone else.
> It has all been done before, in that sense let's just close up shop and call 
> it a day???

Your first argument was "we should not do release, that's what all
others do". I just explained that not doing release is not a new idea.

And maybe I misunderstood your ideas, but if the mere fact that we are
not alone on a segment is a reason to leave it because we cannot
compete, then since by your own word, Arch is doing well, why should we
try to compete too ?
 
In fact, instead of telling what Arch does well, maybe you could start
to say where Arch is not doing well, and how you propose to do things to
do better if you want to convince there is room for another distribution
and room for improvement.

Because if Arch is already fulfilling all your needs, I fail to see what
to do. So the first step would be to explain what Arch is not doing
right if you hope to convince us we can do better.


> > If everything move all days, you cannot :
> > - translate software ( as the string will change every day )
> > - create documentation ( for the same reason )
> > - communicate ( as everything ca be broken at any time )
> > - ensure stability ( as each change can bring unstability )
> 
> > And for user, some do not want to redo training every week for 
> > their users, because libreoffice got updated, because ff 4 just arrived 
> > and 75% of extensions do not work, etc. 
> >
> > In fact, the whole release model is basically what is used all >over the
> > place, from lower level like kernel to higher level like kde. So >you can
> > get lots of feedback on it.
> You are correct on the release model being used everywhere, that fit's 
> development 
> and really there is no other way to do it as it takes time. 
> But really, up stream does have to take time but package maintainers can pull 
> things in pretty fast 
> and make things work.

Being myself a packager, and being a packager since a long time ( like 7
years ), I feel that I have to disagree. While there isn't much breakage
on packaging side, we also suffer from bugs like upstream developers
does, mainly because we use the same software as them. We also develop
our own software ( like the installer, drakxtools, etc ). We also do
work on integration, etc.

And I am a little bit disappointed to learn that my work as a packager
do not take time. I must maybe do it wrong, as it seems to be a real
work.

> I don't understand what's being said here? Are we a community of users 
> or are we just teachers teaching a class? Help with changes is what 
> forums and people are for. 

If people want changes, they either do it themselves, or they wait on
someone else to do. And waiting for someone else to do mean to convince
that someone. And that someone is everybody reading you on the list,
which also mean me.  

Wanting changes has never been sufficient for making them appear. We
wanted to have a change regarding Mandriva, we made it.

> You worried about not being able to keep up with documentation? 
> I suggest you take a look at the Arch wiki, best Linux wiki 
> there is and things change fast... Again, community...

Then I would answer "just look at the ubuntu wiki" to see that the
quality of a wiki is not related to the release model of a
distribution. 

And when I say documentation, I was speaking of something like :
http://doc.mandriva.com/index.php 
or like this :
http://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/index.html

And so, since you didn't answer to the others points I made, shall I
assume they are valid concerns ? 

> > So basically, you suggest that since everybody is already doing 
> > it, this is useless. So the logical conclusion is we should drop 
> > the distribution ?
> No that is not what I'm saying!
>
> What I am saying is that you have 100+/- distributions all going by a 
> release model and only a handful making rolling releases. 

A majority of distributions developers have independently decided to use
a release model, so it is obviously something that is fulfilling their
needs as well as the need of a majority of users, no ?


> There is only one defacto maker of a rolling release and that is Arch, 
> why does this have to be? (Yes I know there are others but Arch is the 
> leader of the pack)

Technically, there is Gentoo, and derived distribution  or Debian
Testing, and I know more people running Gentoo and Debian than Arch
users. I would even say that the *BSD and Slackware are a form of
rolling release, since they have a fixed small base system updated from
time to time, and a evolving upper level with updated software and
others stuff. 

In fact, if we look at the market share, the dominant unix system with a
rolling release model would be mac os X. 

( but I guess that you disagree with the fact that *BSD are a rolling
release, which is yet ano

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le mardi 14 juin 2011 à 02:36 +0200, Bruno Cornec a écrit :
> Michael Scherer said on Tue, Jun 14, 2011 at 01:31:46AM +0200:
> 
> > And I think we can already decide to release 1 week later if a
> > release_critical bug appears. Fedora 15 for example was 2 weeks late,
> > because they changed the release date twice after having seen some
> > problem (http://fedoraproject.org/wiki/Releases/15/Schedule ).
> 
> I think that the level of flexibility that is really useful. Fixing a
> target is nice for all projects. Now, if a blocking point happens, it's
> wise to delay a bit.
> 
> I personaly find ridiculous the Ubuntu approach to release at fixed
> dates, whatever happens, becasue it's 11.04, it should be in April 2011
> !! But then their community is just angry because of the lack of
> quality due to that.

They did a push of 2 months in 2006 ( 6.06 instead of 6.04 for Dapper
Drake ). But I think that was a isolated change, and Mark Shuttleworth
is pushing for keeping schedule. We were praised because we were not
late too :)

> So maybe what would be interesting is to have something like:
> M1-M8: break and fix cauldron with lots of new stuff.
> M8-M8.5: freeze period. Only bug fixes or HW support improvements goes 
> through or mageia tools. In particular, no new KDE, Gnome, LibreO, FF, 
> ...
> M8.5-M9: test period. Only bugs found there are fixed. As the cauldron
> is closed, people have more time to upgrage with an already stabilized
> distro, to make it really stable at the 9 months date.

Well, that's the plan, with the release date come then the decision
about the freeze period, even if we got mixed signals here :
- we want longer freeze because that mean less bugs
- we also see that people always want to have freeze exception because
bugfixing is less fun that adding feature :)

So that warrant also another discussion ( even if I think the current
division is fine, but it could be adapted if the release model is
different ).
-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

Op dinsdag 14 juni 2011 01:02:51 schreef Michael Scherer:
> Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
> > Wolfgang Bornath skrev 13.6.2011 15:20:
> > > About the cycles:
> > > 
> > > The 9-months seem to be a compromise - but I start to ask why we need
> > > such a fixed statement (which it would be, once published). We need a
> > > schedule for each cycle, that's true. Without a schedule we would
> > > never finish anything. But how about taking 9 months only as a "nice
> > > to meet" target, leaving us the option to set a roadmap after setting
> > > the specs of the next release - we could then go for a 8 or 10 months
> > > roadmap, depending on the specs.
> > 
> > This is somewhat like what I had in my mind to write too, but you beat
> > me to it :)
> > 
> > It could allow us to adapt a little for upstream releases.
> > But should we then decide that the limit is +/- 1 month ?
> 
> There is 2 problem :
> - for release of what software ?
> - what if the upstream planning is wrong, and their releases is late
> ( as it happened when I was a trainee in Mandrakesoft, with xfree being
> 3 months late and the distribution still shipping a broken pre release )
> 
> > Obviously there will still be people complaining that "you waited 10
> > months... if you had extended with ~2 more weeks... "this" or "that"
> > package would have been available too... and so on
> 
> Yes, there will be.
> So let's be realist, 9 months with +/- 1 month is just 10 months +
> people complaining to have 10,5 months.
> 
> We will never use the -1 month, because there will always be something
> worth waiting.

actually, the real reason would be more to plan for whatever features you're 
going to implement and the time it takes to do them. if that's 8 months, it's 
8 months, if that's 9 or 10months, that's what it is.

We proved that we can take a planning and follow it through, even the last 
release_critical one was solved _just_in_time_...

imho, we need to decide now on a sort of 9month period, look at what we're 
going to do, then estimating how long it takes (with enough lenience), then 
make a real planning for that, and stick to it, if features are not ready, 
drop those features for next release, and make sure to fix all the 
release_criticals.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le mardi 14 juin 2011 à 03:30 +0200, Maarten Vanraes a écrit :
> Op dinsdag 14 juni 2011 01:02:51 schreef Michael Scherer:
> > Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
> > > Wolfgang Bornath skrev 13.6.2011 15:20:
> > > Obviously there will still be people complaining that "you waited 10
> > > months... if you had extended with ~2 more weeks... "this" or "that"
> > > package would have been available too... and so on
> > 
> > Yes, there will be.
> > So let's be realist, 9 months with +/- 1 month is just 10 months +
> > people complaining to have 10,5 months.
> > 
> > We will never use the -1 month, because there will always be something
> > worth waiting.
> 
> actually, the real reason would be more to plan for whatever features you're 
> going to implement and the time it takes to do them. if that's 8 months, it's 
> 8 months, if that's 9 or 10months, that's what it is.

See my answer to wobo.

> We proved that we can take a planning and follow it through, even the last 
> release_critical one was solved _just_in_time_...

I still think the codecs stuff should not have been release_critical, as
we could do the update later.

> imho, we need to decide now on a sort of 9month period, look at what we're 
> going to do, then estimating how long it takes (with enough lenience), then 
> make a real planning for that, and stick to it, if features are not ready, 
> drop those features for next release, and make sure to fix all the 
> release_criticals.

Great, so can you start by telling how long it will take for the feature
you plan to work on ?
-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thorsten van Lil]

Am Montag, 13. Juni 2011, 23:28:04 schrieb Renaud MICHEL:
> On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
> > A rolling release has following advantages:
> > 1. the distribution is always up to date (also hardware support)
> > 2. no re-install over and over again
> 
> I don't get it why people think a re-install is necessary.
> My current computer was installed with mandriva 2007 (don't remember if it
> was .0 or .1), it is now mageia 1 and has been updated to all intermediary
> mdv releases.

An Upgrade is nearly the same, than reinstalling. The difference is only, that 
you can use your system in the mean time and you are not forced to install the 
missing packages. 

> > This could look like this:
> > Bring up a release once a year. The core (kernel, glib, ...) will only
> > get  minor updates. Apllications like firefox, libreoffice, ... will
> > always be up to date (rolling). Maybe also the desktop envirenments
> > could be rolling but this is very heavy.
> 
> If I understood correctly, that is exactly what the backports should
> provide, new versions of programs when possible (no update of half of the
> core system libraries).
> 

Yes, but Backports are not officially supported and we wouldn't advice new 
users 
to backports normally. It's not what is possible with current repos but what 
we offer for the "normal" user. Because this also influence what release cycle 
we use. If we use such a light rolling release, it's enough to offer one 
release per year or maybe one in 18 month. If we stay with the static release 
model, we are almost "forced" to release every 9 months or earlier.

Greetings,
Thorsten

Re: [Mageia-dev] Release cycles proposals, and discussion

[Oliver Burger]

Thorsten van Lil  schrieb am 14.06.2011
> Am Montag, 13. Juni 2011, 23:28:04 schrieb Renaud MICHEL:
> > I don't get it why people think a re-install is necessary.
> > My current computer was installed with mandriva 2007 (don't
> > remember if it was .0 or .1), it is now mageia 1 and has been
> > updated to all intermediary mdv releases.
> 
> An Upgrade is nearly the same, than reinstalling. The difference is
> only, that you can use your system in the mean time and you are
> not forced to install the missing packages.
And you keep all your precious settings and databases and webroots 
and...
And of couse the software you did unstall outside of the package 
management (proprietary stuff,...).

And a bit to the argument of having to install loads of software at 
the same time: When some basic libraries are upgraded, loads of 
software have to be rebuilt against them, so with the rolling aproach 
you will just get that massive upgrades more often, so where is the 
bonus in it?
If people want to have their software more up to date, use backports, 
if they want to have it even more up to date, use cauldron, but don't 
cry if anything breaks.

Oliver

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thorsten van Lil]

Am 14.06.2011 08:48, schrieb Oliver Burger:

Thorsten van Lil  schrieb am 14.06.2011
 > An Upgrade is nearly the same, than reinstalling. The difference is
 > only, that you can use your system in the mean time and you are
 > not forced to install the missing packages.

And you keep all your precious settings and databases and webroots and...

And of couse the software you did unstall outside of the package
management (proprietary stuff,...).


And a bit to the argument of having to install loads of software at the
same time: When some basic libraries are upgraded, loads of software
have to be rebuilt against them, so with the rolling aproach you will
just get that massive upgrades more often, so where is the bonus in it?


For sure. No matter what release model you want to take, if you want an 
up to date system, you have to update (if this is your counter 
argument). But it's a different if I have to update everything (~3GB) at 
once or if I have to update ~100MB in a week. And it's a difference if I 
have to wait for the software 1/2 year or just a month (if I only want 
to use official supported repos).



If people want to have their software more up to date, use backports


Backports aren't supposed to be for the averaged user and shouldn't be 
used to bring the half of your system up to date. We could rework the 
backports and than officially support them (wouldn't this solve also the 
issue with new packages in mga1?). But than we have almost 2 different 
release models. I'm not sure this is what we want.


Well, Oliver. You are a packager. I'm not. Our menpower is the 
restriction in the whole discussion. If it isn't, we could provide every 
thoughtable release model and cycle and everyone would be happy. But 
that's not the case. So, if a proposal is unworkably please tell us, as 
well as your other concerns.


In my first post I tried to summarize all advantages and disadvantages 
of the different release models. Did I miss a point, than please add it. 
And I'm also fine with a static release model, but I think such a light 
rolling can have a lot of advantages.


Thorsten

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le mardi 14 juin 2011 à 07:55 +0200, Thorsten van Lil a écrit :
> Am Montag, 13. Juni 2011, 23:28:04 schrieb Renaud MICHEL:
> > On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
> > > A rolling release has following advantages:
> > > 1. the distribution is always up to date (also hardware support)
> > > 2. no re-install over and over again
> > 
> > I don't get it why people think a re-install is necessary.
> > My current computer was installed with mandriva 2007 (don't remember if it
> > was .0 or .1), it is now mageia 1 and has been updated to all intermediary
> > mdv releases.
> 
> An Upgrade is nearly the same, than reinstalling. The difference is only, 
> that 
> you can use your system in the mean time and you are not forced to install 
> the 
> missing packages. 

Rolling is just the same as upgrade, except it take X months to do it
with a small change everyday instead of having thing upgraded every X
months.

> > > This could look like this:
> > > Bring up a release once a year. The core (kernel, glib, ...) will only
> > > get  minor updates. Apllications like firefox, libreoffice, ... will
> > > always be up to date (rolling). Maybe also the desktop envirenments
> > > could be rolling but this is very heavy.
> > 
> > If I understood correctly, that is exactly what the backports should
> > provide, new versions of programs when possible (no update of half of the
> > core system libraries).
> > 
> 
> Yes, but Backports are not officially supported and we wouldn't advice new 
> users 
> to backports normally. 

I am sorry, but I fail to follow your reasoning.

Why wouldn't you do a comparison where in one case not recommend
backports, and in the others, recommend them for the whole system ?

If this is for ressource related reasons, why would we have the
ressources in one case and not in the others ? 

And as I said in another mail, if people want to follow arch linux and
do a better job, maybe they should start to explain what are the weak
points of the distribution and then do proposal on stuff that can be
done better instead of asking to copy cat hoping this would be better.

-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thorsten van Lil]

Am 14.06.2011 15:43, schrieb Michael Scherer:

Yes, but Backports are not officially supported and we wouldn't advice new users
>  to backports normally.

I am sorry, but I fail to follow your reasoning.


What I meant is: We can't tell the user to use the backports and if he 
runs in trouble we let him alone and say he shouldn't have used it. If 
we officially support and care for backports, than this is a different case.




And as I said in another mail, if people want to follow arch linux and
do a better job, maybe they should start to explain what are the weak
points of the distribution and then do proposal on stuff that can be
done better instead of asking to copy cat hoping this would be better.


I don't want a full rolling release, because of the listed 
disadvantages. So, if you ask me what is "wrong" with Arch, I would say:
* due to the rolling release, it's nearly vanilla. This doesn't match 
requirements of Mageia

* no innovations (because of vanilla)
* a rolling core system has a negative correlation with it's stability
* heavy work load
* ...

So, I don't ask for a copy of Arch nor any other distribution. I asked 
(although it wasn't my idea) for something new. An compromise: a light 
rolling release.


Further lack of clarity?

Greetings,
Thorsten

Re: [Mageia-dev] Release cycles proposals, and discussion

[Christiaan Welvaart]

On Tue, 14 Jun 2011, Thorsten van Lil wrote:

I don't want a full rolling release, because of the listed disadvantages. So, 
if you ask me what is "wrong" with Arch, I would say:
* due to the rolling release, it's nearly vanilla. This doesn't match 
requirements of Mageia

* no innovations (because of vanilla)
* a rolling core system has a negative correlation with it's stability
* heavy work load
* ...

So, I don't ask for a copy of Arch nor any other distribution. I asked 
(although it wasn't my idea) for something new. An compromise: a light 
rolling release.


This is exactly what release + updates + backports can be, the only 
requirement is enough people to do the work. I do not understand what 
people are saying about backports being "unsupported". IMHO we should 
either have backports that are supported, with fixes for security issues 
and important bugs, or no backports.



Christiaan

Re: [Mageia-dev] Release cycles proposals, and discussion

[Anne nicolas]

2011/6/14 Christiaan Welvaart 

> On Tue, 14 Jun 2011, Thorsten van Lil wrote:
>
>  I don't want a full rolling release, because of the listed disadvantages.
>> So, if you ask me what is "wrong" with Arch, I would say:
>> * due to the rolling release, it's nearly vanilla. This doesn't match
>> requirements of Mageia
>> * no innovations (because of vanilla)
>> * a rolling core system has a negative correlation with it's stability
>> * heavy work load
>> * ...
>>
>> So, I don't ask for a copy of Arch nor any other distribution. I asked
>> (although it wasn't my idea) for something new. An compromise: a light
>> rolling release.
>>
>
> This is exactly what release + updates + backports can be, the only
> requirement is enough people to do the work. I do not understand what people
> are saying about backports being "unsupported". IMHO we should either have
> backports that are supported, with fixes for security issues and important
> bugs, or no backports.
>

I guess because of Mandriva policy. We did provide backports but it was
explicitely said to be unsupported. "Use it at your own risks"
We may have to rewrite  this and make things clear

>
>
>Christiaan
>



-- 
Anne
http://www.mageia.org

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thorsten van Lil]

Am 14.06.2011 17:02, schrieb Anne nicolas:

I do not understand what people are saying about backports being
"unsupported". IMHO we should either have backports that are
supported, with fixes for security issues and important bugs, or no
backports.



I guess because of Mandriva policy. We did provide backports but it was
explicitely said to be unsupported. "Use it at your own risks"


Exactly. If we don't restrict the use of backports on once own risk, I'm 
at least totally happy with it :)


Greetings,
Thorsten

Re: [Mageia-dev] Release cycles proposals, and discussion

[Wolfgang Bornath]

2011/6/14 Anne nicolas :
>
> I guess because of Mandriva policy. We did provide backports but it was
> explicitely said to be unsupported. "Use it at your own risks"
> We may have to rewrite  this and make things clear

Do you mean, just telling people that it is no risk or do you mean a
change which lessens the risk?
As Michael wrote earlier in this thread, if there was the risk to
break the system by low quality of backports then the quality has to
be improved (not his own words but that's how I understood it).

-- 
wobo

Re: [Mageia-dev] Release cycles proposals, and discussion

[Patricia Fraser]

Hi,

2c from the marcomm team...

> Proposal 1: 
> 6 months release cycle -> 12 months life cycle
> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> 
> Proposal 2: 
> 9 months release cycle -> 18 months life cycle  
> ( ~ opensuse and the one we used for Mageia 1 )
> 
> Proposal 3: 
> 12 months release cycle -> 24 months life cycle
> ( Mandriva > 2010.1 )

The only reason for marcomm to take a position is that a release is a
nice hook on which to hang another round of publicity.

I think 9 months is good; it gives us a good amount of time to plan
whatever marketing/comms work is needed for release time, but it's
not too long so we fall out of the public consciousness altogether.

And there are other things about us to publicise besides releases, so
we can fill in the gaps nicely!

Cheers,

-- 
Trish Fraser, JD9R RQ2D
52.4161N,16.9303E
di jun 14 18:04:15 CEST 2011
GNU/Linux 1997-2010 #283226 counter.li.org
andromeda up 0 hour(s), 26 min.
kernel 2.6.38.7-desktop-1.mga
--


signature.asc
Description: PGP signature

Re: [Mageia-dev] Release cycles proposals, and discussion

[Jehan Pagès]

Hi,

On Tue, Jun 14, 2011 at 11:16 PM, Thorsten van Lil  wrote:
> Am 14.06.2011 15:43, schrieb Michael Scherer:
>>>
>>> Yes, but Backports are not officially supported and we wouldn't advice
>>> new users
>>> >  to backports normally.
>>
>> I am sorry, but I fail to follow your reasoning.
>
> What I meant is: We can't tell the user to use the backports and if he runs
> in trouble we let him alone and say he shouldn't have used it. If we
> officially support and care for backports, than this is a different case.

Agreed on this.

>> And as I said in another mail, if people want to follow arch linux and
>> do a better job, maybe they should start to explain what are the weak
>> points of the distribution and then do proposal on stuff that can be
>> done better instead of asking to copy cat hoping this would be better.
>
> I don't want a full rolling release, because of the listed disadvantages.
> So, if you ask me what is "wrong" with Arch, I would say:
> * due to the rolling release, it's nearly vanilla. This doesn't match
> requirements of Mageia
> * no innovations (because of vanilla)
> * a rolling core system has a negative correlation with it's stability
> * heavy work load
> * ...
>
> So, I don't ask for a copy of Arch nor any other distribution. I asked
> (although it wasn't my idea) for something new. An compromise: a light
> rolling release.
>
> Further lack of clarity?

So basically what people call a "light" rolling release in this thread
is a rolling release where packages are tested and integrated? And
what you call a (non-light) rolling release is a development rolling
release (cooker, cauldron…) where packages are just dropped without
prior security checked as fast as they are made available by their
respective authors?

If so, I would say, yeah obviously "light" (I find this naming quite
paradoxical then) is the kind of rolling I would like. And that's not
that new, that's the kind of rolling release in Gentoo (which I found
much more stable than my years of experience in Mandriva, and also
more peaceful as I don't have to fear the big update every 6 months
which will definitely break a lot of small stuffs everywhere at once).

Also yes, I guess this could be simulated using the current backport
system becoming a supported repo (with package getting appropriately
tested and the right integration into the distribution done). I don't
say this is the ideal system, but that can be a first step in the
evolution.
As Anne Nicolas said, this may be only a matter of rewriting the policy.
Yet if doing so, I think it would still need abstraction on UI side at
least. User should not have to deal and even understand concept as
backport, or whatever. On the user point of view, all one should care
is knowing a newer version, which is supposed tested and approved, is
available.

Jehan

Re: [Mageia-dev] Release cycles proposals, and discussion

[Wolfgang Bornath]

2011/6/14 Jehan Pagès :
>On the user point of view, all one should care
> is knowing a newer version, which is supposed tested and approved, is
> available.

A BIG +1

-- 
wobo

Re: [Mageia-dev] Release cycles proposals, and discussion

[Anne nicolas]

2011/6/14 Wolfgang Bornath 

> 2011/6/14 Anne nicolas :
> >
> > I guess because of Mandriva policy. We did provide backports but it was
> > explicitely said to be unsupported. "Use it at your own risks"
> > We may have to rewrite  this and make things clear
>
> Do you mean, just telling people that it is no risk or do you mean a
> change which lessens the risk?
>

not at all


> As Michael wrote earlier in this thread, if there was the risk to
> break the system by low quality of backports then the quality has to
> be improved (not his own words but that's how I understood it).
>
> exactly what I had in mind. Having backports can allow choice between "the
last version of" and "the stable version with which I'm happy
 with". But indeed we need more quality in backport rpms that is policy and
tests.

--
> wobo
>



-- 
Anne
http://www.mageia.org

Re: [Mageia-dev] Release cycles proposals, and discussion

[Ahmad Samir]

On 14 June 2011 09:25, Thorsten van Lil  wrote:
[...]
>
> Backports aren't supposed to be for the averaged user

I've seen this argument more than once in this thread. Why isn't
backports suitable for the average user? that same average user would
install an RPM package from a 3rd party repo or the official web site
of an application in a heartbeat to get a new version of "foo".

The "backports isn't supported" argument means that if backporting a
new package requires a lot of changes then it won't be done, e.g. a
new version of vlc/wine/foo isn't a problem, and if something goes
wrong with the package after a while another backport will be done "if
it's not too much hassle" (e.g. vlc requires a newer ffmpeg to make
some video codec work better but that new ffmpeg is known to break
some other apps then it won't be done).

Packagers don't backport packages they know won't work or are crashy

> and shouldn't be used
> to bring the half of your system up to date.

The word "stable release" implies "doesn't change much"; so a new
version of vlc or wine isn't a problem, but don't put "updating to
GNOME3 or KDE 4.8 in Mageia 1" and "stable" in the same sentence, they
don't fit. such _huge_ changes need to happen in a development
release so that the niggles (which are bound to show up) can be ironed
out so that the distro becomes "stable" and ready to be released
(Mageia 2).

[...]

-- 
Ahmad Samir

Re: [Mageia-dev] Release cycles proposals, and discussion

[Jehan Pagès]

Hi,

On Wed, Jun 15, 2011 at 3:06 AM, Ahmad Samir  wrote:
>> and shouldn't be used
>> to bring the half of your system up to date.
>
> The word "stable release" implies "doesn't change much"; so a new
> version of vlc or wine isn't a problem, but don't put "updating to
> GNOME3 or KDE 4.8 in Mageia 1" and "stable" in the same sentence, they
> don't fit. such _huge_ changes need to happen in a development
> release so that the niggles (which are bound to show up) can be ironed
> out so that the distro becomes "stable" and ready to be released
> (Mageia 2).

I agree this could be a way to do it, which would maybe scare less
some people of the "so-feared rolling", but there still would need a
way to update "simply" one's installation without having to download a
big iso with 90% in it we won't care in an upgrade (where we have
updated most of the other packages, non critical, periodically through
rolling release).

I think it is so insane so many distributions are still with an
"update by CD" logics (even though it is partly modernized with
dropping the iso into an usb stick, or even simply mounting it
directly, I think that is still so backwards that this is the major
advertized way to do it).

Jehan

Re: [Mageia-dev] Release cycles proposals, and discussion

[Frank Griffin]

On 06/14/2011 01:33 PM, Jehan Pagès wrote:

Hi,

This has all been discussed before.  See the thread at 
http://article.gmane.org/gmane.linux.mageia.devel/924

Re: [Mageia-dev] Release cycles proposals, and discussion

[Ahmad Samir]

2011/6/14 Jehan Pagès :
> Hi,
>
> On Wed, Jun 15, 2011 at 3:06 AM, Ahmad Samir  wrote:
>>> and shouldn't be used
>>> to bring the half of your system up to date.
>>
>> The word "stable release" implies "doesn't change much"; so a new
>> version of vlc or wine isn't a problem, but don't put "updating to
>> GNOME3 or KDE 4.8 in Mageia 1" and "stable" in the same sentence, they
>> don't fit. such _huge_ changes need to happen in a development
>> release so that the niggles (which are bound to show up) can be ironed
>> out so that the distro becomes "stable" and ready to be released
>> (Mageia 2).
>
> I agree this could be a way to do it, which would maybe scare less
> some people of the "so-feared rolling", but there still would need a
> way to update "simply" one's installation without having to download a
> big iso with 90% in it we won't care in an upgrade (where we have
> updated most of the other packages, non critical, periodically through
> rolling release).
>
> I think it is so insane so many distributions are still with an
> "update by CD" logics (even though it is partly modernized with
> dropping the iso into an usb stick, or even simply mounting it
> directly, I think that is still so backwards that this is the major
> advertized way to do it).
>
> Jehan
>

You're mixing cards here, I am talking about users running Mageia 1
and using backports, not about full distro upgrade.

A full distro upgrade, e.g. from Mageia 1 to 2, is supported and gets
refined as much as possible before release (the same way the upgrade
from mdv 2010.1 to mga1 was refined to ease the upgrades).

-- 
Ahmad Samir

Re: [Mageia-dev] Release cycles proposals, and discussion

[Angelo Naselli]

In data lunedì 13 giugno 2011 23:44:01, Colin Guthrie ha scritto:
> read about 30 or 40 different community lists. It's much quicker for
> me to have a standard UI and a standard way of operating and a standard
> look and feel.
> 
> Each project having a separate forum, with separate logins, with
> separate style and separate features etc. makes for a very hard and time
> consuming reading experience. There is a similar argument for why HTML
> messages are bad too (consistent style makes everyone's life easier). So
> forums are only really good if you only follow a couple of projects or
> only follow projects fairly superficially. Mailing lists are better for
> the rest of us who are have to follow more projects.
+1
totally agree
-- 
Angelo


signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

Op dinsdag 14 juni 2011 04:08:34 schreef Michael Scherer:
> Le mardi 14 juin 2011 à 03:30 +0200, Maarten Vanraes a écrit :
> > Op dinsdag 14 juni 2011 01:02:51 schreef Michael Scherer:
> > > Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
> > > > Wolfgang Bornath skrev 13.6.2011 15:20:
> > > > Obviously there will still be people complaining that "you waited 10
> > > > months... if you had extended with ~2 more weeks... "this" or "that"
> > > > package would have been available too... and so on
> > > 
> > > Yes, there will be.
> > > So let's be realist, 9 months with +/- 1 month is just 10 months +
> > > people complaining to have 10,5 months.
> > > 
> > > We will never use the -1 month, because there will always be something
> > > worth waiting.
> > 
> > actually, the real reason would be more to plan for whatever features
> > you're going to implement and the time it takes to do them. if that's 8
> > months, it's 8 months, if that's 9 or 10months, that's what it is.
> 
> See my answer to wobo.

i did read that, that's partly a reason why i'm saying this. I think with the 
proper whips things get in order, as we did, and i'm sure that no matter what 
the eventual planning will be (in no matter what project), whippings will 
always be needed, or the said project will never finish at all...

so imho an 8month planning could be possible, or a 7.5month planning. it's 
just that whatever the planning, we should follow it. (pending 
release_critical of course)

> > We proved that we can take a planning and follow it through, even the
> > last release_critical one was solved _just_in_time_...
> 
> I still think the codecs stuff should not have been release_critical, as
> we could do the update later.

that is true, but i still think that would be bad, as:
A) there is still no update afaik (and there have been reviews)
B) even when updates is there, to properly solve it, it also still need some 
work

and eventually, those tainted stuff would likely take 3months or more.

i'm pretty sure some people who review will likely play mp3s...

but ok, that's passed now (but we still need to solve it the right way, let's 
not forget this).

> > imho, we need to decide now on a sort of 9month period, look at what
> > we're going to do, then estimating how long it takes (with enough
> > lenience), then make a real planning for that, and stick to it, if
> > features are not ready, drop those features for next release, and make
> > sure to fix all the release_criticals.
> 
> Great, so can you start by telling how long it will take for the feature
> you plan to work on ?

tbh, in my dayjob, that's often required of me to make an estimation. and if 
we ARE going down that route, then of course i will do it. if you can't even 
try an estimation for the things that you want to do, will you even start 
doing them...

fwiw, i think that 1month before freeze time, it's really clear which features 
will get there in time and which won't.

as an example; i knew right of the bat, that the maintainer db would not be 
ready, and iinm i did warn about that. ok, it's not critical, but it would 
still be very usefull.

if we have a proper version control environment, it should be easy to drop 
feature that aren't going to be in time, and are postponed for next release...

in any case, let us know at the end if an estimation is required, and i'll 
gladly do that

Re: [Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

Op dinsdag 14 juni 2011 18:08:17 schreef Patricia Fraser:
> Hi,
> 
> 2c from the marcomm team...
> 
> > Proposal 1:
> > 6 months release cycle -> 12 months life cycle
> > ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> > 
> > Proposal 2:
> > 9 months release cycle -> 18 months life cycle
> > ( ~ opensuse and the one we used for Mageia 1 )
> > 
> > Proposal 3:
> > 12 months release cycle -> 24 months life cycle
> > ( Mandriva > 2010.1 )
> 
> The only reason for marcomm to take a position is that a release is a
> nice hook on which to hang another round of publicity.
> 
> I think 9 months is good; it gives us a good amount of time to plan
> whatever marketing/comms work is needed for release time, but it's
> not too long so we fall out of the public consciousness altogether.
> 
> And there are other things about us to publicise besides releases, so
> we can fill in the gaps nicely!
> 
> Cheers,

ah yes, i didn't think about this at all... this alone is enough reason to do 
a proper release cycle (instead of the rolling releases which seemed to have 
found a way in this thread)

a +3 is in order here.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Samuel Verschelde]

Le mardi 14 juin 2011 20:00:39, Anne nicolas a écrit :
> 2011/6/14 Wolfgang Bornath 
> 
> > 2011/6/14 Anne nicolas :
> > > I guess because of Mandriva policy. We did provide backports but it was
> > > explicitely said to be unsupported. "Use it at your own risks"
> > > We may have to rewrite  this and make things clear
> > 
> > Do you mean, just telling people that it is no risk or do you mean a
> > change which lessens the risk?
> 
> not at all
> 
> > As Michael wrote earlier in this thread, if there was the risk to
> > break the system by low quality of backports then the quality has to
> > be improved (not his own words but that's how I understood it).
> > 
> exactly what I had in mind. Having backports can allow choice between
> "the last version of" and "the stable version with which I'm happy
>  with". But indeed we need more quality in backport rpms that is policy and
> tests.

Few words could make me more happy about the potential future status of our 
backports. And if backports have a bad reputation among our users, maybe we 
should rename updates to "maintenance updates" and backports to "feature 
updates" ?

Samuel

Re: [Mageia-dev] Release cycles proposals, and discussion

[Patricia Fraser]

> Op dinsdag 14 juni 2011 18:08:17 schreef Patricia Fraser:
> > Hi,
> > 
> > 2c from the marcomm team...
> > 
> > > Proposal 1:
> > > 6 months release cycle -> 12 months life cycle
> > > ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> > > 
> > > Proposal 2:
> > > 9 months release cycle -> 18 months life cycle
> > > ( ~ opensuse and the one we used for Mageia 1 )
> > > 
> > > Proposal 3:
> > > 12 months release cycle -> 24 months life cycle
> > > ( Mandriva > 2010.1 )
> > 
> > The only reason for marcomm to take a position is that a release
> > is a nice hook on which to hang another round of publicity.
> > 
> > I think 9 months is good; it gives us a good amount of time to
> > plan whatever marketing/comms work is needed for release time,
> > but it's not too long so we fall out of the public consciousness
> > altogether.
> > 
> > And there are other things about us to publicise besides
> > releases, so we can fill in the gaps nicely!
> > 
> > Cheers,
> 
> ah yes, i didn't think about this at all... this alone is enough
> reason to do a proper release cycle (instead of the rolling
> releases which seemed to have found a way in this thread)
> 
> a +3 is in order here.

Something else: new users (coming to Mageia for the first time)
*need* a release - they have to have somewhere to start!

Cheers,

-- 
Trish Fraser, JD9R RQ2D
52.4161N,16.9303E
di jun 14 23:18:34 CEST 2011
GNU/Linux 1997-2010 #283226 counter.li.org
andromeda up 5 hour(s), 40 min.
kernel 2.6.38.7-desktop-1.mga
--


signature.asc
Description: PGP signature

Re: [Mageia-dev] Release cycles proposals, and discussion

[Samuel Verschelde]

Le mardi 14 juin 2011 00:50:48, Michael Scherer a écrit :
> 
> Or, as a mathematician would say :
> backport_level(R) = stormi_constant / release_frequency(R)
> 
> ( please not that you are now half as famous as Planck, Faraday and
> Boltzmann since there is a constant named after you, the other half is
> having a institute named after you )
>

Thanks for the fame :) Do you know how I could easily have an institute named 
after me ?

> So no, after doing the math, discussing everything at once is not
> doable.

I could come with less combinations, but probably still too much options :)

Samuel

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le mercredi 15 juin 2011 à 02:33 +0900, Jehan Pagès a écrit :

> >> And as I said in another mail, if people want to follow arch linux and
> >> do a better job, maybe they should start to explain what are the weak
> >> points of the distribution and then do proposal on stuff that can be
> >> done better instead of asking to copy cat hoping this would be better.
> >
> > I don't want a full rolling release, because of the listed disadvantages.
> > So, if you ask me what is "wrong" with Arch, I would say:
> > * due to the rolling release, it's nearly vanilla. This doesn't match
> > requirements of Mageia
> > * no innovations (because of vanilla)
> > * a rolling core system has a negative correlation with it's stability
> > * heavy work load
> > * ...
> >
> > So, I don't ask for a copy of Arch nor any other distribution. I asked
> > (although it wasn't my idea) for something new. An compromise: a light
> > rolling release.
> >
> > Further lack of clarity?
> 
> So basically what people call a "light" rolling release in this thread
> is a rolling release where packages are tested and integrated? And
> what you call a (non-light) rolling release is a development rolling
> release (cooker, cauldron…) where packages are just dropped without
> prior security checked as fast as they are made available by their
> respective authors?

Then light is what arch does. They do tests before migrating. Now, this
can be done faster because the integration is minimal, per philosophy
( ie, you take care of configuration and fixing everything ). Heck, we
could even fully automate that with mdvsys upgrade.

> If so, I would say, yeah obviously "light" (I find this naming quite
> paradoxical then) is the kind of rolling I would like. And that's not
> that new, that's the kind of rolling release in Gentoo (which I found
> much more stable than my years of experience in Mandriva, and also
> more peaceful as I don't have to fear the big update every 6 months
> which will definitely break a lot of small stuffs everywhere at once).

Having lost access to my server for a whole weekend due to a library
upgrade on Gentoo ( some stuff linked to libncurses or libreadline, so
no more shell ), I beg to disagree.

Also, gentoo seems to be updating more slowly nowadays :/ hence the
stability

> Also yes, I guess this could be simulated using the current backport
> system becoming a supported repo (with package getting appropriately
> tested and the right integration into the distribution done). I don't
> say this is the ideal system, but that can be a first step in the
> evolution.

The problem is that the more testing we add, the more ressources it
requires, and the more time it requires. And soon, people will complain
that "packages are too old". 

But if that what people want, we can have the same QA for backports and
for updates. But then I hope there will be many testers.
-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le mercredi 15 juin 2011 à 03:23 +0900, Jehan Pagès a écrit :
> Hi,

> I think it is so insane so many distributions are still with an
> "update by CD" logics (even though it is partly modernized with
> dropping the iso into an usb stick, or even simply mounting it
> directly, I think that is still so backwards that this is the major
> advertized way to do it).

I have updated my laptop from Fedora 11 to 15 using yum ( with all
intermediary release ).
I have updated several debian from sarge to lenny ( like 20 servers )
using apt-get. 
I updated my home server from Mandriva 2006.0 to 2010.2 ( with all
intermediary releases ), and even downgraded it the day I half updated
it to Mageia by error. We also did for the 3 zarb.org servers, among
others.
I updated the laptop of my girlfriend from Hardy Heron to Lucid Lynx.

So where are all those distros that requires to use a cd, since I
successfully avoided it for 4 popular distributions ( Debian, Fedora,
Mandriva, Ubuntu ) ?

If we want to have update with cd, we have the required software. We
just need people to test before the release. 

Now, of course, if people could stop saying "I reinstalled, it is safer"
and just filled bug reports so we can fix the real issue, it would
surely help.
-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le mardi 14 juin 2011 à 23:20 +0200, Samuel Verschelde a écrit :
> Le mardi 14 juin 2011 20:00:39, Anne nicolas a écrit :
> > 2011/6/14 Wolfgang Bornath 
> > 
> > > 2011/6/14 Anne nicolas :
> > > > I guess because of Mandriva policy. We did provide backports but it was
> > > > explicitely said to be unsupported. "Use it at your own risks"
> > > > We may have to rewrite  this and make things clear
> > > 
> > > Do you mean, just telling people that it is no risk or do you mean a
> > > change which lessens the risk?
> > 
> > not at all
> > 
> > > As Michael wrote earlier in this thread, if there was the risk to
> > > break the system by low quality of backports then the quality has to
> > > be improved (not his own words but that's how I understood it).
> > > 
> > exactly what I had in mind. Having backports can allow choice between
> > "the last version of" and "the stable version with which I'm happy
> >  with". But indeed we need more quality in backport rpms that is policy and
> > tests.
> 
> Few words could make me more happy about the potential future status of our 
> backports. And if backports have a bad reputation among our users, maybe we 
> should rename updates to "maintenance updates" and backports to "feature 
> updates" ?

Provided it doesn't requires  changes of the layout of the mirrors, yes.

-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Remco Rijnders]

On Tue, Jun 14, 2011 at 11:43:57PM +0200, Samuel Verschelde wrote:

Le mardi 14 juin 2011 00:50:48, Michael Scherer a écrit :


Or, as a mathematician would say :
backport_level(R) = stormi_constant / release_frequency(R)

( please not that you are now half as famous as Planck, Faraday and
Boltzmann since there is a constant named after you, the other half is
having a institute named after you )



Thanks for the fame :) Do you know how I could easily have an institute named
after me ?


I think huge monetary donations would be the quickest way :)


signature.asc
Description: Digital signature

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thorsten van Lil]

Am Dienstag, 14. Juni 2011, 19:33:00 schrieb Jehan Pagès:
> So basically what people call a "light" rolling release in this thread
> is a rolling release where packages are tested and integrated? And
> what you call a (non-light) rolling release is a development rolling
> release (cooker, cauldron…) where packages are just dropped without
> prior security checked as fast as they are made available by their
> respective authors?

No.
As said in my first mail. Light rolling is, when the core system only gets 
minor updates (no upgrades) and only the apllications get major updates within 
a release.
Full rolling is, when everything will always get the latest version.

Both versions have to be stable as possible.

Regards,
Thorsten

Re: [Mageia-dev] Release cycles proposals, and discussion

[Olav Vitters]

On Sun, Jun 12, 2011 at 10:46:33PM +0200, Michael Scherer wrote:
> Proposal 1: 
> 6 months release cycle -> 12 months life cycle

> Proposal 2: 
> 9 months release cycle -> 18 months life cycle  

> Proposal 3: 
> 12 months release cycle -> 24 months life cycle


Regarding release cycles from a GNOME perspective (so 6 months):
+ 6 months is great for stability; with the various freezes and so on,
  there is not a lot of development going on, so code doesn't become too
  unstable

+ very predictable for everyone (releases + freezes are always in the
same period)

+ more immediate feedback from users

- developers might get too focussed on the 6 months, and development
  might slow down after a few years (happened with GNOME 2.x until 3.0
  was suggested)
  to avoid it you need something like a 'feature map' (plan beforehand
  what to do next and when you think the development would be done;
  don't focus too much on the next version)

- big changes are difficult to do in 6 months; though you can branch and
  so on, it isn't always possible (interaction between modules and so
  on)
  e.g. new GDM or the gnome-vfs -> gvfs switch

- stable release is not supported/looked after for too long

Distribution is of course different from just software, so feel free to
ignore.

There was discussion in the past to make a release every 6 months, but
work on it for 9 (there would be a 3 month overlap where developers had
to work on both branches). E.g. by having a restricted 'Mageia 2' while
still having an 'anything goes' Cauldron.
-- 
Regards,
Olav

Re: [Mageia-dev] Release cycles proposals, and discussion

[andre999]

Samuel Verschelde a écrit :


Le mardi 14 juin 2011 20:00:39, Anne nicolas a écrit :

2011/6/14 Wolfgang Bornath


2011/6/14 Anne nicolas:

I guess because of Mandriva policy. We did provide backports but it was
explicitely said to be unsupported. "Use it at your own risks"
We may have to rewrite  this and make things clear


Right.  Define a (somewhat lower) level of support -- but enough to assure most users that 
backports can be reliable.

Mandriva was defining _corporate_ support, which doesn't apply in a community 
volonteer-based distro.


Do you mean, just telling people that it is no risk or do you mean a
change which lessens the risk?


not at all


As Michael wrote earlier in this thread, if there was the risk to
break the system by low quality of backports then the quality has to
be improved (not his own words but that's how I understood it).


exactly what I had in mind. Having backports can allow choice between
"the last version of" and "the stable version with which I'm happy
  with". But indeed we need more quality in backport rpms that is policy and
tests.


Few words could make me more happy about the potential future status of our
backports. And if backports have a bad reputation among our users, maybe we
should rename updates to "maintenance updates" and backports to "feature
updates" ?

Samuel


Not a bad idea -- even if only as a subtitle :)

--
André

Re: [Mageia-dev] Release cycles proposals, and discussion

[andre999]

Michael Scherer a écrit :


Proposal 1:
6 months release cycle ->  12 months life cycle
( Fedora, Ubuntu, Mandriva<  2010.1&&  Mandriva != 2006.0 )

Proposal 2:
9 months release cycle ->  18 months life cycle
( ~ opensuse and the one we used for Mageia 1 )

Proposal 3:
12 months release cycle ->  24 months life cycle
( Mandriva>  2010.1 )



First, suggest an amended freeze process (idea from recent report of another 
project)
Instead of a freeze on cauldron until everything is ready for the release, we do
1) short freeze on cauldron
2) copy cauldron to pre-release branch, which remains frozen until release
3) immediately unfreeze cauldron.

- we avoid blocking cauldron, while leaving pre-release frozen for bug fixes.
- updates can continue on cauldron.  Bugfixes can be applied to newer versions, if present in 
cauldron, at the same time as corresponding bugfixes in pre-release.

- activities like translation can continue in cauldron, meaning less rush for 
such updates.
- because cauldron is open to changes (virtually) all the time, they don't have to be put off and 
perhaps forgotten.
- the cauldron cycle is extented by the time of the pre-release freeze.  e.g. In a release cycle of 
6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 months.

This allows more time to iron out the pre-release bugs and more time for 
cauldron.
- with the longer pre-release freeze, it may be appropriate to modify somewhat the policy on what 
is accepted during freeze.  (Certain more recent packages or translations, for example.)
- note that we would still have to monitor cauldron to avoid freezing partially implemented complex 
changes, such as a major update of kde or gnome or perl, etc.  But we have to do that now, anyway.




Proposal 1 :
---

My personal preference


Pros:
- better hardware support
- up to date versions / upstream projects (must have for developers)

- coincides with kde/gnome releases
- amended freeze process (outlined above) would lengthen both pre-release freeze time and cauldron 
development time.

A 1-month pre-release freeze would add 1 month to cauldron development time.
This would tend to alleviate the rush of the 6-month release cycle.


- short life cycle

would be alleviated by having periodic long term support releases (lasting at 
least 2 years).



Proposal 2

Pros:

- amended freeze process outlined above would still be advantageous, to a 
lessor degree.


Cons:
- not synchronized with gnome or others that use a 6 month cycle
- potentially release when there isn't much activity (like during Holidays)

- release would not be the same month every year
e.g. 2011 june ; 2012 mar ; 2012 dec ; 2013 sep ; 2014 june ...
so users won't know when to expect a release



Proposal 3 :


Would prefer to avoid this.

Additional cons :
- periodic long-term support releases with a shorter release cycle would be more advantageous, in 
terms of providing long-term stability for the few who would prefer it, while allowing a more 
up-to-date distro.
- requires more updates and backports, in order to keep up to date with upstream, which doesn't 
necessarily reduce workload over shorter release cycles.


my 2 cents :)

--
André

Re: [Mageia-dev] Release cycles proposals, and discussion

[Dick Gevers]

On Tue, 14 Jun 2011 23:43:57 +0200, Samuel Verschelde wrote about Re:
[Mageia-dev] Release cycles proposals, and discussion:

>Thanks for the fame :) Do you know how I could easily have an institute
>named after me ?

With the meteorlogical service of a windy nation (small island group for
instance): Stormi Weather Institute.

Re: [Mageia-dev] Release cycles proposals, and discussion

[John]

On Sat, 18 Jun 2011 08:16:53 +
Dick Gevers wrote:

> On Tue, 14 Jun 2011 23:43:57 +0200, Samuel Verschelde wrote about Re:
> [Mageia-dev] Release cycles proposals, and discussion:
> 
> >Thanks for the fame :) Do you know how I could easily have an institute
> >named after me ?
> 
> With the meteorlogical service of a windy nation (small island group for
> instance): Stormi Weather Institute.

Pitcairn ?

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :
> Michael Scherer a écrit :
> 
> > Proposal 1:
> > 6 months release cycle ->  12 months life cycle
> > ( Fedora, Ubuntu, Mandriva<  2010.1&&  Mandriva != 2006.0 )
> >
> > Proposal 2:
> > 9 months release cycle ->  18 months life cycle
> > ( ~ opensuse and the one we used for Mageia 1 )
> >
> > Proposal 3:
> > 12 months release cycle ->  24 months life cycle
> > ( Mandriva>  2010.1 )
> 
> 
> First, suggest an amended freeze process (idea from recent report of another 
> project)

you can say the name of the project, even if I suspect it to be Fedora.

> Instead of a freeze on cauldron until everything is ready for the release, we 
> do
> 1) short freeze on cauldron
> 2) copy cauldron to pre-release branch, which remains frozen until release
> 3) immediately unfreeze cauldron.
> 
> - we avoid blocking cauldron, while leaving pre-release frozen for bug fixes.
> - updates can continue on cauldron.  Bugfixes can be applied to newer 
> versions, if present in 
> cauldron, at the same time as corresponding bugfixes in pre-release.
> - activities like translation can continue in cauldron, meaning less rush for 
> such updates.
> - because cauldron is open to changes (virtually) all the time, they don't 
> have to be put off and 
> perhaps forgotten.
> - the cauldron cycle is extented by the time of the pre-release freeze.  e.g. 
> In a release cycle of 
> 6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 
> months.
> This allows more time to iron out the pre-release bugs and more time for 
> cauldron.
> - with the longer pre-release freeze, it may be appropriate to modify 
> somewhat the policy on what 
> is accepted during freeze.  (Certain more recent packages or translations, 
> for example.)
> - note that we would still have to monitor cauldron to avoid freezing 
> partially implemented complex 
> changes, such as a major update of kde or gnome or perl, etc.  But we have to 
> do that now, anyway.

So you suggest that in order to help packagers focusing on bug fixing,
that we have them take care of cauldron and the bugfixes for the stable
release ( ie, twice more the load ).

> 
> > Proposal 1 :
> > ---
> My personal preference
> 
> > Pros:
> > - better hardware support
> > - up to date versions / upstream projects (must have for developers)
> - coincides with kde/gnome releases
>
> - amended freeze process (outlined above) would lengthen both pre-release 
> freeze time and cauldron 
> development time.
> A 1-month pre-release freeze would add 1 month to cauldron development time.
> This would tend to alleviate the rush of the 6-month release cycle.

Let's do some math, shall we ?

If people work the same amount of time, with work divided on 2 products,
they must share their time, and usually work less than if they focused
only on one product, unless there is twice the ressources. But I doubt
this will happen for us, so let's assume that ressources are fixed. 

Let say : 
- the freeze period is Y weeks, 
- the time between 2 release is X weeks, 
- people divide their time evenly on both products. 

That's a simplification, but I will come back on that later. Let's also
count the time spent as the metrics for the work, even if man/month is a
wrong unit in software development ( but that's a good enough
approximation for our case, given the highly distributed and
decentralized nature of the work of releasing a distribution ).

So when there is the freeze ( at release(n) time - Y weeks ), we will
have Y weeks of work done on both products ( next release, and cauldron
), so Y/2 weeks on each. We have X -Y weeks once the release(n) is out
( before the next freeze for release(n+1) ), and then again Y/2 weeks.

So for the release (n+1), we spend : 
Y/2 + X - Y + Y/2 
= 2 * Y/2 - Y + X  
= Y - Y + X
= X

So that give X weeks of work. Fascinating, isn't it ?
Now, of course, we can say "what if people do not divide their work in
2 ?" 

So let's call :
- F the time spent on bugfix during the freeze
- C the time spent on cauldron during the freeze

We can assume that :
C + F = Y 

So the equation become :
C + ( X - Y ) + F 
= C + F - Y + X 
= X 

So no matter how you divide the time, you still have the same amount of
time spent overall. 

Now, the real important question is "can we really exchange work done as
part of C for work done as part of F". 

And so "if I do regular packages updates on cauldron at the begining of
the cycle, does it count as bugfixing for the release in the end of the
cycle" ? 

To me, the answer is clearly no. If it was somethig we could exchange,
we would not have to make a freeze in the first place to make sure that
only bugfixes are uploaded in cauldron.

So the only way to maximize the time spent on bugfixes is to have F = Y,
and so C = 0. Ie, do like we do now.

And unless you show that letting people work on cauldron will bring more
ressources , and more than the one we will lose du to people who d

Re: [Mageia-dev] Release cycles proposals, and discussion

[andre999]

Michael Scherer a écrit :


Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :

Michael Scherer a écrit :


Proposal 1:
6 months release cycle ->   12 months life cycle
( Fedora, Ubuntu, Mandriva<   2010.1&&   Mandriva != 2006.0 )

Proposal 2:
9 months release cycle ->   18 months life cycle
( ~ opensuse and the one we used for Mageia 1 )

Proposal 3:
12 months release cycle ->   24 months life cycle
( Mandriva>   2010.1 )



First, suggest an amended freeze process (idea from recent report of another 
project)


you can say the name of the project, even if I suspect it to be Fedora.


I suspected that it might have been Fedora, if it wasn't a summary of the new mozilla process, but 
I couldn't remember.  Just the concept intrigued me.  Which I reflected on for a few weeks.



Instead of a freeze on cauldron until everything is ready for the release, we do
1) short freeze on cauldron
2) copy cauldron to pre-release branch, which remains frozen until release
3) immediately unfreeze cauldron.

- we avoid blocking cauldron, while leaving pre-release frozen for bug fixes.
- updates can continue on cauldron.  Bugfixes can be applied to newer versions, 
if present in
cauldron, at the same time as corresponding bugfixes in pre-release.
- activities like translation can continue in cauldron, meaning less rush for 
such updates.
- because cauldron is open to changes (virtually) all the time, they don't have 
to be put off and
perhaps forgotten.
- the cauldron cycle is extented by the time of the pre-release freeze.  e.g. 
In a release cycle of
6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 
months.
This allows more time to iron out the pre-release bugs and more time for 
cauldron.
- with the longer pre-release freeze, it may be appropriate to modify somewhat 
the policy on what
is accepted during freeze.  (Certain more recent packages or translations, for 
example.)
- note that we would still have to monitor cauldron to avoid freezing partially 
implemented complex
changes, such as a major update of kde or gnome or perl, etc.  But we have to 
do that now, anyway.


So you suggest that in order to help packagers focusing on bug fixing,
that we have them take care of cauldron and the bugfixes for the stable
release ( ie, twice more the load ).


I wouldn't quite put it that way ...


Proposal 1 :
---

My personal preference


Pros:
- better hardware support
- up to date versions / upstream projects (must have for developers)

- coincides with kde/gnome releases

- amended freeze process (outlined above) would lengthen both pre-release 
freeze time and cauldron
development time.
A 1-month pre-release freeze would add 1 month to cauldron development time.
This would tend to alleviate the rush of the 6-month release cycle.


Let's do some math, shall we ?


great :)


If people work the same amount of time, with work divided on 2 products,
they must share their time, and usually work less than if they focused
only on one product, unless there is twice the ressources. But I doubt
this will happen for us, so let's assume that ressources are fixed.


That was my assumption : resources fixed in terms of time spent.
And why would that divide a contributor's focus more than now ?  They would 
just have a choice.
Now during the freeze, someone that wants to contribute to cauldron, but can't or chooses not to 
contribute to pre-release bugfix, is not contributing.

So in practice, we risk to have more time contributed during the freeze.


Let say :
- the freeze period is Y weeks,
- the time between 2 release is X weeks,
- people divide their time evenly on both products.


That wasn't assumed.  Rather that as much time would be spent on bug fixes, etc. in pre-release. 
But having a longer freeze period would likely result in better quality, and certainly less rush.



That's a simplification, but I will come back on that later. Let's also
count the time spent as the metrics for the work, even if man/month is a
wrong unit in software development ( but that's a good enough
approximation for our case, given the highly distributed and
decentralized nature of the work of releasing a distribution ).

So when there is the freeze ( at release(n) time - Y weeks ), we will
have Y weeks of work done on both products ( next release, and cauldron
), so Y/2 weeks on each. We have X -Y weeks once the release(n) is out
( before the next freeze for release(n+1) ), and then again Y/2 weeks.

So for the release (n+1), we spend :
Y/2 + X - Y + Y/2
= 2 * Y/2 - Y + X
= Y - Y + X
= X

So that give X weeks of work. Fascinating, isn't it ?


Not really.  Being my basic assumption :)


Now, of course, we can say "what if people do not divide their work in
2 ?"

So let's call :
- F the time spent on bugfix during the freeze
- C the time spent on cauldron during the freeze

We can assume that :
C + F = Y

So the equation become :
C + ( X - Y ) + F
= C + F - Y + X
= X

So no matter how you divide the time, yo

Re: [Mageia-dev] Release cycles proposals, and discussion

[andre999]

andre999 a écrit :

Michael Scherer a écrit :


Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :

Michael Scherer a écrit :


Proposal 1:
6 months release cycle -> 12 months life cycle
( Fedora, Ubuntu, Mandriva< 2010.1&& Mandriva != 2006.0 )

Proposal 2:
9 months release cycle -> 18 months life cycle
( ~ opensuse and the one we used for Mageia 1 )

Proposal 3:
12 months release cycle -> 24 months life cycle
( Mandriva> 2010.1 )



First, suggest an amended freeze process (idea from recent report of
another project)


you can say the name of the project, even if I suspect it to be Fedora.


I suspected that it might have been Fedora, if it wasn't a summary of
the new mozilla process, but I couldn't remember. Just the concept
intrigued me. Which I reflected on for a few weeks.


Instead of a freeze on cauldron until everything is ready for the
release, we do
1) short freeze on cauldron
2) copy cauldron to pre-release branch, which remains frozen until
release
3) immediately unfreeze cauldron.

- we avoid blocking cauldron, while leaving pre-release frozen for
bug fixes.
- updates can continue on cauldron. Bugfixes can be applied to newer
versions, if present in
cauldron, at the same time as corresponding bugfixes in pre-release.
- activities like translation can continue in cauldron, meaning less
rush for such updates.
- because cauldron is open to changes (virtually) all the time, they
don't have to be put off and
perhaps forgotten.
- the cauldron cycle is extented by the time of the pre-release
freeze. e.g. In a release cycle of
6 months and a pre-release freeze of 1 month, the cauldron cycle
would be 7 months.
This allows more time to iron out the pre-release bugs and more time
for cauldron.
- with the longer pre-release freeze, it may be appropriate to modify
somewhat the policy on what
is accepted during freeze. (Certain more recent packages or
translations, for example.)
- note that we would still have to monitor cauldron to avoid freezing
partially implemented complex
changes, such as a major update of kde or gnome or perl, etc. But we
have to do that now, anyway.


So you suggest that in order to help packagers focusing on bug fixing,
that we have them take care of cauldron and the bugfixes for the stable
release ( ie, twice more the load ).


I wouldn't quite put it that way ...


Proposal 1 :
---

My personal preference


Pros:
- better hardware support
- up to date versions / upstream projects (must have for developers)

- coincides with kde/gnome releases

- amended freeze process (outlined above) would lengthen both
pre-release freeze time and cauldron
development time.
A 1-month pre-release freeze would add 1 month to cauldron
development time.
This would tend to alleviate the rush of the 6-month release cycle.


Let's do some math, shall we ?


great :)


If people work the same amount of time, with work divided on 2 products,
they must share their time, and usually work less than if they focused
only on one product, unless there is twice the ressources. But I doubt
this will happen for us, so let's assume that ressources are fixed.


That was my assumption : resources fixed in terms of time spent.
And why would that divide a contributor's focus more than now ? They
would just have a choice.
Now during the freeze, someone that wants to contribute to cauldron, but
can't or chooses not to contribute to pre-release bugfix, is not
contributing.
So in practice, we risk to have more time contributed during the freeze.


Let say :
- the freeze period is Y weeks,
- the time between 2 release is X weeks,
- people divide their time evenly on both products.


That wasn't assumed. Rather that as much time would be spent on bug
fixes, etc. in pre-release. But having a longer freeze period would
likely result in better quality, and certainly less rush.


That's a simplification, but I will come back on that later. Let's also
count the time spent as the metrics for the work, even if man/month is a
wrong unit in software development ( but that's a good enough
approximation for our case, given the highly distributed and
decentralized nature of the work of releasing a distribution ).

So when there is the freeze ( at release(n) time - Y weeks ), we will
have Y weeks of work done on both products ( next release, and cauldron
), so Y/2 weeks on each. We have X -Y weeks once the release(n) is out
( before the next freeze for release(n+1) ), and then again Y/2 weeks.

So for the release (n+1), we spend :
Y/2 + X - Y + Y/2
= 2 * Y/2 - Y + X
= Y - Y + X
= X

So that give X weeks of work. Fascinating, isn't it ?


Not really. Being my basic assumption :)


Now, of course, we can say "what if people do not divide their work in
2 ?"

So let's call :
- F the time spent on bugfix during the freeze
- C the time spent on cauldron during the freeze

We can assume that :
C + F = Y

So the equation become :
C + ( X - Y ) + F
= C + F - Y + X
= X

So no matter how you divide the time, you still have the sam

Re: [Mageia-dev] Release cycles proposals, and discussion

[Oliver Burger]

andre999  schrieb am 19.06.2011
> Another thought about the amended freeze process.
> Have you noticed how packagers sometimes set off an exchange of 10
> or more emails in attempts to get a package into the release
> during the freeze ?
> The packager wants to submit, but they can't because cauldron is
> frozen.  Maybe if only pre-release were frozen, but cauldron open,
> they would accept submitting to cauldron after only 1 or 2
> exchanges.  They would have the at least partial satisfaction of
> being able to submit their package (instead of waiting, and doing
> something else, probably elsewhere), and others would have been
> releaved of the hassle of dealing with their repeated requests. I
> think that would be more motivating for the packager in question,
> as well as the others involved. And packagers would avoid wasting
> both time and energy.
I don't know. I think most freeze push requests were due to the fact, 
that packagers wanted to have their baby in the release.
Because every packager knows, he only has to wait some days to submit 
it to Cauldron again.
So I don't think any packager would be any the happier by this 
solution.

I have to agree with misc. It would only mean having more work.

Oliver

Re: [Mageia-dev] Release cycles proposals, and discussion

[mammig_linux mammig_linux]

Hello,

The discussion about the "Mageia life cycle" start few days ago on the
forum of the French user community of Mageia (
http://www.mageialinux-online.org/forum/topic-10576+cycle-de-vie-de-mageia.php
: for those who read French )

tTo put all the answers in a nutshell, i will say that users rather
having a new version if that bring big changes.
If the goal is to have a "windows like new version" ( with a new
design, new bugs, new system sounds, "please buy a new printer/scanner
because the new driver will never exist" or "please buy a new computer
because yours is too old/not enough memory"... and no fundamental
changes on the OS ) or something like :
Mageia(n) = Mageia(n-1) - some bugs + new design + some updates
then it's useless to have a new version each x month.

Users wants a good, strong, and long life OS.
Those who like to change the design will be happy if they have
something like "task-newdesign.RPM"
those who like news or updates will be happy with update and backports
repository.

Currently, we just put the suitcase on the floor. ( sorry, bad
translation of a french idiom ;))
The website is "temporary", like the wiki and like a lot of things.
It's hard to find new volunteers... So... We needn't to have the eyes
bigger than the stomach ( sorry, bad translation of a French idiom
O:))
Let's take time for opening the suitcase... having a good multilingual
web site with an easy management, a "not temporary" wiki, correcting
bugs, maybe make more test, create the missing and ask packages,
create stronger teams with more people. Maybe we can think of a new
way of working ( like the idea of "Proofreading" in i18n teams )...

Currently I help anaselli in his project of "educative Mageia
version", maybe it should be great to have others version of Mageia (
like a "server" version for example ).

Greeting,
mammig

PS : I think it's a good thing to have the opinion of users about
that, even if they are not english. I will not make a translation of
each message, I guess a small summary is enough.

2011/6/19 Oliver Burger :
> andre999  schrieb am 19.06.2011
>
>> Another thought about the amended freeze process.
>
>> Have you noticed how packagers sometimes set off an exchange of 10
>
>> or more emails in attempts to get a package into the release
>
>> during the freeze ?
>
>> The packager wants to submit, but they can't because cauldron is
>
>> frozen. Maybe if only pre-release were frozen, but cauldron open,
>
>> they would accept submitting to cauldron after only 1 or 2
>
>> exchanges. They would have the at least partial satisfaction of
>
>> being able to submit their package (instead of waiting, and doing
>
>> something else, probably elsewhere), and others would have been
>
>> releaved of the hassle of dealing with their repeated requests. I
>
>> think that would be more motivating for the packager in question,
>
>> as well as the others involved. And packagers would avoid wasting
>
>> both time and energy.
>
> I don't know. I think most freeze push requests were due to the fact, that
> packagers wanted to have their baby in the release.
>
> Because every packager knows, he only has to wait some days to submit it to
> Cauldron again.
>
> So I don't think any packager would be any the happier by this solution.
>
> I have to agree with misc. It would only mean having more work.
>
> Oliver

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le samedi 18 juin 2011 à 23:49 -0400, andre999 a écrit :
> Michael Scherer a écrit :
> >
> > Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :
> >> Michael Scherer a écrit :

> > If people work the same amount of time, with work divided on 2 products,
> > they must share their time, and usually work less than if they focused
> > only on one product, unless there is twice the ressources. But I doubt
> > this will happen for us, so let's assume that ressources are fixed.
> 
> That was my assumption : resources fixed in terms of time spent.
> And why would that divide a contributor's focus more than now ? 
>  They would just have a choice.

So before, the choice is between :
- not doing anything
- bugfixing

After your proposal, there is :
- not doing anything
- bugfixing
- uploading new stuff to cauldron 

And you fail to see how it divert focus ?

> Now during the freeze, someone that wants to contribute to cauldron, but 
> can't or chooses not to 
> contribute to pre-release bugfix, is not contributing.
> So in practice, we risk to have more time contributed during the freeze.

My own experience tell the contrary, but maybe you should ask to Anne
her opinion if you do not believe me, or to others people who did
distribution releases ( and not software releases, which is slightly
different, mainly because there is less  ).

> > Now, of course, we can say "what if people do not divide their work in
> > 2 ?"
> >
> > So let's call :
> > - F the time spent on bugfix during the freeze
> > - C the time spent on cauldron during the freeze
> >
> > We can assume that :
> > C + F = Y
> >
> > So the equation become :
> > C + ( X - Y ) + F
> > = C + F - Y + X
> > = X
> >
> > So no matter how you divide the time, you still have the same amount of
> > time spent overall.
> 
> As I assumed :)

No.
"the cauldron cycle is extented by the time of the pre-release freeze.
e.g. In a release cycle of 6 months and a pre-release freeze of 1 month,
the cauldron cycle would be 7 months."

The cauldron cycle would be 7 months just on the calendar, but 6 months
worth of work, as demonstrated. 

"A 1-month pre-release freeze would add 1 month to cauldron development
time."

That's the same, you do not add real months, just months on the
calendar.

> > Now, the real important question is "can we really exchange work done as
> > part of C for work done as part of F".
> >
> > And so "if I do regular packages updates on cauldron at the begining of
> > the cycle, does it count as bugfixing for the release in the end of the
> > cycle" ?
> >
> > To me, the answer is clearly no. If it was somethig we could exchange,
> > we would not have to make a freeze in the first place to make sure that
> > only bugfixes are uploaded in cauldron.
> >
> > So the only way to maximize the time spent on bugfixes is to have F = Y,
> > and so C = 0. Ie, do like we do now.
> 
> I really don't follow this line of reasoning.
> The focus on bug fixes starts with the freeze.  So a longer freeze would give 
> more time to focus on 
> bug fixes.

The focus on bugfixing start with version freeze, since what introduce
problem is various changes, and new versions of softwares usually bring
new changes. Then we block all uploads except bug fixes, and then all
uploads unless very serious bug fixes ( ie, release blocker ). So the
focus start much before the last freeze, and you are quite unclear.

> > And unless you show that letting people work on cauldron will bring more
> > ressources , and more than the one we will lose du to people who do not
> > want to work on bugfixes and the release, I doubt this will change.
> 
> Ok.  Obviously I need to clarify my point of view.
> Firstly, my assumption was that at least as much time would be spent on bug 
> fixing during the 
> longer freeze, but being less rushed, would tend to produce better quality 
> results.  (And less 
> aggravation for ennael)  (That is certainly how it works in the non-libre 
> world.)

You do not say much how you extend the freeze to be longer, nor even
that the freeze appear sooner, reread your mail. Nor what kind of freeze
would it be.

The only mention of the duration of the freeze is :
"A 1-month pre-release freeze would add 1 month to cauldron development
time."

The version freeze started on 20 april
( https://mageia.org/pipermail/mageia-dev/20110419/004066.html ), which
is more than 1 month. The release freeze was on 14 may, which is 2
weeks. 

Given that the version freeze is when we start to ask to people to focus
on bugfixes and when we prevent packagers from uploading newer versions
of packages, the proposed 1 month pre-release freeze is unclear and
unexplained.


> I don't see how having the choice between contributing to pre-release or 
> cauldron during the freeze 
> will lead to us loosing _any_ contributors.

We do not lose contributors, we lose the work of people that prefer to
work on cauldron by uploading new versions rather than bug fixing, and
from people that will prefer to t

Re: [Mageia-dev] Release cycles proposals, and discussion

[andre999]

Michael Scherer a écrit :


Le samedi 18 juin 2011 à 23:49 -0400, andre999 a écrit :

Michael Scherer a écrit :


Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :

Michael Scherer a écrit :



If people work the same amount of time, with work divided on 2 products,
they must share their time, and usually work less than if they focused
only on one product, unless there is twice the ressources. But I doubt
this will happen for us, so let's assume that ressources are fixed.


That was my assumption : resources fixed in terms of time spent.
And why would that divide a contributor's focus more than now ?
  They would just have a choice.


So before, the choice is between :
- not doing anything
- bugfixing

- or doing something elsewhere.


After your proposal, there is :
- not doing anything
- bugfixing
- uploading new stuff to cauldron

And you fail to see how it divert focus ?


We have to remember that packager time is not an ubiquitous resource.  If a packager cannot use 
their time efficiently during freeze, they have incentive to contribute their time elsewhere.  It 
is just human nature.  Admittedly this is more likely to affect packagers with less broad-based 
skills, but such packagers do not make insignificant contributions.
As far as diverting focus, does the existance of many distros, providing much more choice, divert 
focus ?  Likely to some extent, but not many packagers contribute to 4 to 6 distros and support in 
the order of 1000 packages.  That's more the exception, for packagers with exceptional skills.



Now during the freeze, someone that wants to contribute to cauldron, but can't 
or chooses not to
contribute to pre-release bugfix, is not contributing.
So in practice, we risk to have more time contributed during the freeze.


My own experience tell the contrary, but maybe you should ask to Anne
her opinion if you do not believe me, or to others people who did
distribution releases ( and not software releases, which is slightly
different, mainly because there is less  ).


Until we try it, we don't know how much effect it will have.  To the best of my knowledge 
Mandrake/Mandriva and certainly Mageia has not tried this approach.  We are both working on 
conjectures, and we can't know until we (or some other distro with similar resources) tries it.
I find it difficult to believe that it will have a negative effect.  And I think it would be useful 
to try it early in the development of Mageia.
Even experienced programmers, who have to support different versions of the same software, run into 
cases where it is very convient -- and more efficient -- to do parallel updates for example.  I run 
into that often enough myself.



Now, of course, we can say "what if people do not divide their work in
2 ?"

So let's call :
- F the time spent on bugfix during the freeze
- C the time spent on cauldron during the freeze

We can assume that :
C + F = Y

So the equation become :
C + ( X - Y ) + F
= C + F - Y + X
= X

So no matter how you divide the time, you still have the same amount of
time spent overall.


As I assumed :)


No.
"the cauldron cycle is extented by the time of the pre-release freeze.
e.g. In a release cycle of 6 months and a pre-release freeze of 1 month,
the cauldron cycle would be 7 months."


Agreed.  I've already said that.


The cauldron cycle would be 7 months just on the calendar, but 6 months
worth of work, as demonstrated.

"A 1-month pre-release freeze would add 1 month to cauldron development time."

That's the same, you do not add real months, just months on the calendar.


As I said, my basic assumption that the same number of packager hours are contributed.  Certain 
factors suggest that one could expect somewhat more time contributed, and a number of others that 
the time would be used more efficiently.  Nothing suggests that less time would be available.



Now, the real important question is "can we really exchange work done as
part of C for work done as part of F".

And so "if I do regular packages updates on cauldron at the begining of
the cycle, does it count as bugfixing for the release in the end of the
cycle" ?

To me, the answer is clearly no. If it was somethig we could exchange,
we would not have to make a freeze in the first place to make sure that
only bugfixes are uploaded in cauldron.

So the only way to maximize the time spent on bugfixes is to have F = Y,
and so C = 0. Ie, do like we do now.


I really don't follow this line of reasoning.
The focus on bug fixes starts with the freeze.  So a longer freeze would give 
more time to focus on
bug fixes.


The focus on bugfixing start with version freeze, since what introduce
problem is various changes, and new versions of softwares usually bring
new changes. Then we block all uploads except bug fixes, and then all
uploads unless very serious bug fixes ( ie, release blocker ). So the
focus start much before the last freeze, and you are quite unclear.


It terms of freeze, I'm referring to the first fr

Re: [Mageia-dev] Release cycles proposals, and discussion

[andre999]

andre999 a écrit :

Michael Scherer a écrit :


Le samedi 18 juin 2011 à 23:49 -0400, andre999 a écrit :

Michael Scherer a écrit :


Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :

Michael Scherer a écrit :



If people work the same amount of time, with work divided on 2
products,
they must share their time, and usually work less than if they focused
only on one product, unless there is twice the ressources. But I doubt
this will happen for us, so let's assume that ressources are fixed.


That was my assumption : resources fixed in terms of time spent.
And why would that divide a contributor's focus more than now ?
They would just have a choice.


So before, the choice is between :
- not doing anything
- bugfixing

- or doing something elsewhere.


After your proposal, there is :
- not doing anything
- bugfixing
- uploading new stuff to cauldron

And you fail to see how it divert focus ?


We have to remember that packager time is not an ubiquitous resource. If
a packager cannot use their time efficiently during freeze, they have
incentive to contribute their time elsewhere. It is just human nature.
Admittedly this is more likely to affect packagers with less broad-based
skills, but such packagers do not make insignificant contributions.
As far as diverting focus, does the existance of many distros, providing
much more choice, divert focus ? Likely to some extent, but not many
packagers contribute to 4 to 6 distros and support in the order of 1000
packages. That's more the exception, for packagers with exceptional skills.


Now during the freeze, someone that wants to contribute to cauldron,
but can't or chooses not to
contribute to pre-release bugfix, is not contributing.
So in practice, we risk to have more time contributed during the freeze.


My own experience tell the contrary, but maybe you should ask to Anne
her opinion if you do not believe me, or to others people who did
distribution releases ( and not software releases, which is slightly
different, mainly because there is less ).


Until we try it, we don't know how much effect it will have. To the best
of my knowledge Mandrake/Mandriva and certainly Mageia has not tried
this approach. We are both working on conjectures, and we can't know
until we (or some other distro with similar resources) tries it.
I find it difficult to believe that it will have a negative effect. And
I think it would be useful to try it early in the development of Mageia.
Even experienced programmers, who have to support different versions of
the same software, run into cases where it is very convient -- and more
efficient -- to do parallel updates for example. I run into that often
enough myself.


Now, of course, we can say "what if people do not divide their work in
2 ?"

So let's call :
- F the time spent on bugfix during the freeze
- C the time spent on cauldron during the freeze

We can assume that :
C + F = Y

So the equation become :
C + ( X - Y ) + F
= C + F - Y + X
= X

So no matter how you divide the time, you still have the same amount of
time spent overall.


As I assumed :)


No.
"the cauldron cycle is extented by the time of the pre-release freeze.
e.g. In a release cycle of 6 months and a pre-release freeze of 1 month,
the cauldron cycle would be 7 months."


Agreed. I've already said that.


The cauldron cycle would be 7 months just on the calendar, but 6 months
worth of work, as demonstrated.

"A 1-month pre-release freeze would add 1 month to cauldron
development time."

That's the same, you do not add real months, just months on the calendar.


As I said, my basic assumption that the same number of packager hours
are contributed. Certain factors suggest that one could expect somewhat
more time contributed, and a number of others that the time would be
used more efficiently. Nothing suggests that less time would be available.


Now, the real important question is "can we really exchange work
done as
part of C for work done as part of F".

And so "if I do regular packages updates on cauldron at the begining of
the cycle, does it count as bugfixing for the release in the end of the
cycle" ?

To me, the answer is clearly no. If it was somethig we could exchange,
we would not have to make a freeze in the first place to make sure that
only bugfixes are uploaded in cauldron.

So the only way to maximize the time spent on bugfixes is to have F
= Y,
and so C = 0. Ie, do like we do now.


I really don't follow this line of reasoning.
The focus on bug fixes starts with the freeze. So a longer freeze
would give more time to focus on
bug fixes.


The focus on bugfixing start with version freeze, since what introduce
problem is various changes, and new versions of softwares usually bring
new changes. Then we block all uploads except bug fixes, and then all
uploads unless very serious bug fixes ( ie, release blocker ). So the
focus start much before the last freeze, and you are quite unclear.


It terms of freeze, I'm referring to the first freeze for the 

Re: [Mageia-dev] Release cycles proposals, and discussion

[andre999]

sorry, I forgot to strip off everything at the beginning
... so if you could ignore the previous email

andre999 a écrit :


I'd like to consolidate and clarify my ideas regarding an amended freeze
process, taking into account the critiques.
That is, that for the freeze which leads to the release, that we
1) freeze cauldron
2) copy caudron to a pre-release branch, which remains frozen, and will
become the release
3) then unfreeze cauldron.

- this would be the first freeze, when the big focus starts on bug
fixes. The sequence of freeze types would not (necessarily) change.
- although cauldron would be unfrozen, the idea is to allow small
contributions, such as new packages, new versions not accepted into
pre-release, etc.
But not to have major changes which could break cauldron, as the main
contributors will be focused, as now, on pre-release, and major breaks
in cauldron should be quickly fixed.
So that cauldron would not be not totally blocked to all non-release
contributions during the freeze period (which was about 6 weeks for mga1).
- It would probably be very useful to have an explicit policy limiting
the nature of contributions to cauldron during the pre-release period.
We could even encourage the importing of new packages during this period.
- Caudron unfrozen would also allow less experienced packagers to
contribute to cauldron at times when they are unable to usefully
contribute to pre-release. For instance, such packagers could depend
heavily on the advice of others for bug fixes, but could be advanced
enough to import new packages or new versions to cauldron on their own.
(idea from comment on mageia1_postmortum wiki page.)
- This process assumes that the freeze period would be extended (by
maybe 2 weeks) to give more time to fix bugs, relieving some of the
pressure. Those less able to efficiently contribute to pre-release could
contribute to cauldron, so the extra time would be needed.
- If this amended process allows us to more easily make the release, and
thus keep the release cycle of 6 months, we would have the advantage of
keeping in sync with upstream for major projects such as kde and gnome.
But if not enough for keeping the 6-month release cycle, if it helps,
let's use it if we go with a longer cycle.
- In no way is the idea to produce parallel development streams as is
now done by mozilla for firefox.

Hopefully this summary helps.
(BTW, it is still Wednesday in my time zone.)
On the road to mga2 ... :)



--
André

Re: [Mageia-dev] Release cycles proposals, and discussion - messages from the forum

[lebarhon]

by *corbintech 
* » 
Jun 13th, '11, 22:12
I quit the ML because I was not doing it right (never used a list like 
that before).


So if I may, I will post here what somebody responded to me and write my 
response here.


   complete rolling release would put a QA strain on each of the
   levels. think
   about it, it's not only the current package being updated, but also the
   combinations with other packages. (AND also all the long time supported
   versions)

   This would mean that for each package being release, it'll have to
   work with
   the current set of other packages, but also with the packages you'll
   be doing
   next.

   if you have this constant level of QA, you need alot of resources
   (which we
   don't have in QA), and as an extra result, you'll not have the same
   level of
   QA you could have, when you're doing a release.

   it's much easier (as devs) to just choose a subset of packages, and
   test those
   out.

   if you have X QA-devs, and you have 1 subset of versions of
   packages, you can
   test alot more than if you have several versions of several packages
   that need
   to work all with each other in almost any combinations...

   not to mention that you need an extra step with QA to put a "group" of
   packages from one level to the next...

   sorry, but with our current resources, i vote no. i want current
   resources to
   be used much more efficiently than with a rolling release.



Why do we keep acting like there is no other way to pool resources? I 
have never helped develop in any way, teach me something and I'll lend a 
hand... Others may do the same.. ASK!


QA comes from testing... Test... Test... And test more... To make sure 
what you have works and works well. Let's change up my idea a bit and 
satisfy everyone... Let's compromise...


How about Cooker (or whatever you call) rolls to rolling (can be very 
stable???!!!) with release cycle releases based on a snapshot of either 
of the rolling models and supported for X amount of time? This could 
make those whom want a rolling release model happy and those whom want a 
release cycle.


Would this be hard? I don't really think so as development is already 
based on a rolling model (cooker or whatever), all that will have to be 
done is packages roll down the line. I seen in the start of all these 
talks you wanted to support 3 structures of systems... Here they are!


What about this? Get the community involved!

Re: [Mageia-dev] Release cycles proposals, and discussion - messages from the forum

[lebarhon]

by *roadrunner 
* » 
Jun 13th, '11, 22:24


   pmithrandir wrote:BTW : I think mailing list are totally outdated
   and that mageia should have a special section in this forum for
   these discussion, or maybe another forum.
   It's totally impossible for people who want to participate sometimes
   to follow you emails everydays. It's much faster to read some topic
   on a forum than dozens emails. And your final user should be able to
   know what happen easily. It would be a big + in front of others
   distributions.

Well said, I couldn't have put it better mysef and I agree 100%

.\\artin

Re: [Mageia-dev] Release cycles proposals, and discussion - messages from the forum

[Colin Guthrie]

'Twas brillig, and lebarhon at 14/06/11 11:42 did gyre and gimble:
> by *roadrunner
> * »
> Jun 13th, '11, 22:24
> 
> pmithrandir wrote:BTW : I think mailing list are totally outdated
> and that mageia should have a special section in this forum for
> these discussion, or maybe another forum.
> It's totally impossible for people who want to participate sometimes
> to follow you emails everydays. It's much faster to read some topic
> on a forum than dozens emails. And your final user should be able to
> know what happen easily. It would be a big + in front of others
> distributions.
> 
> Well said, I couldn't have put it better mysef and I agree 100%

This email is not about release cycles and peoples opinions of the
options presented for discussion.

While it's maybe a valid feeling that may require it's own discussion
(I've already explained why I believe the exact opposite and that the
use of forums for projects would seriously limit my ability to
participate), it's not part of this discussion per se.

Col


-- 

Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [Mageia-dev] Release cycles proposals, and discussion - messages from the forum

[Lee Forest]

I agree. Mailing lists are messy and hard to follow. And sometimes the only
response you get is about how you sent the message wrong. I bet more people
would use the forums. Only a couple people so far are hooked on mailing
lists. Im seeing more and more comments coming in about this. forums would
at least would allow people to follow one version of the discussion instead
of everyone posting a copy with their reply. And its easier to review past
messages without sorting through all your emails that practically spam your
box. People can subscribe to the topics they actually want, and browse the
messages at their leisure. mailing list might work best for a couple people
but is it worth inconveniencing the rest of the word because you are a die
hard mailing list user?
On Jun 14, 2011 6:42 AM, "lebarhon"  wrote:
> by *roadrunner
> * »
> Jun 13th, '11, 22:24
>
> pmithrandir wrote:BTW : I think mailing list are totally outdated
> and that mageia should have a special section in this forum for
> these discussion, or maybe another forum.
> It's totally impossible for people who want to participate sometimes
> to follow you emails everydays. It's much faster to read some topic
> on a forum than dozens emails. And your final user should be able to
> know what happen easily. It would be a big + in front of others
> distributions.
>
> Well said, I couldn't have put it better mysef and I agree 100%
>
> .\\artin

Re: [Mageia-dev] Release cycles proposals, and discussion - messages from the forum

[Wolfgang Bornath]

I've been around when there were no forums, just news groups and
mailing lists. And I have been posting in forums since they were
invented (even in early CompuServe times). What I found out over all
these years:

1. All these reasons which have been posted here and in previous
threads since the beginning of Mageia communication are the very same
reasons (in favor and against both platforms) which have been posted
10 years ago and zillions of times in between - nothing has changed
one little bit on either side.

2. If you handle both platforms right there is no difference at all
between them (except that mailing lists are easier to handle in a
text-only environment, which is quite rare these days)

So, IMHO this discussion is as meaningless as the famous/infamous vi
vs emacs discussions of way back when.

-- 
wobo