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

Fri Oct 15 13:42:03 CEST 2010

On Friday, 15 October 2010 03:48:56 Fernando Parra wrote:
+> 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:
+> > What aspects of the Mandriva backports solution are not satisfactory?
+> > 
+> > -The fact that not everything is available as a backport?
+> 
+> Not all are in backports, more these users don't want/understand a big
+> share of them
+
+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)?
+
+> > -That users don't know how to request a backport?
+> 
+> That is true, more, they don't want to learn about that, they only want a
+> new version of their favourite program.
+
+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).
+
+> > -That too many backports are available?
+> 
+> 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.
+> 
+> > -That all users don't get them by default?
+> > -That users doing network installs by default don't get the backport on
+> > initial installation?
+> 
+> No, they are not get them if we will use a potentially problematic
+> repository.
+> 
+> > -That users aren't aware of backports?
+> > -Something else?
+> 
+> Panic? Fear? Baal, Luzbel and other demons in their minds?
+> 
+> > Technically speaking?
+> > Less than 'urpmi --searchmedia Backports chromium' ?
+> 
+> If I was a novice my answer will be: What hell is that?
+
+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:
+
+> > Or, should it be more obvious in rpmdrake or similar? How about
+> > commenting on my proposal for UI change in rpmdrake making backports
+> > more obvious?
+
+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.
+
+> > Again, before we can decide what *more* we should do (what significant
+> > resources we need to commit), maybe we should first understand why the
+> > existing features (which have significant effort behind them) are not
+> > resulting in user satisfaction.
+> 
+> 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
+> 
+> > Personally I think a poll without educating everyone about what exactly
+> > each choice would mean is useless. We first need to elaborate detailed
+> > alternatives before anyone can make an informed choice.
+> 
+> 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.
+> 
+> > backports should be supported for security patches and bug fixes just
+> > like the main packages (if not instead of the main packages).
+> > Of course the security patch could be simply provided by backporting a
+> > newer version of the package, no need to make patches for each version.
+> 
+> That is essential, any upgrade must be supported (other valid reason for an
+> small group of packages).
+
+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 ...
+
+> > What I mean is basically when new updates get presented (which would
+> > include new backports) the user could untick specific packages (as is
+> > possible now) but also have a second tick-box to store the choice
+> > permanently in the skip.list.
+> > This would give the user more choice of which packages he wants to always
+> > update to the newest version and wich ones he/she prefers to keep frozen
+> > at the same version.
+> 
+> Please try to explain that to my grandma, or maybe you could be lucky with
+> some of my students.
+
+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
+