[Mageia-dev] Proposal of a backporting process

[andre999]

Samuel Verschelde a écrit :
>
> 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:

...

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

Given this explanation, I would definitely go for option 2 as well.

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

Sound good to me.

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

I tend to like the idea of using bugzilla with a streamlined template, to avoid 
unnecessary duplication of code to be maintained.
But if madb can track things better, and it can be readily developed, that sounds good.
As for packagers, it shouldn't make much difference if the tools are done right.

> Best regards
>
> Samuel Verschelde

Regards

-- 
André