[Mageia-dev] Proposal of a backporting process

Sat Jun 25 22:53:03 CEST 2011

On 25 June 2011 22:15, Samuel Verschelde <stormi at laposte.net> wrote:
+> Le samedi 25 juin 2011 21:22:20, Ahmad Samir a écrit :
+>> 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:
+>> >> > - 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?
+>
+> Bugzilla is an issue tracker, and is centered on that concept. I think that a
+> simple "request backport" button in a package database browsing application
+> can be easier and more efficient, in that the "need" will be more easily
+> transmitted from the user to the packager. The backports requests we get today
+> (and got back in mandriva) don't represent the majority of needs. I'd like to
+> see what happens if users have a dead simple way to request them.
+>
+
+You want to interface for users, so that they don't have to deal with
+a 1minute-to-fill bug report to request a backport... that's your
+prerogative, I don' have a problem with that as long as it works.
+
+> Plus, as we want to transform "requester" into "tester", the more requests we
+> can get, the more users we have a chance to turn into testers... And maybe
+> more
+>
+
+"Tester" will have to use bugzilla, as that's the designated tool to
+contact devs/packagers... so maybe it's a good chance users become
+familiar with bugzilla?
+
+> I'm almost sure madb will have such a "request backport" button. It was
+> planned in the original specs. There's still to decide what this button does :
+> option 1 or option 2 above, or even (but not my choice) a redirect to a
+> prefilled form in bugzilla.
+>
+> There's one point that for me favors the use of a dedicated tool : the fact
+> that several users can request the same backport. Madb will be store existing
+> requests and associate new requesters to them if needed. This way :
+> - we will have means to see the most demanded backports
+> - there will be only one (if any) associated bugzilla request, and once madb
+> detects that the backport is available for testing, it will notify all
+> associated users, and once available for good too.
+> I think it's easier this way than asking to users to "check if there's already
+> a backport request for this program and add yourself in CC to the bug report
+> if there's one, otherwise create a new backport request".
+>
+
+FWIW, such kind of duplicate reports is easy to spot and marking one
+bug as a dupe of another adds the user to CC automatically.
+
+Again, I am not with or against using madb, simply because I've not
+seen in action and can't judge it.
+
+>>
+>> >> > - 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 see. You mean that once the backport has its own branch, updating it from
+> cauldron becomes difficult because each branch lives its own life.
+>
+> My proposal that the BS allows a direct jump from cauldron to backport, taking
+> care by itself of the SVN copying part can solve this problem I think.
+>
+>>
+>> > 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'm not sure. See misc's backport policy proposal : it's very close to
+> Mandriva's.
+>
+>> 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.
+>
+> I'd like us to try our best then, but remember that we're also trying to use
+> backport and software requests as a catalyst to get more testers and maybe
+> even more packagers.
+> Maybe even (let's dream :)) we will become known as a distribution where it's
+> easy to get newer versions of software and attract more users, which we will
+> try to turn into contributers in the end and then just rule the world :P
+>
+> Samuel
+>
+
+IIUC, the whole idea behind backports, is having an easy way for
+packagers to offer new versions of desktop application packages for
+users, emphasis on "easy"; based on the cauldron (cooker back in the
+day) SVN, the packager submits a new package to backports. That worked
+most of the times. I've seen anyone giving numbers/statistics on how
+many backports actually didn't work for the users.
+
+So, yes, I am all for improving the process, but without complicating
+it too much.
+
+-- 
+Ahmad Samir
+