Hi, as said in the thread of firefox 5, and in the meeting of packager sooner this week, this is the first mail about backports ( on 3 ).
So here is the proposal of a process, based on the feedback of people, and the idea of some packagers ( mainly stormi ). - Someone request a backport ( by bugzilla, by madb, by a email, by taking a packager family in hostage, whatever ). I would prefer use bugzilla but this may not be very user friendly, or too heavy. - a packager decide to do it. Based on the policy ( outlined in another mail ), and maybe seeing with the maintainer first about that for non trivial applications, the backport can be done, or not. The criterias for being backported or not are not important to the process, just assume that they exist for now ( and look at next mail ). So based on criteria, someone say "it can be backported, so I do it". - I am not sure on this part, but basically, we have 2 choices : - the packager take the cauldron package and push to backport testing - the packager move the cauldron package in svn to backport, and there send it to backport testing. Proposal 1 mean less work duplication, but proposal 2 let us do more customization. if the package doesn't build, the packager fix ( or drop the idea if this requires too much work ) - the packager send requesting feedback about the backport from the people who requested it, and test it as well. - based on feedback ( ie if the package work or if the packager is confident ), the packager decide to move it to backport for everybody, using some stuff similar to rpmctl ( the tool we used to move package at Mandriva ). The tool would also send notifications. - if the package doesn't work, he either fix, or drop the backport idea. If he fix, we go back on testing, if he drop, we remove the rpm ( with a automated cleaning of rpm after 1 or 2 months ). If the packager drop the backport, it should be notified to the requester ( hence the use of bugzilla, or a more suitable tool ) This way : - packages are not sent untested, thus raising confidence in backports - the QA should not be overloaded, and can focus on updates - sysadmins are not overloaded - people requesting backport see how QA work, and are involved into the distribution as testers, thus creating a much healthier discussion with packagers, and creating more incentive to help. And since they request the package, they will be motivated to test more than stuff they do not use. WDYT ? -- Michael Scherer
