2011/7/26 Michael Scherer <[email protected]>: > 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/[email protected]/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
