[Mageia-dev] Proposal for backport process and policy

Samuel Verschelde stormi at laposte.net
Tue Jul 26 00:34:03 CEST 2011


I have finally taken the time to re-read all the backports discussion and tried 
to summarize it. However, as there were various positions expressed during the 
discussion and I didn't want to repeat them all (just read the discussion for 
that), I chose to build a coherent proposal out of this, taking the various 
difficulties at hand into account. I hope it is good, otherwise you'll probably 
tell me it isn't.

All in all, I hope we can come to an agreement as soon as possible, iron out 
the angles, and start providing backports (I'd like to play teeworlds 0.6 ;)).

*** What's backportable ***
- leaf packages
- leaf group of packages (a group of packages no external package depends on). 
It means that you must carefully check dependencies before backporting, and 
are allowed to backport a lot of packages provided you're ready to support 
them all and have them all properly tested. This way the policy is self-
adapting to the available ressources. Little ressources, no complicated 
backport. Lots of ressources, possibility to backport more complex stuff (such 
as KDE for example). For now, we are in the "little ressources" side of 
things, and will maybe remain there... Future will tell.
- packages not present in the distribution (provided it doesn't
obsolete or provide stuff that would impact the distribution, like
backporting a new jvm with a obsolete on the current one).
- a list of never backportable packages will be created to avoid big breakages 
(rpm, glibc, python, perl, xorg, ...)

*** Support ***
"better not backport than provide unsupported backports"
- bug fixes and security fixes for already backported packages, with the first 
way to fix being updating to a newer version, and close work with upstream in 
case the latest version doesn't solve the problems. If a fix is available in a 
development release but in no stable release, try to get the patch and apply 
it.
- security team helps finding out about security issues in current backported 
packages (an automated tool would help greatly for that, as proposed by misc)
- the packagers who backported the package are responsible for its support

*** Who backports ? ***
- no obligation to provide backports for the maintainer of a package (whereas 
a maintainer should provide updates to the stable releases for packages he/she 
maintains)
- another packager can step in and provide backports and then maintain them 
fully : provide newer versions, fix bugs and security issues... He must keep 
the maintainer informed.
- the maintainer can refuse that some packages are backported. If hard 
conflicts arise (eg. the maintainer vs all other packagers), we can refer to 
the council.

*** Backport cherry-picking ***
- backports can be cherry-picked ( ie, enable backports, install, disable
backports ). It means too that there must be strict requires between 
backported packages, in order to make sure they can be cherrypicked. 
- (for mageia 2) as this means that generally backports media will not be 
activated, improve the tools so that cherry-picked packages are updated when 
necessary :
  * Make mgaapplet or a similar applet propose newer backports for packages 
that were installed from backports media ( see item 41 in 
http://mageia.org/wiki/doku.php?id=iso2:technical_specification )
  * Give an easy way to update backports that need updating in CLI ( can be 
part of item 40 in 
http://mageia.org/wiki/doku.php?id=iso2:technical_specification )

*** Upgrade path ***
 - we need to ensure that upgrades never fail :
   * cauldron must always have a higher version/release than in stable 
releases
   * mageia n must always have a higher version than mageia n-1
 - there's a problem : if you backport from cauldron to mageia 1 and mageia 2, 
upgrade from mageia 1 to mageia 2 will fail because during upgrade backports 
are not available. Here is my proposal : until we work out a solution (and 
we'll try to bring one before mageia 2 if possible), or decide that we 
consider ability to backport more important than upgrade (not sure here though 
:)), backports are allowed only to the latest Mageia release.

*** SVN side of things ***
- use backports branches similar to the updates branches
- no direct submit from cauldron, must update in the backports branch first
- one of us will probably get tired from the extra work and write a mgarepo 
command to automate copy to the backport branch from cauldron, so in the end 
it will not be more difficult while giving us more control over the backports

*** Backport submit and testing ***
- to backports_testing first, no direct submit to backports from cauldron 
branch
- no delay from cauldron submit to backports_testing submit, backports_testing 
is here to allow testing
- (not sure about this part, we could also just trust packagers here) minimum 
one week before move from backports_testing to backports
- have them tested by the people who requested them
- (if QA team agrees) have them tested by QA team : create bug assigned to qa-
bugs at ml.mageia.org with an appropriate "backport" keyword in the report, or if 
QA Team doesn't want to mix updates with backports in the same mailing list, 
to a new qa-backports-bugs at ml.mageia.org list for QA Team members specifically 
willing to test backports). We'll make sure there are enough testers in QA by 
(using madb, communicating though forums...). It's easier to find new testers 
than new packagers, so I'm confident about it provided we put enough energy 
into this, which some members of QA team (including me) can work at. Important 
notice: QA team gives priority to updates, so if we don't find enough manpower, 
we'll skip the QA team backport testing. What I propose here is start with the 
QA Team, and see how well it goes. And if the part of the QA Team that tests 
backports must be just me, then let's start like this and I'll rapidly find the 
motivation to find volunteers :)

*** Move from backports_testing to backports ***
- once the backport has been validated, move it from backports_testing to 
backports
- who can move packages from backports_testing to backports ? Let's trust 
packagers : any packager with submit rights can do it. If too much problems 
arise, we will give those rights only to experienced members of the QA team 
(for example).

*** Old backports ***  
Remove old backports when newer ones are submitted
- otherwise we let people use old bugged or plagged with security issues 
packages, when they don't necessarily know that there are problems with them
- simpler choice : users have to choose between the version in updates and the 
one in backports, not more
- less space on mirrors (fear wesnoth and vegastrike multiple backports !)

Thank you for reading.

 Best regards,

Samuel Verschelde


More information about the Mageia-dev mailing list