<!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=%3C4FEAE474.5040602%40mageia.org%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="016874.html">
<LINK REL="Next" HREF="016906.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=%3C4FEAE474.5040602%40mageia.org%3E"
TITLE="[Mageia-dev] Backports Summary">tmb at mageia.org
</A><BR>
<I>Wed Jun 27 12:46:12 CEST 2012</I>
<P><UL>
<LI>Previous message: <A HREF="016874.html">[Mageia-dev] Backports Summary
</A></li>
<LI>Next message: <A HREF="016906.html">[Mageia-dev] Backports Summary
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#16899">[ date ]</a>
<a href="thread.html#16899">[ thread ]</a>
<a href="subject.html#16899">[ subject ]</a>
<a href="author.html#16899">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>andre999 skrev 27.6.2012 10:47:
><i> Thomas Backlund a écrit :
</I>>><i> Thomas Backlund skrev 26.6.2012 22:25:
</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>
This is esentially stating that we cant backport any bigger version to
mga2 /backports than mga3 will havein /release wich means when we hit
version freeze for mga3, it also freezes mga2 /backports...
><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>
-ENOTCOMPUTE
"continue to function properly" vs "don't require that it be tested"
><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>
Nothing is "simple" if it's supposed to "continue to function properly"
as it then must be tested.
>>><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>
No.
as the update applet currently works it would show the backport as
an update even if you dont have an earlier backport installed,
defeating the purpose of having separate /updates vs /backports
><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>
Tools must work before the backports repo affect them.
--
Thomas
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="016874.html">[Mageia-dev] Backports Summary
</A></li>
<LI>Next message: <A HREF="016906.html">[Mageia-dev] Backports Summary
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#16899">[ date ]</a>
<a href="thread.html#16899">[ thread ]</a>
<a href="subject.html#16899">[ subject ]</a>
<a href="author.html#16899">[ 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>