Mageia Rolling Release please

[masinick]

I am a fan of some kind of perpetual release, regardless of what we choose to call it or how we categorize it. I am fine if that approach is a Cooker, coupled with a release strategy, but some kind of tiered approach, making instantly new packages available, tested to some degree, put into a testing repository, thoroughly tested, and then packaged into a periodic stable release is a strategy that makes a lot of sense. It is a lot of work to set up and maintain, but it is a proven approach that has worked well elsewhere, and it is worthy of consideration and discussion before locking in on a long term approach.

[teaage]

This is already the 3. thread about rolling release here. The thread on the ml increase the volume of the bible.
Isn't that enough to discuss?

Regards,
TeaAge

[teaage]

Args,
sorry. Haven't noticed that this was posted in the main thread. Thought it was a new one. So please do me a favor and ignore my post above, as it seems to be impossible to edit or delete it's own posts?!

Regards,
TeaAge

EDIT:
This one I can edit (and delete) but the other post not? Confusing ...

[wobo]

EDIT:
This one I can edit (and delete) but the other post not? Confusing ...

See this discussion: viewtopic.php?f=18&t=134

[rtb]

My thoughts:

I am new to mageai but have been using Ubuntu for a while.
My main consideration is stability. I chose Ubuntu because of the LTS (Long Term Support) version.
I run my family and friend computers and don't want to get stuck on a repetitive six monthly upgrade/reinstall cycle.

Three Years is great for the Life of a Desktop/Server.
The rolling release gives me cause for concern not in the general day to day updates but when you need to change something major like a jump to Wayland (if ever happens) for example could cause older family members lots of issues.

So second to Stability needs to be consistency. Evolution not Revolution.
Older people can't cope with major changes. Updating a package for bug fixes is not normally an issue as the core functionality/design does not change but the idea of an Upgrade which changes things can be a real learning curve.

I like the look and feel of Megeia and I am considering it as a replacement for my systems but I would like to be sure on the future plans before making the jump.

RTB

[jkerr82508]

Older people can't cope with major changes.

Please don't generalise. I have known many older people who have no problem adapting to change. I have also known more than a few younger people who don't like change of any kind.

Jim

[rtb]

>>Please don't generalise. I have known many older people who have no problem adapting to change. I have also known more than a few younger people who don't like change of any kind.

Fair comment. I suppose what I am saying is that I always like to find things where I left them.
Eg: Put the milk back in the fridge.

I have seen with Debian SID (I know it's different) that sometimes the updates break things.
Their is a reason why Red Hat have a strict distribution release cycle.
Existing RHEL releases only get security updates and new releases get new functionality (in the main).
The user chooses when to "break/update" the system.

Ubuntu has followed this module through it's LTS versions.
I've not really used a rolling distribution before to install for other people.

RTB

[PietroTux88]

yeah mageia begim now to be rolling release with emerald,emerald themes,compiz-fusion-icon,pidgin all plugins,vlc,xorg server,xorg,kernel ,wicd,7zip,kdenlive,openshot,cinelerra 4.2 and git version,gnomealsamixer,skype,amsn2,emesene2 this i believe how to amsn2.But i think mageia can have this packages on mirror cauldron soon.

[stormi]

Part of what you wrote I didn't understand, but if you are asking for newer versions of certains applications, you already can issue backport requests.

[PietroTux88]

Part of what you wrote I didn't understand, but if you are asking for newer versions of certains applications, you already can issue backport requests.

yes i say backport request staff mageia forum if possible have emerald,emerald themes and libs,pidgin all plugins,gnomealsamixer,cinelerra 4.2 and git version 2.1,compiz-fusion-icon (this is important).Mageia can be great dist with many packages request to users.Please don't ask me to send to bugzilla please i don't know use bugzilla if possible can admin user forum mageia request this please.

[stormi]

Part of what you wrote I didn't understand, but if you are asking for newer versions of certains applications, you already can issue backport requests.

yes i say backport request staff mageia forum if possible have emerald,emerald themes and libs,pidgin all plugins,gnomealsamixer,cinelerra 4.2 and git version 2.1,compiz-fusion-icon (this is important).Mageia can be great dist with many packages request to users.Please don't ask me to send to bugzilla please i don't know use bugzilla if possible can admin user forum mageia request this please.

When Mageia App Db will be ready, you will be able to ask easily for newer versions in a single click. However, until then, the only answer I can bring is exactly what you guessed : fill one package request per package on bugzilla. Saying "I don't know how to use bugzilla" is not a valid reason for not doing it, because there are people here who can explain you how to do it

Side note : as soon as the backports media will be open for change (soon), I will try to backport as much needed applications as possible, using the backports_testing media for testing. If you are ready to help testing those backports, it would be useful (this offer goes for anyone who wants to help, of course !)

[PietroTux88]

Part of what you wrote I didn't understand, but if you are asking for newer versions of certains applications, you already can issue backport requests.

yes i say backport request staff mageia forum if possible have emerald,emerald themes and libs,pidgin all plugins,gnomealsamixer,cinelerra 4.2 and git version 2.1,compiz-fusion-icon (this is important).Mageia can be great dist with many packages request to users.Please don't ask me to send to bugzilla please i don't know use bugzilla if possible can admin user forum mageia request this please.

When Mageia App Db will be ready, you will be able to ask easily for newer versions in a single click. However, until then, the only answer I can bring is exactly what you guessed : fill one package request per package on bugzilla. Saying "I don't know how to use bugzilla" is not a valid reason for not doing it, because there are people here who can explain you how to do it

Side note : as soon as the backports media will be open for change (soon), I will try to backport as much needed applications as possible, using the backports_testing media for testing. If you are ready to help testing those backports, it would be useful (this offer goes for anyone who wants to help, of course !)

im ready to testing backports repo i want flash player 64 bit ,ntfs-config, emerald,emerald.emerald-themes,compiz-fusion-icon,faac,faad,gnomealsamixer ecc.yes i want this and cinelerra 4.2 and cinelerra 2.1 git version if possible.If possible cauldron have also repo mirror testing and not normal mirrors.Cauldron must be rolling release on testing version repo thanks

[gotang]

I like the look and feel of Megeia and I am considering it as a replacement for my systems but I would like to be sure on the future plans before making the jump.

I share this sentiment entirely. I'd like a little more certainty before I cross over from Mandriva to Mageia. Is anyone in a position to shed some light on when a final decision on this matter might be made?

[maat]

I like the look and feel of Megeia and I am considering it as a replacement for my systems but I would like to be sure on the future plans before making the jump.

I share this sentiment entirely. I'd like a little more certainty before I cross over from Mandriva to Mageia. Is anyone in a position to shed some light on when a final decision on this matter might be made?

The discussion on these points is not finished... rolling versus not rolling (and if not rolling the cycle type and length) debate is still opened.

If you want to get in : this current topic is dedicated and you can also subscribe to mageia discuss mailing lists to give your point of view : https://mageia.org/mailman/

[zack]

No experience of rolling distro, so difficult to have qualified opinion.

What is clear, is that i need to CONTROL stability (and not be trapped, by a "global" dependencies update avalanche).

Then frozen is logical with "long" release cycle. The shorther you release, to remain "up to date", the more "rolling" becomes "natural evolution".

Another point is workload (to develop, to package, to test, to maintain all the variant of packages), and culture/habit (efficiency) of dev. The decision is driven by this of course.

My current thinking is more a simple balanced and conservative approach :
- longer release cycle (1 year)
- longer maintainance period (2-3 years)
- some "testing / stable" backports

Or a variant based on a 6 month releases, with shorter maintenance (1-2 year), but a LTS version every 18 month (3-4 years).

[stormi]

My current thinking is more a simple balanced and conservative approach :
- longer release cycle (1 year)
- longer maintainance period (2-3 years)
- some "testing / stable" backports

Or a variant based on a 6 month releases, with shorter maintenance (1-2 year), but a LTS version every 18 month (3-4 years).

Great, that's exactly my conclusion in the little study I gave the link of in the 6th comment of this thread (which raised no comment, probably too long to be read I guess ) : http://piratepad.net/CHSWq6ZRz2

[msdobrescu]

Hello,

I would definitely love a rolling release, but I think it leads to quality issues in the end.
Anyway, some important parts of a distro, like KDE/GNOME/etc. would be very nice to have when there are available new versions (not all minors if there are not major bugs) but still asap after.
It's so painful to wait for months for a version that never come (meanwhile, until one version adoption, some other 3 -minor- are released sometimes). In my case, Amarok had many bugs at 4.5.5 version of KDE, and I am not happy to wait for the next 6 months for some new distro release or at the mercy of somebody that would do a build for me (like MIB, which do a great job btw).

[PietroTux88]

mageia must be rolling release please with stability and fix bugs applications

[maat]

mageia must be rolling release please with stability and fix bugs applications

These two demands (in bold) contradict each other

Unless a miracle occurs we can not square the circle

[PietroTux88]

mageia must be rolling release please with stability and fix bugs applications

These two demands (in bold) contradict each other

Unless a miracle occurs we can not square the circle

i say mageia must be stable on rolling all

[mgsAbfnc]

I think that Mageia shouldn'be a rolling release, because it makes the distro less stable.

However, I think that the backports repositories should be "heavily" populated with new major versions of some software (Firefox, LibreOffice, Okular, etc.).

Since the Backports repositories are not enabled by default, those who want maximum stability, should keep it disabled.

Anyone who wants the latest and greatest software, could just enable the Backports repositories and use the newest software until the next release.

Then, whenever a new release comes out, Mageia users would get new versions of KDE, the Linux Kernel, x.org, etc., all the latest software, and the new improvements of the next release.

This would allow, without a rolling distro, to either have most of the latest software or have a very stable system, until the next version comes out.

For those who live on the bleeding edge, here is TeaAge's advice in this thread, to have a rolling release:

The system in Mandriva and Mageia is the same.
Cooker and Cauldron will always be rolling. Befor each release there will be a feature freeze (just a short time), where no new software versions will be implement (but updates), just to ensure the the stability. At the moment of the release Cauldron will be the same like Mageia 1 (for example). If you don't change your repositories after the release, the developer will bring all the new stuff to cauldron (and so to you).
But IF you change the repos to Mageia 1, you will stick with Mageia 1.

So, for now you have a Cauldron installation. Don't change anything and easly update your system with

Code: Select all
urpmi --auto-update


frequently and you will always have the latest available software for mageia (=> rolling release).

TeaAge

Best regards

[rtb]

No experience of rolling distro, so difficult to have qualified opinion.

What is clear, is that i need to CONTROL stability (and not be trapped, by a "global" dependencies update avalanche).

Then frozen is logical with "long" release cycle. The shorther you release, to remain "up to date", the more "rolling" becomes "natural evolution".

Another point is workload (to develop, to package, to test, to maintain all the variant of packages), and culture/habit (efficiency) of dev. The decision is driven by this of course.

My current thinking is more a simple balanced and conservative approach :
- longer release cycle (1 year)
- longer maintainance period (2-3 years)
- some "testing / stable" backports

Or a variant based on a 6 month releases, with shorter maintenance (1-2 year), but a LTS version every 18 month (3-4 years).

This is my thinking aswell, from the following posts it looks like caldron could behave like debian sid and give users rolling release.
I also like the longer release cycle and maintainence cycles but would too many versions over lap creating a support headache?
I would suggest an ubuntu like model.
Release yearly but only every two years release a LTS (Longer Term Support) version supported for three years.
IE: Last LTS is support for the first year on the New LTS version giving large scale installations a year to upgrade.

rtb

[corbintech]

I agree with a lot of what has been said. We really don't need yet another stack of CDs devoted to distro-X (OK this is in my case lol)

I think rolling is the way to go! The only problem is finding a way to satisfy those whom want pure stable.

Here is what I propose:

Unstable- This is the place where it all starts! Packages come from upstream end up here and move forward if no show stopper bugs are found
Rolling Unstable- Packages that leave Unstable come here to be tested for stability and made stable... Bleeding edge rolling (Debian Unstable)
Rolling Stable- Packages that are stable in Rolling Unstable for X amount of time come here.... Stable rolling (Arch)
Point releases- These releases are taken from the stable rolling release and supported for X amount of time... Security updates only
LTS release- These are rock solid stable (Debian stable) and snap shots from point release on whole number

So we would have unstable (easy to understand), unstable rolling for those who want cutting edge software, stable rolling for those who want to roll stable, point releases for those who like to install every now and then and LTS which after the way down the line should be VERY stable!

[rtb]

This looks like a good model.
The only key point would be how long the LTS versions are supported for?

RTB

[stormi]

I agree with a lot of what has been said. We really don't need yet another stack of CDs devoted to distro-X (OK this is in my case lol)

I think rolling is the way to go! The only problem is finding a way to satisfy those whom want pure stable.

Here is what I propose:

Unstable- This is the place where it all starts! Packages come from upstream end up here and move forward if no show stopper bugs are found
Rolling Unstable- Packages that leave Unstable come here to be tested for stability and made stable... Bleeding edge rolling (Debian Unstable)
Rolling Stable- Packages that are stable in Rolling Unstable for X amount of time come here.... Stable rolling (Arch)
Point releases- These releases are taken from the stable rolling release and supported for X amount of time... Security updates only
LTS release- These are rock solid stable (Debian stable) and snap shots from point release on whole number

So we would have unstable (easy to understand), unstable rolling for those who want cutting edge software, stable rolling for those who want to roll stable, point releases for those who like to install every now and then and LTS which after the way down the line should be VERY stable!

Point releases must be supported for bugfixes too, not only security. Otherwise, the only way to have bugfixes for a given package would be to switch your entire system to a rolling version.

However, your proposal looks like a maintainer's nightmare to me. With 10 times more packagers and testers, maybe we could achieve it, but it doesn't look realistic given our current ressources.

At the same time, a maintainer would have to support a given package in : Unstable, Rolling Unstable, Rolling Stable, Point release 1, Point release 2, Point release 3, LTS release 1, LTS release 2 (for the periods where to LTS releases overlap to ease transition). Which means you have to run up to 8 different systems to be able to reproduce reported bugs, test your updates, etc. I'm not sure it would scale. I don't think we can have realistically at the same time a stable rolling release and point releases that are supported.