[Mageia-dev] Proposal for backport process and policy

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
+