[Mageia-dev] backports

Tue Jul 26 00:33:57 CEST 2011

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
+
+