On 24 June 2011 02:09, Michael Scherer <[email protected]> wrote: > 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. >
How would the packager get notified of backports requests via madb? Would you elaborate on how bugzilla is heavy for a backports request? > - 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. > Option 1 doesn't only mean not duplicating work, but also that the the spec in backports svn isn't ever out-dated; the only reason I see a package being in stable distro SVN is if it's in /release|updates, not backports... > 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. > Probably off-topic, but how will that work with madb? i.e. how will the maintainer get the feedback? > - 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. > The packager decides to move it and he has the necessary privileges to do so? or will he have to request someone from another team to move it? > - 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 ) > Agreed. > This way : > - packages are not sent untested, thus raising confidence in backports How many times did backports breaks a user's whole installation? we always say that backports should mainly be cherry picked, but not enabled all the time... so how does installing a new version of e.g. wine break the user's system when he can easily back out that rpm? > - 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 > > -- Ahmad Samir
