diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-June/016906.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-June/016906.html | 218 |
1 files changed, 218 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-June/016906.html b/zarb-ml/mageia-dev/2012-June/016906.html new file mode 100644 index 000000000..ac3573e95 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016906.html @@ -0,0 +1,218 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Backports Summary + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20Summary&In-Reply-To=%3C4FEAF142.1030905%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="016899.html"> + <LINK REL="Next" HREF="016909.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Backports Summary</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20Summary&In-Reply-To=%3C4FEAF142.1030905%40laposte.net%3E" + TITLE="[Mageia-dev] Backports Summary">andre999mga at laposte.net + </A><BR> + <I>Wed Jun 27 13:40:50 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="016899.html">[Mageia-dev] Backports Summary +</A></li> + <LI>Next message: <A HREF="016909.html">[Mageia-dev] Backports Summary +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16906">[ date ]</a> + <a href="thread.html#16906">[ thread ]</a> + <a href="subject.html#16906">[ subject ]</a> + <a href="author.html#16906">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Thomas Backlund a écrit : +><i> andre999 skrev 27.6.2012 10:47: +</I>>><i> Thomas Backlund a écrit : +</I>>>><i> Thomas Backlund skrev 26.6.2012 22:25: +</I>><i> +</I>>>>><i> +</I>>>>><i> And then the questions we need to decide on: +</I>>>>><i> (substitute mga1/mga2 for any future release...) +</I>>>>><i> 1. Do we support backporting package with higher version +</I>>>>><i> than package in the following next mageia release has ? +</I>>>>><i> (meaning if mga1 has v12, and mga2 has v14, is it ok +</I>>>>><i> to backport v16 to mga1?) +</I>>>>><i> * PRO: more uptodate package in backports +</I>>>>><i> * CON: can cause trouble during distro upgrade +</I>>>>><i> * imho both technically ok as long as we make sure +</I>>>>><i> its documented so people know what to expect. +</I>>>>><i> +</I>>>>><i> 2. If one want to backport a package to mga1, does it mean +</I>>>>><i> it must be backported to mga2 in order to preserve +</I>>>>><i> upgrade path (unless already in mga2, depending on +</I>>>>><i> question 1)? +</I>>>>><i> +</I>>>>><i> +</I>>>>><i> +</I>>>>><i> And since we can continue this what/if discussion forever, +</I>>>>><i> and thereby delay backports even more here is my take on it: +</I>>>>><i> +</I>>>>><i> my suggestions to decide on question 1 and 2: +</I>>>>><i> 1. backporting bigger version to mga1 than mga2 has is +</I>>>>><i> allowed as it will otherwise restrict backporting +</I>>>>><i> too much. (and since its leaf packages, it should +</I>>>>><i> not break (too much)). Lets just make it clear to +</I>>>>><i> everyone using backports. +</I>>>>><i> +</I>>>>><i> 2. we cant really require that as the one backporting +</I>>>>><i> the package to mga1 has to backport it to mga2 too +</I>>>>><i> as he/she might not be using mga2 at all. if someone +</I>>>>><i> wants/needs the backport for mga2, they need to +</I>>>>><i> request that. (in reality, going by how backports +</I>>>>><i> got handled in mdv most backports will end up in +</I>>>>><i> all supported releases anyway) +</I>>><i> +</I>>><i> I would favour adding the requirement that the dependancies of the +</I>>><i> backport must be available in the next release. So that we would expect +</I>><i> +</I>><i> +</I>><i> This is esentially stating that we cant backport any bigger version to +</I>><i> mga2 /backports than mga3 will havein /release wich means when we hit +</I>><i> version freeze for mga3, it also freezes mga2 /backports... +</I> +I'm not following this point. +What I mean is that if backport xx for mga1 requires yy version 12 in +mga1, but yy is version 13 in mga2, we would define the requires for yy +to accept versions 12 to 13 (or maybe wider). +If the user updates to mga2, yy would be updated to version 13, and the +backport would still be expected to work (without being tested). Of +course it is possible that it doesn't for some reason, as it hasn't been +tested. But adding this requirement makes it much more likely to work. + +If there is a further update to mga3, the backport would be replaced by +what was the cauldron package, which would have the appropriate requires. + +>><i> that the backport would continue to function properly on an update to +</I>>><i> the next release, but we don't require that it be tested, so it may not. +</I>><i> +</I>><i> -ENOTCOMPUTE +</I>><i> +</I>><i> "continue to function properly" vs "don't require that it be tested" +</I> +See my explanation above. + +>><i> This is a relatively simple to check, so it won't have a big impact on +</I>>><i> QA, but should increase significantly the reliability of backports. +</I>><i> +</I>><i> Nothing is "simple" if it's supposed to "continue to function properly" +</I>><i> as it then must be tested. +</I> +My point is simply that if we ensure that the backport requires match +what is available in the next release, then it is more likely to work +than if we don't meet this condition. +I'm not saying that it "must" continue to function properly, only that +it is more likely to. +There are many cases where the available packages change, and it +required packages are no longer available, it could be more prudent to +deny the backport. +Just a suggestion. + +>>>><i> If we can agree on this as a start, we can open backports +</I>>>>><i> soon so we get actual facts of how backports policy and +</I>>>>><i> process works. +</I>>>>><i> +</I>>>>><i> Then we rewiew backports policy and process in ~6 months, +</I>>>>><i> and adjust it if needed. +</I>>>>><i> +</I>>>>><i> +</I>>>>><i> +</I>>>>><i> Comments? Questions ? +</I>>><i> +</I>>><i> I would favour tagging backports as update repos, so that in the event +</I>>><i> of a newer backport for security or bug fixes, that it will be +</I>>><i> automatically presented with other updates. +</I>><i> +</I>><i> No. +</I>><i> as the update applet currently works it would show the backport as +</I>><i> an update even if you dont have an earlier backport installed, +</I>><i> defeating the purpose of having separate /updates vs /backports +</I> +This is conditional on first modifying the update tools, as suggested next. +A backport should only update an already installed backport. +(Similarly for nonfree and tainted, if that is not already the case.) +><i> +</I>>><i> This would require some modification to update tools, so it seems to me +</I>>><i> ok to open backports beforehand, with the understanding that the update +</I>>><i> tools would be changed to accommodate this. +</I>><i> +</I>><i> Tools must work before the backports repo affect them. +</I> +I agree that it would be very much better to modify the tools first. +Just suggesting that as an alternative, if we are in a hurry to open +backports. + +><i> -- +</I>><i> Thomas +</I>><i> +</I>-- +André + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="016899.html">[Mageia-dev] Backports Summary +</A></li> + <LI>Next message: <A HREF="016909.html">[Mageia-dev] Backports Summary +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16906">[ date ]</a> + <a href="thread.html#16906">[ thread ]</a> + <a href="subject.html#16906">[ subject ]</a> + <a href="author.html#16906">[ 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> |