From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20101016/001235.html | 145 ++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 zarb-ml/mageia-dev/20101016/001235.html (limited to 'zarb-ml/mageia-dev/20101016/001235.html') diff --git a/zarb-ml/mageia-dev/20101016/001235.html b/zarb-ml/mageia-dev/20101016/001235.html new file mode 100644 index 000000000..2926ddd99 --- /dev/null +++ b/zarb-ml/mageia-dev/20101016/001235.html @@ -0,0 +1,145 @@ + + + + [Mageia-dev] How will be the realese cycle? + + + + + + + + + +

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

+ Fernando Parra + gato2707 at yahoo.com.mx +
+ Sat Oct 16 18:00:22 CEST 2010 +

+
+ +
On Sat, 16 Oct 2010 11:52:27 +0200
+Renaud MICHEL <r.h.michel+mageia-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
+
+> 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".
+> 
+
+Well, if we are talking about a new model, I think we need to redefine what will be the way that's Mageia offer these particular (Rolling Light) packages. I'm not closed to any method in particular.
+
+> 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".
+> 
+
+Ok, as more clear options, as it will be better.
+
+> 
+> cheers
+> -- 
+> Renaud Michel
+> 
+
+Regards from Mexico
+-- 
+Fernando Parra <gato2707 at yahoo.com.mx>
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1