[Mageia-dev] backports

[Michael Scherer]

Le lundi 25 juillet 2011 à 21:47 +0200, Maarten Vanraes a écrit :
> Hi,
> 
> with regards to backports, users are complaining (they always do) that 
> backports are taking too long.
> 
> on the one hand almost everyone seems to agree that backports should be 
> "supported" in some way or another... however, noone seems to want to 
> actuallty put in the time to finalize that. (or at least that's how I see it)
> 
> Since afair there is no real consensus, i suggest one of the following 
> options, or possibly make this a vote, or have packaging team leaders (or 
> board) decide this:
> 
> A. backports are maintainers responsibility
> 
> Every backport is tested or untested by maintainers discretion, (s)he decides 
> how much testing it needs. We could still make a policy that there should be 
> some tests.
> 
> B. well established support like updates
> 
> Similar QA like updates.
> 
> 
> then there is the matter of submission:
> 
> A. We submit all backports from cauldron
> 
> B. like updates, there's a separate section for backports
> 
> C. backport submission is only allowed from the separate section, not from 
> cauldron, if you want to backports from cauldron, you need to make the 
> necessary steps yourself.
> 
> 
> personally, i favor B & C; such as i think most of the people wanted; but if 
> wanted, i can settle for A & B.

If people did read what others said, they would have seen the obvious
problem : 
Most people using backports, if not all, want to update just partially
their system ( ie, cherry picking ). See for example the mail of wobo 
http://www.mail-archive.com/mageia-dev@mageia.org/msg05794.html

We also do it on our infrastructure, and I know others admins that do it
too. See also others mails about the topic.

So you are completely missing the real problems.

Yet, the solution is simple :
just say that backports are unsupported beyond "we offer them on the
mirrors", since nobody is willing to :

1) properly define supported ( yet everybody agree that it should be ).
To me supported mean :
- do not break important stuff of the distribution
- is supported in term of bugfixes by the distribution, in a timely
fashion 
- supported by packagers

2) take the required measure to make that happen
and by "taking the measure", I mean "follow the limitations that would
enable proper support by my definition", which include among others : 
- not break upgrade from the distro to a new version ( I already
explained that in the previous thread )
- not let users with outdated and vulnerable softwares without expecting
them to spend time finely tuning their system, and without putting
restriction on what they run ( such as forcing to run a specific applet
instead of having a smooth and integrated system like update )

Current system of Mandriva, that is currently used, is geared toward
technical users only, and even them are left with a system in a
unsupported state ( ie, no update, no upgrade, and no assurance of
backport being properly tested ). 

We only solved the 3rd part for now, and I did proposal for the 2nd one
( that were refused ).

> If someone from -sysadmin can find the time to make the SVN repos for backports 
> (and testing), that would be awesome, so we can actually do some testing for 
> it and get this show on the road.

I do not think we should deploy first and then think. 

Either we declare backport unsupported, as in the current form, saying
otherwise would be lying, or we need clearly define what to expect ( and
that would be mostly "no support if you do this, and less support if you
do that" ) if people think unsupported is too strong. If we take this
way, we should make it clear to people using it.

Or we find a solution for the problems, without adding new ones.

We worked too hard to have a good reputation of being a solid
distribution to ruin it. People can better cope with running old working
softwares ( with old being 3 or 4 months old ) than having crashes or
breakage later.

Especially since people have said "we do not want to reinstall on every
version", to me, that's clearly a demand from users to have a working
and smooth distribution upgrade process. 
-- 
Michael Scherer