[Mageia-dev] Proposal of a backporting process

[Ahmad Samir]

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?

Would you elaborate on how bugzilla is heavy for a backports 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...

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

> - based on feedback ( ie if the package work or if the packager is
> confident ), the packager decide to move it to backport for everybody,
> using some stuff similar to rpmctl ( the tool we used to move package at
> Mandriva ). The tool would also send notifications.
>

The packager decides to move it and he has the necessary privileges to
do so? or will he have to request someone from another team to move
it?

> - if the package doesn't work, he either fix, or drop the backport idea.
> If he fix, we go back on testing, if he drop, we remove the rpm ( with a
> automated cleaning of rpm after 1 or 2 months ).
>

[..]

> If the packager drop the backport, it should be notified to the
> requester ( hence the use of bugzilla, or a more suitable tool )
>

Agreed.

> This way :
> - packages are not sent untested, thus raising confidence in backports

How many times did backports breaks a user's whole installation? we
always say that backports should mainly be cherry picked, but not
enabled all the time... so how does installing a new version of e.g.
wine break the user's system when he can easily back out that rpm?

> - the QA should not be overloaded, and can focus on updates
> - sysadmins are not overloaded
> - people requesting backport see how QA work, and are involved into the
> distribution as testers, thus creating a much healthier discussion with
> packagers, and creating more incentive to help. And since they request
> the package, they will be motivated to test more than stuff they do not
> use.
>
> WDYT ?
>
> --
> Michael Scherer
>
>



-- 
Ahmad Samir