diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005977.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005977.html | 190 |
1 files changed, 190 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005977.html b/zarb-ml/mageia-dev/2011-June/005977.html new file mode 100644 index 000000000..9b10f96ef --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005977.html @@ -0,0 +1,190 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Backports policy proposal + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20policy%20proposal&In-Reply-To=%3C1308874214.22020.164.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="006091.html"> + <LINK REL="Next" HREF="005981.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Backports policy proposal</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20policy%20proposal&In-Reply-To=%3C1308874214.22020.164.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Backports policy proposal">misc at zarb.org + </A><BR> + <I>Fri Jun 24 02:10:14 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="006091.html">[Mageia-dev] Proposal of a backporting process +</A></li> + <LI>Next message: <A HREF="005981.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5977">[ date ]</a> + <a href="thread.html#5977">[ thread ]</a> + <a href="subject.html#5977">[ subject ]</a> + <a href="author.html#5977">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Hi, + +as said, this is the 2nd mail of the 3 mails about handling backports. +It is about backport policy, ie what we update, and what we don't, with +a set of criteria, to make sure we fullfill our goals. + +I will start by the fact we can all agree that we want to have a +breakage-free experience. One of the value of the project is the +quality, and traditionally, the best way to not break something is to +have minimal changes. +Yet, people have asked for newer version of packages, and people are ok +to trade a little bit of change and little bit of risk for new software, +and we have offered that in the past at Mandriva with some success. + +Experience have showed that people care mostly about applications rather +than low level library and modules. Experience have also show that +people are not sure about backport, and that we should make sure +everything work fine so we can have more people that use them. + +The Mandriva policy was rather good, and I think we can also all agree +there is packages that can clearly not be backportable without either +lots of QA, or without rebuilding lots of stuff : +- glibc, python, perl, xorg, etc + +I would also say that the maintainer can also say that he doesn't want +the rpm be backported, either because he think that's not ready, or +because he think it should not be done. I think this will not happen +often, but for the rare case a problem would arise, the maintainer +should have the last word. + +On the other hand, there is packages that can be backported without +impacting much : +- leaf packages ( those that nothing requires ), +- packages not present in the distribution ( provided it doesn't +obsolete or provides stuff that would impact the distribution, like +backporting a new jvm with a obsolete on the current one ). + +So for a start, I would suggest to use the same policy as Mandriva +( <A HREF="http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy">http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy</A> ). + +Ie, only create a backport for rpm that cannot have a negative impact +( leaf packages, newer one ), and then revise the policy in one year +based on request that were refused, to see if we can find something to +change. + + +I would also propose a few rules : + +"a package should have been in cauldron since 1 week before being +backported", so we can at least ensure there was a minimal test on it, +Ie, if I package stuff-virtual-manager, I cannot backport it before 1 +week. If we have a package of stuff-virtual-manager since 1 month, and +that I update a new version, then I can backport. The idea is that a +newer packages may suffer from more bug than older one. + + +Another rule that we could add is that cauldron should always be newer +than backports, in order to ensure upgradability. The same goes for n-2 +and n-1 release. +While this seems innocent, do not forget this will have a impact when we +do the version freeze. + + +Something that was discussed previously, we should make sure that +backport can be cherrypicked. If I backport trac, I will need to place +stricted Requires from subpackages on the main package and so on, in +order to ensure no mix of rpm. And since we plan to backport only leaf +packages, this would not affect others packages. However, this will have +a impact on the next issue, updates. + +so : +- cannot be backported if this is not a leaf package, will be revised +later +- cannot be backported if the maintainer say "no", but we assume he say +"yes" by default +- cannot be backported if it impact the dependency tree too much +( Obsoletes, Provides, etc ) +- cannot be backported if the package was just created and is thus +basically untested in cauldron + +- must not prevent upgrade to next release + +- strict requires between backported packages, in order to make sure +they can be cherrypicked ( ie, someone enable backports, install, remove +backports ) + +You can comment ( do not forget to trim the answer , and please keep +this on topic, that's why I did 3 mails ). + +-- +Michael Scherer + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="006091.html">[Mageia-dev] Proposal of a backporting process +</A></li> + <LI>Next message: <A HREF="005981.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5977">[ date ]</a> + <a href="thread.html#5977">[ thread ]</a> + <a href="subject.html#5977">[ subject ]</a> + <a href="author.html#5977">[ 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> |