[Mageia-dev] Proposal of a backporting process

[Samuel Verschelde]

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.

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 

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".

> 
> >> > - 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