On Sat, 16 Oct 2010 11:52:27 +0200 Renaud MICHEL <[email protected]> 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 <[email protected]>
