diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-June/017057.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-June/017057.html | 251 |
1 files changed, 251 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-June/017057.html b/zarb-ml/mageia-dev/2012-June/017057.html new file mode 100644 index 000000000..4c22e7787 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/017057.html @@ -0,0 +1,251 @@ +<!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=%3C2659462.pflZmYAzUM%40tiger.ranger.dnsalias.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="016911.html"> + <LINK REL="Next" HREF="016966.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Backports Summary</H1> + <B>Buchan Milne</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20Summary&In-Reply-To=%3C2659462.pflZmYAzUM%40tiger.ranger.dnsalias.com%3E" + TITLE="[Mageia-dev] Backports Summary">bgmilne at zarb.org + </A><BR> + <I>Thu Jun 28 09:57:00 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="016911.html">[Mageia-dev] Backports Summary +</A></li> + <LI>Next message: <A HREF="016966.html">[Mageia-dev] Backports Summary +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#17057">[ date ]</a> + <a href="thread.html#17057">[ thread ]</a> + <a href="subject.html#17057">[ subject ]</a> + <a href="author.html#17057">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Tuesday, 26 June 2012 22:25:10 Thomas Backlund wrote: +><i> So, +</I>><i> we have been discussing this many times, and not gotten any +</I>><i> satisfactory decision to go ahead yet... +</I> +Sorry for the late reply, but as some of you are aware, I have had some +problems replying to Mageia-related mails (which are finally resolved). + +><i> First off, we decided long ago that backports will be +</I>><i> better supported than during mdv times, +</I> +This may be an unfair generalisation. + +><i> meaning security +</I>><i> and bugfixes and has to pass QA. +</I> +In some cases, this is a basic feature of backports. For example, the primary +targets of my backports typically ship new releases for any security fix, and +bugfixes are typically released in new releases (and only in severe cases do +we cherry-pick the bugfix from a new release for a bugfix update). + +In the case of samba, openldap etc., my primary motivation for wanting +backports is so that we can provide early bugfixes (which in most cases have +been well tested by the rest of the upstream community) with less delay than +cherry-picking bugfixes, QA, etc. + +The other motivation for me, is to make newly packaged software in cauldron +available to stable releases. The probability of a security update being +required is usually quite low in this case. + +><i> Now for references: +</I>><i> * we have the backports policy: +</I>><i> <A HREF="https://wiki.mageia.org/en/Backports_policy">https://wiki.mageia.org/en/Backports_policy</A> +</I> +I think we are over-engineering everything here. + +See for example: +<A HREF="https://www.google.com/search?q=%22main/backports%20openldap-2.4%22%20site:lists.mandriva.com">https://www.google.com/search?q=%22main/backports%20openldap-2.4%22%20site:lists.mandriva.com</A> + +For openldap, since upstream doesn't really look at bugs on old releases, I +backported every new release to every version that had a build system +available. + +In all that time, there was only ever one bug reported on the backports, due +to a NMU backport. + +><i> * Last discussions started by Stormi: +</I>><i> * [Mageia-dev] Backports policy clarification (and discussion) +</I>><i> <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> +</I>><i> +</I>><i> * [Mageia-dev] Proposed Feature:Backports_update_applet +</I>><i> <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> +</I>><i> +</I>><i> * It also came up in the discussion about fixing bug 2317: +</I>><i> * [Mageia-dev] bug 2317 revisited: --update option should behave like +</I>><i> --search-media +</I>><i> <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> +</I>><i> +</I>><i> +</I>><i> People seem to agree on most things, but there is a few questions +</I>><i> that need to be decided how to handle. +</I>><i> +</I>><i> +</I>><i> +</I>><i> +</I>><i> Lets start with the summary and suggestion of how to get it started: +</I>><i> (addendum / refinements / important points of current backports policy) +</I>><i> +</I>><i> * backports is supported as long as the rest of the release +</I> +But this is not a committment to always backport every already-backported +package. + +><i> * packages must always be in cauldron first +</I> +Of course. + +><i> * if you want to backport a package someone else is maintainer +</I>><i> for, you need to discuss with maintainer first. if he dont +</I>><i> want the package to be backported _and_ have valid reasons, +</I>><i> respect that. (if you disagree, you can still ask council) +</I>><i> * if you backport anything, (regardless if you are the real +</I>><i> maintainer or not) you accept the responsibility of +</I>><i> handling the bugreports against the backport and make sure +</I>><i> it gets patched (or upgraded) to get security fixes. +</I>><i> * cherrypicking backports must work, so requires need +</I>><i> to be checked and be strict to make sure they work +</I> +Agreed, but it is not critical to QA every possible combination of packages. +Users are able to resolve these problems themselves, and report the problem. + +><i> * nothing in backports must require the use of "--nodeps" +</I>><i> or "--force" to get it to install +</I>><i> * QA will do basic tests to make sure it works and obeys the rules +</I>><i> * QA can deny package(s) to be backported if it breaks the policy +</I>><i> * QA has /updates as priority, and /backports will be handled +</I>><i> if/when there is time, so if you want faster response, join QA +</I>><i> to help out with the workload. +</I> +Hmm, in many cases, I actually test backports on the stable release myself +before submitting them ... I am concerned QA will become a bottle-neck that +doesn't necessarily always add much value. + +><i> Now a point that got raised during discussion of bug 2317: +</I>><i> * if a backport break because of something ending up in /updates +</I>><i> it's a bug to be reported against the backport (and not against +</I>><i> the released update) as packages ending up in /updates are only +</I>><i> validated against /release and /updates (and rightfully so as +</I>><i> thats how they are built too) +</I>><i> +</I>><i> +</I>><i> +</I>><i> And some important points to avoid making backports_testing a +</I>><i> "dumping ground" for package(r)s trying to avoid the policy: +</I>><i> * after submitting anything to backports_testing you have +</I>><i> 48 hours to file/assign a "Backport to validate" at +</I>><i> bugs.mageia.org. +</I>><i> * package needs to be validated within 1 month (or shorter/longer +</I>><i> time if QA wants that) +</I>><i> * failure to match any of the two timelimits will get the +</I>><i> package removed from updates_testing again. (I understand this +</I>><i> will get some questions, but if we cant get people to help out +</I>><i> with QA we might as well never open backports) +</I> +I would prefer if we could crowd-source and automate this, otherwise, again, +this will be the bottle-neck. + +><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> +As long as it was backported to mga2 first. + +><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> +E.g., if upgrading from mga1 to mga2 and having used backports after mga2 +release, the users should enable backports in mga2 during upgrade, or post- +upgrade. + +><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> +Yes. + +><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> +What about an update to a backport for a security issue? + +><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> +Typically, if it backports easily to mga1, it will backport more easily to +mga2. + +><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 think we may want to review this policy one month after we open backports, +as I think some pieces in the process/policy may not scale as well as the +others. + +Regards, +Buchan +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: </pipermail/mageia-dev/attachments/20120628/42c04d86/attachment-0001.html> +</PRE> + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="016911.html">[Mageia-dev] Backports Summary +</A></li> + <LI>Next message: <A HREF="016966.html">[Mageia-dev] Backports Summary +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#17057">[ date ]</a> + <a href="thread.html#17057">[ thread ]</a> + <a href="subject.html#17057">[ subject ]</a> + <a href="author.html#17057">[ 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> |