Fernando Parra a écrit :
On Fri, 15 Oct 2010 12:42:03 +0100
Buchan Milne<[email protected]> wrote:
...
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.
With Mandriva and thus initially Mageia, often one only has to select
the new version, and the old version is automatically removed.
Otherwise the old version can be removed later. So we already have it
easier :)
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
This is simply not advisable. In the event of a problem resulting from
an automatic update, the user will have no idea what was done. So how
easy will it be to support the user in such a case ? All changes should
be expressly confirmed (or specifically requested) by the user.
With this in mind:
What aspects of the Mandriva backports solution are not satisfactory?
-The fact that not everything is available as a backport?
True in the Microsoft windows environnement, as everywhere else.
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)?
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.
The user selects which backports they want. If they don't understand
OpenLDAP, they wouldn't have a reason to select it.
-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.
They will only likely want a new version of their favorite program if
they know it is available. Which they will probably discover via backports.
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).
Agree 100%. The presentation definitely needs improvement.
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.
-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?
Obviously the novice user would use Rpmdrake via the MCC.
And Rpmdrake definitely needs improvement.
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.
Some times easy doesn't means "do less", I think in this particular case must
means Understandable.
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.
These are excellent ideas.
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.
I think that polls generally totally miss the mark, especially on
questions essentially technically based. What we are discussing at this
point is how to better present upgrade options to the end-user, be it
novice or experienced. Any polls should focus on what the user wants to
experience, and contributors to Mageia decide, based on their
competence, how to deliver it.
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 ...
It's not just creating the update that costs, also due to these changing
dependancies, dealing with bugs on various installations of the release
in question becomes much more problematic. Installing a backport is
generally more stable than installing a new version.
Again, IHMO, these kind of packages (samba, nfs, cups, etc.) now are in the
main repository, and of course they must be frozen, except for security
updates, and if a new version occurs, it should be in backports repository or
in Cauldron or at any place that will be appropriated.
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.
Good idea. The white-list (preferred newer versions) would probably be
more useful, but the black-list would be very useful to avoid installing
packages known to be problematic on the user's system.
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.
I think that all updates should be specifically confirmed. Otherwise,
it's a bit like driving a car blind-folded, and later wondering why one
had an accident.
It is a good idea to tag updates as "security", "recommended", etc.
Implicitly, an advanced user is more likely to decide otherwise.
But anyone who is intelligent enough to use a computer should be
respected enough to at least confirm updates.
If my grandma watch the word "Advanced", she simply call me by phone and order
me: Come here right now!.
Regards,
Buchan
Let me relate a true history (and it isn't a joke): few years ago, I was a
technical support manager in an international bank, my main task was to have
running all time, all computers in the bank (2000). When my guys were
responding to a request for support, and when asked:
What happened? the first response was:
I did nothing!
Okay, a message appeared on the screen?
Oh yes, but did not understand, then I hit the OK button.
What was wrote in the Message?
I'm not a technician, I didn't read it.
Mmmm, and now what is the problem?
Are you blind?, I can not start Word! (Or print or whatever)
And you didn't train your users ? From personal experience, most users
learn quickly to copy error messages that appear on the screen - even
those who initially seem totally inept. I regularly trained users who
initially required a lot of hand-holding to let me reliably troubleshoot
by telephone. But it does take a little patience.
Of course, novice home users will be more problematic, since they will
often use the computer much less.
I heard hundreds of times these kind of absurd conversations.
The basic/novice user doesn't read anything, doesn't request anything to some like a
bugzilla, If you show on his screen some like your proposal, he usually take one of two
different ways: 1) Check all the options or maybe worst 2) Close the window and he will
think: "Oh hell, Why Linux is so hard?"
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
That is entirely possible with a Mandriva-like system. Stable 6-month
releases, with security updates and backports available. How would a
so-called rolling update system do it better ?
Note that the 6-month releases don't have to be installed every time.
Also, even if done, this installation process is simple - and much
faster than installing Microsoft's excuse of an operating system.
Please take in mind that we are trying to get a considerable number of new
users. If we just keep doing things like today, we will certainly have new
users, but they probably come from other distributions.
Note that Mandriva has the reputation of being one of the most friendly
Linux systems available. But powerful enough for serious users and
servers. So Mageia, with its stronger community focus, will probably be
one of the distros most capable of attracting non-Linux users.
Not counting the advertising budget of Ubuntu, of course.
...
IHMO before to discuss what are the technical conflicts, we need to evaluate
the benefits of any proposal focusing the point of view on what the users
needs/wants.
Evaluate the benefits in terms of what the user wants to experience --
those with the technical competence must decide how to deliver.
As we said in Mexico: My home is your home.
Regards from México.
my 2 cents :)
- André (andre999)
