diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-June/016855.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-June/016855.html | 237 |
1 files changed, 237 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-June/016855.html b/zarb-ml/mageia-dev/2012-June/016855.html new file mode 100644 index 000000000..265a3fa11 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016855.html @@ -0,0 +1,237 @@ +<!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=%3C4FEA0C96.2000905%40mageia.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="016864.html"> + <LINK REL="Next" HREF="016857.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Backports Summary</H1> + <B>Thomas Backlund</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20Summary&In-Reply-To=%3C4FEA0C96.2000905%40mageia.org%3E" + TITLE="[Mageia-dev] Backports Summary">tmb at mageia.org + </A><BR> + <I>Tue Jun 26 21:25:10 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="016864.html">[Mageia-dev] Mageia ARM on Raspberry Pi +</A></li> + <LI>Next message: <A HREF="016857.html">[Mageia-dev] Backports Summary +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16855">[ date ]</a> + <a href="thread.html#16855">[ thread ]</a> + <a href="subject.html#16855">[ subject ]</a> + <a href="author.html#16855">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>So, +we have been discussing this many times, and not gotten any +satisfactory decision to go ahead yet... + + + +First off, we decided long ago that backports will be +better supported than during mdv times, meaning security +and bugfixes and has to pass QA. + + + +Now for references: +* we have the backports policy: + <A HREF="https://wiki.mageia.org/en/Backports_policy">https://wiki.mageia.org/en/Backports_policy</A> + +* Last discussions started by Stormi: + * [Mageia-dev] Backports policy clarification (and discussion) + <A HREF="https://www.mageia.org/pipermail/mageia-dev/2012-June/016265.html">https://www.mageia.org/pipermail/mageia-dev/2012-June/016265.html</A> + + * [Mageia-dev] Proposed Feature:Backports_update_applet + <A HREF="https://www.mageia.org/pipermail/mageia-dev/2012-June/016263.html">https://www.mageia.org/pipermail/mageia-dev/2012-June/016263.html</A> + +* It also came up in the discussion about fixing bug 2317: + * [Mageia-dev] bug 2317 revisited: --update option should behave like +--search-media + <A HREF="https://www.mageia.org/pipermail/mageia-dev/2012-June/016692.html">https://www.mageia.org/pipermail/mageia-dev/2012-June/016692.html</A> + + +People seem to agree on most things, but there is a few questions +that need to be decided how to handle. + + + + +Lets start with the summary and suggestion of how to get it started: +(addendum / refinements / important points of current backports policy) + +* backports is supported as long as the rest of the release +* packages must always be in cauldron first +* if you want to backport a package someone else is maintainer + for, you need to discuss with maintainer first. if he dont + want the package to be backported _and_ have valid reasons, + respect that. (if you disagree, you can still ask council) +* if you backport anything, (regardless if you are the real + maintainer or not) you accept the responsibility of + handling the bugreports against the backport and make sure + it gets patched (or upgraded) to get security fixes. +* cherrypicking backports must work, so requires need + to be checked and be strict to make sure they work +* nothing in backports must require the use of "--nodeps" + or "--force" to get it to install +* QA will do basic tests to make sure it works and obeys the rules +* QA can deny package(s) to be backported if it breaks the policy +* QA has /updates as priority, and /backports will be handled + if/when there is time, so if you want faster response, join QA + to help out with the workload. + + + +Now a point that got raised during discussion of bug 2317: +* if a backport break because of something ending up in /updates + it's a bug to be reported against the backport (and not against + the released update) as packages ending up in /updates are only + validated against /release and /updates (and rightfully so as + thats how they are built too) + + + +And some important points to avoid making backports_testing a +"dumping ground" for package(r)s trying to avoid the policy: +* after submitting anything to backports_testing you have + 48 hours to file/assign a "Backport to validate" at + bugs.mageia.org. +* package needs to be validated within 1 month (or shorter/longer + time if QA wants that) +* failure to match any of the two timelimits will get the + package removed from updates_testing again. (I understand this + will get some questions, but if we cant get people to help out + with QA we might as well never open backports) + + + +And then the questions we need to decide on: +(substitute mga1/mga2 for any future release...) +1. Do we support backporting package with higher version + than package in the following next mageia release has ? + (meaning if mga1 has v12, and mga2 has v14, is it ok + to backport v16 to mga1?) + * PRO: more uptodate package in backports + * CON: can cause trouble during distro upgrade + * imho both technically ok as long as we make sure + its documented so people know what to expect. + +2. If one want to backport a package to mga1, does it mean + it must be backported to mga2 in order to preserve + upgrade path (unless already in mga2, depending on + question 1)? + + + +And since we can continue this what/if discussion forever, +and thereby delay backports even more here is my take on it: + +my suggestions to decide on question 1 and 2: +1. backporting bigger version to mga1 than mga2 has is + allowed as it will otherwise restrict backporting + too much. (and since its leaf packages, it should + not break (too much)). Lets just make it clear to + everyone using backports. + +2. we cant really require that as the one backporting + the package to mga1 has to backport it to mga2 too + as he/she might not be using mga2 at all. if someone + wants/needs the backport for mga2, they need to + request that. (in reality, going by how backports + got handled in mdv most backports will end up in + all supported releases anyway) + + + +If we can agree on this as a start, we can open backports +soon so we get actual facts of how backports policy and +process works. + +Then we rewiew backports policy and process in ~6 months, +and adjust it if needed. + + + +Comments? Questions ? + +-- + +Thomas +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="016864.html">[Mageia-dev] Mageia ARM on Raspberry Pi +</A></li> + <LI>Next message: <A HREF="016857.html">[Mageia-dev] Backports Summary +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16855">[ date ]</a> + <a href="thread.html#16855">[ thread ]</a> + <a href="subject.html#16855">[ subject ]</a> + <a href="author.html#16855">[ 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> |