diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-July/006995.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-July/006995.html | 190 |
1 files changed, 190 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-July/006995.html b/zarb-ml/mageia-dev/2011-July/006995.html new file mode 100644 index 000000000..17c79f8a7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-July/006995.html @@ -0,0 +1,190 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Proposal for backport process and policy + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%20for%20backport%20process%20and%20policy&In-Reply-To=%3C201107260034.03358.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="006998.html"> + <LINK REL="Next" HREF="006999.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Proposal for backport process and policy</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%20for%20backport%20process%20and%20policy&In-Reply-To=%3C201107260034.03358.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Proposal for backport process and policy">stormi at laposte.net + </A><BR> + <I>Tue Jul 26 00:34:03 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="006998.html">[Mageia-dev] [RPM] cauldron core/release gnome-keyring-3.1.4-3.mga2 +</A></li> + <LI>Next message: <A HREF="006999.html">[Mageia-dev] Proposal for backport process and policy +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6995">[ date ]</a> + <a href="thread.html#6995">[ thread ]</a> + <a href="subject.html#6995">[ subject ]</a> + <a href="author.html#6995">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>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 +<A HREF="http://mageia.org/wiki/doku.php?id=iso2:technical_specification">http://mageia.org/wiki/doku.php?id=iso2:technical_specification</A> ) + * Give an easy way to update backports that need updating in CLI ( can be +part of item 40 in +<A HREF="http://mageia.org/wiki/doku.php?id=iso2:technical_specification">http://mageia.org/wiki/doku.php?id=iso2:technical_specification</A> ) + +*** 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 +:<i>)), backports are allowed only to the latest Mageia release. +</I> +*** 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- +<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">bugs at ml.mageia.org</A> 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 <A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">qa-backports-bugs at ml.mageia.org</A> 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 +</PRE> + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="006998.html">[Mageia-dev] [RPM] cauldron core/release gnome-keyring-3.1.4-3.mga2 +</A></li> + <LI>Next message: <A HREF="006999.html">[Mageia-dev] Proposal for backport process and policy +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6995">[ date ]</a> + <a href="thread.html#6995">[ thread ]</a> + <a href="subject.html#6995">[ subject ]</a> + <a href="author.html#6995">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |