[Mageia-dev] backports

Tue Jul 26 04:13:05 CEST 2011

2011/7/26 Michael Scherer <misc at zarb.org>:
+> 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.
+
+A very strong +1 for these 2 last paragraphs.
+
+-- 
+wobo
+