diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005451.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005451.html | 287 |
1 files changed, 287 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005451.html b/zarb-ml/mageia-dev/2011-June/005451.html new file mode 100644 index 000000000..b1bf37dd0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005451.html @@ -0,0 +1,287 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] about release cycle + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20about%20release%20cycle&In-Reply-To=%3C726644.65720.qm%40web161318.mail.bf1.yahoo.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="005951.html"> + <LINK REL="Next" HREF="005452.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] about release cycle</H1> + <B>Ron</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20about%20release%20cycle&In-Reply-To=%3C726644.65720.qm%40web161318.mail.bf1.yahoo.com%3E" + TITLE="[Mageia-dev] about release cycle">corbintechboy at yahoo.com + </A><BR> + <I>Mon Jun 13 00:25:43 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005951.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005452.html">[Mageia-dev] autologin + consolekit +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5451">[ date ]</a> + <a href="thread.html#5451">[ thread ]</a> + <a href="subject.html#5451">[ subject ]</a> + <a href="author.html#5451">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Hello, +I hope I am doing this right as I have never used this type of thing before, I will apologize before hand if not. +I wrote a proposal on the forums and I think it is very good and I would like it at the very least just heard and seen if it might work in the ideals of the project. I joined this list to get this out here. I am going to do copy/paste from my original post(s) to get this here.. Post 1: +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! +Further info: +1 developer releases 1 package. Package maintainer pulls package into unstable (developers don't make a habit of making crappy packages, stability is judged by the whole system running in harmony). Maintainers job is to make sure it works before it leaves unstable. When the package gains stability in unstable (basically you are able to install the package and have a usable system) the package moves to the next stage, rolling unstable. Rolling unstable is a test bed of bleeding edge software from the package maintainer for a X amount of time (we are still on this one package). Now, the next time this package moves it is from a scheduled pull, so this package after X amount of time now gets "pulled" into the next phase (rolling stable (as long as there are no show stopper bugs)). From here on out the "team" responsible pulls in packages from up stream (rolling unstable) and the package maintainer just repeats this process in working at the top of the + ladder. Security updates and bug fixes can be "pushed" down by the maintainer. + +Where is this hard? Sounds like any other distribution to me... Debian maybe? + +Anyway... + +2.0 will become an LTS. Not a packaging nightmare at all... A snapshot of rolling stable from a point in time that matures with bug fixes and security updates. Kernel only updates within kernel branch (2.6.30-XX). + +2.1 is a point release... Snapshot of rolling unstable (again easy on package maintainer). Supported for X amount of time. Becomes slightly mature as bug fixes and core updates make it so (from stuff already coming down from up stream). + +So we have 1 package maintainer working packages that are pushed into rolling unstable (think testing) and trickle on down the line with help from the community team of "distribution" maintainers. + +One rolling set of packages ever changing like a fine oiled machine. The logic just sounds right to me and very efficient I think... + +EDIT: If you wanted to "shorten" the amount of "projects (I guess)" you could omit anything below rolling unstable. + +Rolling unstable for instance could roll into a full fledged release (Not a good idea IMHO) +Rolling stable we could do without and we would be Debian all over (maybe more bleeding edge on the release) +LTS does not have to be... But LTS would be a very good way to get us used on servers... +Point releases are for those who don't like the rolling model... This is a "showcase" release to show everyone what we are without having to roll  + +Up to anyone really but this model is so versatile it really don't matter. You could omit about any point below the maintainer and have working mechanics.________________________________________________________________________Last post was in response to a disagreement with someone else. To help make my idea more fitting I was suggesting ways within my idea where things can change. Was under the impression the other part thought the idea would be hard on the package maintainer, I didn't and still don't see this problem. With everything being snapshots of the rolling model, maintaining should be very easy. +We could become fully rolling with this model, rolling and stable (debian but with newer packages), rolling unstable with LTS releases, rolling with general releases... Really there are a lot of possibilities based on this model.  +I like it... + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: </pipermail/mageia-dev/attachments/20110612/1fc5ea8a/attachment.html> +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005951.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005452.html">[Mageia-dev] autologin + consolekit +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5451">[ date ]</a> + <a href="thread.html#5451">[ thread ]</a> + <a href="subject.html#5451">[ subject ]</a> + <a href="author.html#5451">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |