diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101015/001224.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101015/001224.html | 228 |
1 files changed, 228 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101015/001224.html b/zarb-ml/mageia-dev/20101015/001224.html new file mode 100644 index 000000000..80e33f86a --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001224.html @@ -0,0 +1,228 @@ +<!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=%3C201010151242.04108.bgmilne%40multilinks.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001213.html"> + + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] How will be the realese cycle?</H1> + <B>Buchan Milne</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=%3C201010151242.04108.bgmilne%40multilinks.com%3E" + TITLE="[Mageia-dev] How will be the realese cycle?">bgmilne at multilinks.com + </A><BR> + <I>Fri Oct 15 13:42:03 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001213.html">[Mageia-dev] How will be the realese cycle? +</A></li> + + <LI> <B>Messages sorted by:</B> + <a href="date.html#1224">[ date ]</a> + <a href="thread.html#1224">[ thread ]</a> + <a href="subject.html#1224">[ subject ]</a> + <a href="author.html#1224">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Friday, 15 October 2010 03:48:56 Fernando Parra wrote: +><i> Hi everybody. +</I>><i> +</I>><i> I feel that the concept of a new way, as it exist into my mind is not +</I>><i> completely understood. Let me try to re-explain again. Please be patient +</I>><i> and excuses any mistake with my English (I'm totally out of practice): +</I>><i> +</I>><i> I'm talking about to liberate to novice/novel/without experience user, +</I>><i> about concepts like backports, but I'm not talking about +</I>><i> close/disappear/eliminate/forgot backports. +</I>><i> +</I>><i> Why? because a big share of them will arrive from a very different +</I>><i> environment (especially windows), and as you now, in there those concepts +</I>><i> are not only estrange, they simply don't exists. When a Windows user +</I>><i> wants/needs to update a program, as much the only thing that he/she must +</I>><i> do is unninstall the old/previous version and then install the new one. +</I>><i> +</I>><i> What programs? Following the same idea, about these kind of users, we +</I>><i> should ask: what programs they usually upgrade? The answer could be found +</I>><i> asking to the user's themselves, but certainly could be another ways. +</I>><i> +</I>><i> Why not all backports? Reason 1: Because a lot of them don't care about the +</I>><i> new version of CUPS (in example) or the new version of Maxima (I'm sure +</I>><i> there are a lot clearly examples). Reason 2: Because there are packages +</I>><i> that may causes some incidents after upgrade them. +</I>><i> +</I>><i> How we can solve this situation? Offering a default automatic upgrade for a +</I>><i> small group of packages, especially when they change in an important way, +</I>><i> in example Firefox 3.6x 3.6x+ or to 4.x +</I>><i> +</I>><i> With this in mind: +</I>><i> > What aspects of the Mandriva backports solution are not satisfactory? +</I>><i> > +</I>><i> > -The fact that not everything is available as a backport? +</I>><i> +</I>><i> Not all are in backports, more these users don't want/understand a big +</I>><i> share of them +</I> +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)? + +><i> > -That users don't know how to request a backport? +</I>><i> +</I>><i> That is true, more, they don't want to learn about that, they only want a +</I>><i> new version of their favourite program. +</I> +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). + +><i> > -That too many backports are available? +</I>><i> +</I>><i> This is matter of who are revising backports, for novice? Yes there are to +</I>><i> many. For the geek or the expert? Maybe never there will enough of them. +</I>><i> +</I>><i> > -That all users don't get them by default? +</I>><i> > -That users doing network installs by default don't get the backport on +</I>><i> > initial installation? +</I>><i> +</I>><i> No, they are not get them if we will use a potentially problematic +</I>><i> repository. +</I>><i> +</I>><i> > -That users aren't aware of backports? +</I>><i> > -Something else? +</I>><i> +</I>><i> Panic? Fear? Baal, Luzbel and other demons in their minds? +</I>><i> +</I>><i> > Technically speaking? +</I>><i> > Less than 'urpmi --searchmedia Backports chromium' ? +</I>><i> +</I>><i> If I was a novice my answer will be: What hell is that? +</I> +This was a response to 'users must do less', not 'it must be very easy'. At +present, users need to do just one thing. We can fix the ease of doing that +one thing, if we understand the problem correctly. + +I note you chose to leave out: + +><i> > Or, should it be more obvious in rpmdrake or similar? How about +</I>><i> > commenting on my proposal for UI change in rpmdrake making backports +</I>><i> > more obvious? +</I> +The proposal I refer to is: +" +Now, maybe the user interface needs to be improved. For example, maybe there +should be no dropdown box, but instead when searching for a package by name, +it should show you all the versions: + +============================================================================ +Find: | digikam | In: ->Graphical applications |By: ->Package Name +---------------------------------------------------------------------------- +Package| |Status | Action ++digikam |Security update recommended |Update | +- 1.3.0-1mdv |Installed |Uninstall | +- 1.3.0-1.1mdv |Security Update |Update | +- 1.4.0-4mdv |Unsupported upgrade (backport) |Upgrade | + +----------------------------------------------------------------------------- +digikam - A KDE ........ + +============================================================================= +" + +Further, we could have some settings regarding what the user's preference is, +and possibly even per-package. For example, maybe the user would not like only +updates by default, except for chromium and pidgin where they want backports. +Or, maybe another user wants all backports, except OpenOffice.org, where they +just want updates. + +><i> > Again, before we can decide what *more* we should do (what significant +</I>><i> > resources we need to commit), maybe we should first understand why the +</I>><i> > existing features (which have significant effort behind them) are not +</I>><i> > resulting in user satisfaction. +</I>><i> +</I>><i> More and more reasons to prepare very carefully our offer. All we here +</I>><i> appreciate those efforts and there are no way to send them to trash +</I>><i> +</I>><i> > Personally I think a poll without educating everyone about what exactly +</I>><i> > each choice would mean is useless. We first need to elaborate detailed +</I>><i> > alternatives before anyone can make an informed choice. +</I>><i> +</I>><i> IMHO, a democracy without education is not democracy, is populism. I agree +</I>><i> at all, we need first elaborate a well structured alternatives and then, +</I>><i> explicitly after inform and educate our community we can run a poll, or +</I>><i> prepare a council, or any other appropriated way. +</I>><i> +</I>><i> > backports should be supported for security patches and bug fixes just +</I>><i> > like the main packages (if not instead of the main packages). +</I>><i> > Of course the security patch could be simply provided by backporting a +</I>><i> > newer version of the package, no need to make patches for each version. +</I>><i> +</I>><i> That is essential, any upgrade must be supported (other valid reason for an +</I>><i> small group of packages). +</I> +Note that this can be difficult. For example, if (say) 2010.1 has shipped with +samba 3.5.3, and let's say we shipped samba 3.5.5 in backports, now a security +update is required, updates provides 3.5.3-1.1mdv with a patch, but 3.5.6 +doesn't build without substantial work. + +Now, in order to provide a rapid update, the maintainer now needs to either: +-apply the patch to 3.5.5 and ship this to cooker and backports, and later +work on 3.5.6 for cooker, and then send it to backports again +-work on 3.5.6 until it works, and leave users without a security update for a +few days + +These decisions have quite an impact on the cost of supporting the distro ... + +><i> > What I mean is basically when new updates get presented (which would +</I>><i> > include new backports) the user could untick specific packages (as is +</I>><i> > possible now) but also have a second tick-box to store the choice +</I>><i> > permanently in the skip.list. +</I>><i> > This would give the user more choice of which packages he wants to always +</I>><i> > update to the newest version and wich ones he/she prefers to keep frozen +</I>><i> > at the same version. +</I>><i> +</I>><i> Please try to explain that to my grandma, or maybe you could be lucky with +</I>><i> some of my students. +</I> +How easy this is to use depends on the UI. For example, the updates window +could be reduced to be "Apply all recommended updates", "Apply only security +updates", and "Advanced", which would show the list of packages to update (and +provide options similar to the above, but slightly different). Your grandma +shouldn't click the "Advanced" button. + +Regards, +Buchan +</PRE> + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001213.html">[Mageia-dev] How will be the realese cycle? +</A></li> + + <LI> <B>Messages sorted by:</B> + <a href="date.html#1224">[ date ]</a> + <a href="thread.html#1224">[ thread ]</a> + <a href="subject.html#1224">[ subject ]</a> + <a href="author.html#1224">[ 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> |