[Mageia-dev] Proposal of a backporting process

Sat Jun 25 21:22:20 CEST 2011

On 25 June 2011 19:33, Samuel Verschelde <stormi at laposte.net> wrote:
+> 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.
+>
+
+Yes, but what's wrong with bugzilla and better in the other tool?
+
+>>
+>> > - 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 ?
+
+The cauldron one got some changes/patches, the one in backports didn't
+get them => outdated.
+
+> 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.
+>
+
+Good point, but now we're not really talking about backports any more,
+I think; we're talking about having a second "updates" repo but with
+version bumps allowed, which sort of negates the backports repos
+criteria that was used in mdv all those years.... I can't help but
+think that in some cases that will be promising support that we can't
+afford to give to begin with.
+
+The whole "backports isn't officially supported" was/is a sort of CYA*
+motto, like the "the beverage you're about to drink is hot" on
+Starbucks coffee cups (if the customer doesn't already know coffee is
+served hot, then there's something fundamentally wrong somewhere in
+his head), it's just there so that when someone sues, they have a way
+out, that's all it is.
+
+I've seen backported packages get repushed with fixes when needed,
+that's support AFAICT.
+
+* CYA == cover your ass.
+
+> 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
+>
+
+
+
+-- 
+Ahmad Samir
+