[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