[Mageia-dev] Proposal of a backporting process

[Ahmad Samir]

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