diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101016/001231.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101016/001231.html | 135 |
1 files changed, 135 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101016/001231.html b/zarb-ml/mageia-dev/20101016/001231.html new file mode 100644 index 000000000..5b14829fb --- /dev/null +++ b/zarb-ml/mageia-dev/20101016/001231.html @@ -0,0 +1,135 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] How will be the realese cycle? + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20How%20will%20be%20the%20realese%20cycle%3F&In-Reply-To=%3C201010161152.27465.r.h.michel%2Bmageia%40gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001243.html"> + <LINK REL="Next" HREF="001235.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] How will be the realese cycle?</H1> + <B>Renaud MICHEL</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20How%20will%20be%20the%20realese%20cycle%3F&In-Reply-To=%3C201010161152.27465.r.h.michel%2Bmageia%40gmail.com%3E" + TITLE="[Mageia-dev] How will be the realese cycle?">r.h.michel+mageia at gmail.com + </A><BR> + <I>Sat Oct 16 11:52:27 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001243.html">[Mageia-dev] How will be the realese cycle? +</A></li> + <LI>Next message: <A HREF="001235.html">[Mageia-dev] How will be the realese cycle? +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1231">[ date ]</a> + <a href="thread.html#1231">[ thread ]</a> + <a href="subject.html#1231">[ subject ]</a> + <a href="author.html#1231">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Hello +On samedi 16 octobre 2010 at 05:00, Fernando Parra wrote : +><i> > On Friday, 15 October 2010 03:48:56 Fernando Parra wrote: +</I>><i> > So, we must "dumb down" everything, and not provide openldap backports +</I>><i> > for people running servers who want a convenient way to run the +</I>><i> > software version that will allow them to file bugs upstream (OpenLDAP +</I>><i> > team doesn't respond to bugs filed on non-current releases)? +</I>><i> +</I>><i> Specially here the answer is obvious: The novice doesn't now what is +</I>><i> OpenLDAP! and maybe he wont hear about it for the rest of his life. New +</I>><i> versions of OpenLDAP should be stay available in the backports +</I>><i> repository, not as an automatic available upgrade. +</I> +Well, for example like OpenLDAP it is not a problem, because only users that +need it will install it, and those that might need it are most likely aware +what it implies to upgrade it to a newer version. So it will not bother +other users if it is in backports or even updates, because as they won't +have it installed, they won't be proposed to update. + +It is more of a concern for things like cups or dbus, which most users will +use without knowing it, and won't know how to fix if it breaks (not even +knowing which package actually broke). + +><i> > What do we do in the case where a new version of some software is +</I>><i> > available, and has been sent to cooker? How do we decide whether it +</I>><i> > should go to backports or not? And for which releases? +</I>><i> > +</I>><i> > (FYI, for Mandriva users can typically request backports in bugzilla or +</I>><i> > on IRC, but we may need better means). +</I>><i> +</I>><i> Ok, first at all, we must deicide what packages (not all of them!) will +</I>><i> be at the Rolling Ligth model. After that, all this packages must have +</I>><i> an appropriate path. +</I> +I don't understand what you mean by "appropriate path". + +I think we should not decide before hand what packages will be backported, +we should maybe have a (short) list of packages that must not be backported +(like glibc) and then have backports either when contributors are willing to +make (and test) them, or on request. + +Maybe we could also have a (short also) list of packages that we should +really try (the packaging team could decide to dedicate some of his +resources to that) to backport to the latest stable release, and maybe the +previous latest. +Such packages would be for example firefox or OOo, packages that we know are +used by many (most) users, and many users are likely to want a newer +version. + +><i> Anyway, after decide what packages will be in the Rolling Light, The OS +</I>><i> must be gentle with the user and show a Window with a Message like that: +</I>><i> +</I>><i> There are available a new version of Firefox(as an example). Do you want +</I>><i> to install it? NO, Maybe Later, Show me more information, Yes +</I> +A little OT, but: + +Dialog windows should (almost) never have yes/no or ok/cancel choices, +because when an user see a yes/ok choice, he generally interpret it as "yes, +I want to keep on doing what I was doing". (and I know I have done it some +times myself) + +In your example, the No/yes should be labelled something like "keep current +version" and "install new version". + + +cheers +-- +Renaud Michel +</PRE> + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001243.html">[Mageia-dev] How will be the realese cycle? +</A></li> + <LI>Next message: <A HREF="001235.html">[Mageia-dev] How will be the realese cycle? +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1231">[ date ]</a> + <a href="thread.html#1231">[ thread ]</a> + <a href="subject.html#1231">[ subject ]</a> + <a href="author.html#1231">[ 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> |