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. -- Michael Scherer
