[Mageia-dev] Proposal of a backporting process

Sat Jun 25 19:33:15 CEST 2011

Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit :
+> 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?
+
+There are several options :
+- option 1 : maintainers prefer to have all backports requests in bugzilla. 
+Madb will then create backports requests via XML-RPC, with the original 
+reporter in CC maybe, and regularly watch bug report status. This will be 
+extra work on madb's side and force those users (who maybe don't know how to 
+use bugzilla) to use 1 tool for the request and a different tool for testing 
+reports, but why not.
+- option 2 : maintainers are OK to use bugzilla for bugs and madb for package 
+requests => madb will query the maintainers database and notify the 
+maintainer(s) by mail. It could, like bugzilla, send notifications to a ML too, 
+and provide a simple yet sufficient tracking system (status, comments).
+
+> 
+> Would you elaborate on how bugzilla is heavy for a backports request?
+
+Heavy I don't know, but I think that we can give users a better tool to 
+request backports, see what backports already have been requested, etc.
+
+> 
+> > - 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...
+
+I'm not sure I understand your point. What do you mean with out-dated specs in 
+backports ? 
+I favor option 2 (with all needed useful shortcuts in mgarepo and BS to make 
+it simple for packagers) because it allows to cope with the following 
+situation :
+- foo is in version 1.2.2 in release|updates
+- foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for 
+the next stable release
+- the latest release in the 1.x branch, 1.3.0, brings many features requested 
+by some users, we want to provide it as a backport : with option 1 we can't, 
+with option 2 we can. 
+
+or : 
+- foo is in version 1.2.2 in release|updates
+- foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for 
+the next stable release
+- we had backported version 1.2.6 before switching to 2.0alpha in cauldron
+- the backported version 1.2.6 has a big bug we hadn't spotted during tests 
+and we want to fix in the backport : with option 1 we can't, with option 2 we 
+can.
+
+So, for me, this is definitely option 2.
+
+However, I think it must be made a painless as possible to packagers :
+- in the common case, allow to submit directly from cauldron to the backports 
+media, but let the BS detect that and automatically do the SVN copy part.
+- for the situations I described above, work with the backport branch 
+similarly as we work on updates (technically speaking : SVN, BS...). 
+
+
+> 
+> > 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?
+
+I partially answered above : either via bugzilla, or via a simple tracking 
+system included in madb for that need. It will depend on the chosen process, 
+we'll try to adapt the tool to the situation.
+
+
+Best regards
+
+Samuel Verschelde
+