[Mageia-dev] How will be the realese cycle?

Sat Oct 16 11:52:27 CEST 2010

Hello
+On samedi 16 octobre 2010 at 05:00, Fernando Parra wrote :
+> > On Friday, 15 October 2010 03:48:56 Fernando Parra wrote:
+> > So, we must "dumb down" everything, and not provide openldap backports
+> > for people running servers who want a convenient way to run the
+> > software version that will allow them to file bugs upstream (OpenLDAP
+> > team doesn't respond to bugs filed on non-current releases)?
+> 
+> Specially here the answer is obvious: The novice doesn't now what is
+> OpenLDAP! and maybe he wont hear about it for the rest of his life. New
+> versions of OpenLDAP should be stay available in the backports
+> repository, not as an automatic available upgrade.
+
+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).
+
+> > What do we do in the case where a new version of some software is
+> > available, and has been sent to cooker? How do we decide whether it
+> > should go to backports or not? And for which releases?
+> > 
+> > (FYI, for Mandriva users can typically request backports in bugzilla or
+> > on IRC, but we may need better means).
+> 
+> Ok, first at all, we must deicide what packages (not all of them!) will
+> be at the Rolling Ligth model. After that, all this packages must have
+> an appropriate path.
+
+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.
+
+> Anyway, after decide what packages will be in the Rolling Light, The OS
+> must be gentle with the user and show a Window with a Message like that:
+> 
+> There are available a new version of Firefox(as an example). Do you want
+> to install it? NO,   Maybe Later,   Show me more information,    Yes
+
+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
+