[Mageia-dev] Proposal of a backporting process

Fri Jun 24 21:39:51 CEST 2011

On 24 June 2011 02:09, Michael Scherer <misc at zarb.org> 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
+