diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101015/001212.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101015/001212.html | 165 |
1 files changed, 165 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101015/001212.html b/zarb-ml/mageia-dev/20101015/001212.html new file mode 100644 index 000000000..884b35a67 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001212.html @@ -0,0 +1,165 @@ +<!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=%3C20101014214856.ed444fed.gato2707%40yahoo.com.mx%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001211.html"> + <LINK REL="Next" HREF="001213.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] How will be the realese cycle?</H1> + <B>Fernando Parra</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=%3C20101014214856.ed444fed.gato2707%40yahoo.com.mx%3E" + TITLE="[Mageia-dev] How will be the realese cycle?">gato2707 at yahoo.com.mx + </A><BR> + <I>Fri Oct 15 04:48:56 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001211.html">[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc +</A></li> + <LI>Next 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#1212">[ date ]</a> + <a href="thread.html#1212">[ thread ]</a> + <a href="subject.html#1212">[ subject ]</a> + <a href="author.html#1212">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Hi everybody. + +I feel that the concept of a new way, as it exist into my mind is not completely understood. Let me try to re-explain again. Please be patient and excuses any mistake with my English (I'm totally out of practice): + +I'm talking about to liberate to novice/novel/without experience user, about concepts like backports, but I'm not talking about close/disappear/eliminate/forgot backports. + +Why? because a big share of them will arrive from a very different environment (especially windows), and as you now, in there those concepts are not only estrange, they simply don't exists. +When a Windows user wants/needs to update a program, as much the only thing that he/she must do is unninstall the old/previous version and then install the new one. + +What programs? Following the same idea, about these kind of users, we should ask: what programs they usually upgrade? The answer could be found asking to the user's themselves, but certainly could be another ways. + +Why not all backports? Reason 1: Because a lot of them don't care about the new version of CUPS (in example) or the new version of Maxima (I'm sure there are a lot clearly examples). +Reason 2: Because there are packages that may causes some incidents after upgrade them. + +How we can solve this situation? Offering a default automatic upgrade for a small group of packages, especially when they change in an important way, in example Firefox 3.6x 3.6x+ or to 4.x + +With this in mind: + +><i> What aspects of the Mandriva backports solution are not satisfactory? +</I> +><i> -The fact that not everything is available as a backport? +</I> +Not all are in backports, more these users don't want/understand a big share of them + +><i> -That users don't know how to request a backport? +</I> +That is true, more, they don't want to learn about that, they only want a new version of their favourite program. + +><i> -That too many backports are available? +</I> +This is matter of who are revising backports, for novice? Yes there are to many. For the geek or the expert? Maybe never there will enough of them. + +><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> +No, they are not get them if we will use a potentially problematic repository. + +><i> -That users aren't aware of backports? +</I>><i> -Something else? +</I> +Panic? Fear? Baal, Luzbel and other demons in their minds? + +><i> Technically speaking? +</I>><i> Less than 'urpmi --searchmedia Backports chromium' ? +</I> +If I was a novice my answer will be: What hell is that? + +><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> +More and more reasons to prepare very carefully our offer. All we here appreciate those efforts and there are no way to send them to trash + +><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> +IMHO, a democracy without education is not democracy, is populism. I agree at all, we need first elaborate a well structured alternatives and then, explicitly after inform and educate our community we can run a poll, or prepare a council, or any other appropriated way. + +><i> backports should be supported for security patches and bug fixes just like +</I>><i> 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> +That is essential, any upgrade must be supported (other valid reason for an small group of packages). + +><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> +Please try to explain that to my grandma, or maybe you could be lucky with some of my students. + +><i> New users who frequented the forums always got to know what backports +</I>><i> are pretty fast. And bugzilla is the perfect system for asking for a +</I>><i> backport, that worked pretty good. +</I> +These users are walking to change into intermediate users, they are no longer basic users. This only for the simple fact that they are posting in a technical forum. Let me remind you: 1,300 millions of Hispanics and only 130 votes at the BlogDrake poll. + +><i> I was thinking about writing a proposal as you suggested, but so far I +</I>><i> haven't found the time. +</I>><i> I don't think this is that urgent, since backports only become an issue +</I>><i> once we have the first release out, but I will try to write up a +</I>><i> proposal well before that. +</I> +I'm writing a proposal as Tux99 does, I need find time for finish it and then translate it. + +Regards from México +-- +Fernando Parra <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">gato2707 at yahoo.com.mx</A>> +</PRE> + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001211.html">[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc +</A></li> + <LI>Next 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#1212">[ date ]</a> + <a href="thread.html#1212">[ thread ]</a> + <a href="subject.html#1212">[ subject ]</a> + <a href="author.html#1212">[ 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> |