summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/2011-December/010328.html
diff options
context:
space:
mode:
Diffstat (limited to 'zarb-ml/mageia-dev/2011-December/010328.html')
-rw-r--r--zarb-ml/mageia-dev/2011-December/010328.html218
1 files changed, 218 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-December/010328.html b/zarb-ml/mageia-dev/2011-December/010328.html
new file mode 100644
index 000000000..3a4c966fd
--- /dev/null
+++ b/zarb-ml/mageia-dev/2011-December/010328.html
@@ -0,0 +1,218 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [Mageia-dev] RFC: Opening Backports (once again...)
+ </TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20RFC%3A%20Opening%20Backports%20%28once%20again...%29&In-Reply-To=%3C4EE38434.7040606%40mageia.org%3E">
+ <META NAME="robots" CONTENT="index,nofollow">
+ <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
+ <LINK REL="Previous" HREF="010314.html">
+ <LINK REL="Next" HREF="010350.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[Mageia-dev] RFC: Opening Backports (once again...)</H1>
+ <B>Thomas Backlund</B>
+ <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20RFC%3A%20Opening%20Backports%20%28once%20again...%29&In-Reply-To=%3C4EE38434.7040606%40mageia.org%3E"
+ TITLE="[Mageia-dev] RFC: Opening Backports (once again...)">tmb at mageia.org
+ </A><BR>
+ <I>Sat Dec 10 17:09:24 CET 2011</I>
+ <P><UL>
+ <LI>Previous message: <A HREF="010314.html">[Mageia-dev] RFC: Opening Backports (once again...)
+</A></li>
+ <LI>Next message: <A HREF="010350.html">[Mageia-dev] RFC: Opening Backports (once again...)
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#10328">[ date ]</a>
+ <a href="thread.html#10328">[ thread ]</a>
+ <a href="subject.html#10328">[ subject ]</a>
+ <a href="author.html#10328">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>Michael Scherer skrev 10.12.2011 13:32:
+&gt;<i> Le mardi 06 d&#233;cembre 2011 &#224; 00:56 +0200, Thomas Backlund a &#233;crit :
+</I>&gt;&gt;<i> Now,
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> here comes the question about backports once again.
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> We are now 6+ months into Mageia 1, and we are nowhere closer to opening
+</I>&gt;&gt;<i> backports that we were at Mageia 1 release time.
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> Because of that there are 3rdparty repos popping up everywhere...,
+</I>&gt;&gt;<i> something we hoped to avoid atleast partly when starting this project.
+</I>&gt;<i>
+</I>&gt;<i> Well, the backport issue ( ie :
+</I>&gt;<i> - no garantee of keep the distribution upgradable
+</I>
+
+Policy is to always keep Cauldron with atleast higher release,
+so next release will be ok.
+
+I guess when we have 2 releases we must extend the policy to
+state that if you backport to Mageia 1 you also must backport
+to Mageia 2 in order to keep upgrading fully possible.
+
+
+&gt;<i> - no security )
+</I>
+
+Well, that's the same as with current stable relase,
+maintainer/backporter submits security fixes to backports_testing
+
+QA validates, update gets pushed.
+
+&gt;<i>
+</I>&gt;<i> have also not been fixed, so that's rather unfair to
+</I>&gt;<i>
+</I>&gt;&gt;<i> And at current rate we will probably release Mageia &quot;infinity&quot;
+</I>&gt;&gt;<i> before backports is opened.
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> It has been delayed because of needed infrastructure changes,
+</I>&gt;&gt;<i> something no-one have had time to do so far...
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> I know there is &quot;only some coding missing&quot; and &quot;someone should
+</I>&gt;&gt;<i> do it&quot;, buth truthfully there are only a few that knows the
+</I>&gt;&gt;<i> code used in the buildsystem enough to actually make it happend,
+</I>&gt;&gt;<i> and they are already othervise busy or overloaded...
+</I>&gt;&gt;<i> (this is no rant against them, as all here are using their
+</I>&gt;&gt;<i> personal free time to help out)
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> And to be honest I dont see that changing anytime soon...
+</I>&gt;<i>
+</I>&gt;<i> Then we have a bigger problem to solve.
+</I>&gt;<i>
+</I>
+Yep, no argument here....
+
+
+&gt;&gt;<i> So here is a suggestion to get some value to our endusers:
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> we add a backports branch on svn
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> So packages for backports would use:
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> svn.mageia.org/packages/backports/1/&lt;package&gt;/{current,pristine,releases}
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> and allow that to be used for backports.
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> Using a separate branch is also a cleaner way of providing
+</I>&gt;&gt;<i> backports, and makes it easy to separate changes needed only
+</I>&gt;&gt;<i> for Cauldron (or backports).
+</I>&gt;<i>
+</I>&gt;<i> Then in practice, that mean having a 2nd/3rd distribution ( because
+</I>&gt;<i> there is a separate 2nd svn branch, and a 3rd one for later ) and so
+</I>&gt;<i> that's a big no for me. Having 2+ branchs is just asking for trouble
+</I>&gt;<i> when they are not in sync ( and since keeping everything in sync
+</I>&gt;<i> properly with svn is a pain if there is a divergence, this will not be
+</I>&gt;<i> done ).
+</I>&gt;<i>
+</I>&gt;<i> Worst, if we do like in mdv and propose 2 way of backporting ( submit
+</I>&gt;<i> from cauldron, submit from a branch ), this will create a mess of having
+</I>&gt;<i> some packages from cauldron, some from the branch, and people having no
+</I>&gt;<i> way from knowing where does a package come from. This also make the
+</I>&gt;<i> system harder to maintain and to follow, and rather impossible to script
+</I>&gt;<i> properly.
+</I>&gt;<i>
+</I>&gt;<i> So that's also to be avoided.
+</I>&gt;<i>
+</I>
+Well, branching is needed, regardless if it's done in a whole separate
+branch as I suggested, or in a branch per package when needed.
+
+&gt;<i> Having a separate branch where people can write also remove the only
+</I>&gt;<i> incentive I have seen for backports, ie, wider testing of our packages,
+</I>&gt;<i> because they may not really the same as in cauldron.
+</I>&gt;<i>
+</I>
+It cant always be the same in cauldron and backports.
+
+&gt;<i>
+</I>&gt;<i> So here is what I propose :
+</I>&gt;<i>
+</I>&gt;<i> - have X branchs, but do not let anyone commit on it, besides a system
+</I>&gt;<i> user. When a package is submitted to cauldron, it is also copied to this
+</I>&gt;<i> branch, ie, we make sure current is in sync. The same goes for version
+</I>&gt;<i> N-1 being copied from N once a backported rpm have been submitted to be
+</I>&gt;<i> used by people. Once a distribution is no longer supported, we close the
+</I>&gt;<i> branch, and disable the sync.
+</I>&gt;<i>
+</I>
+If you cant commit to the branch, it's useless.
+
+&gt;<i> - backports are only submitted from the branch, with separate
+</I>&gt;<i> markrelease, tags, whatever. This let us have proper audit of backports,
+</I>&gt;<i> and who did what.
+</I>&gt;<i>
+</I>
+the same auditing is available in any branch or cauldron.
+
+&gt;<i> - packagers still need to commit and submit on cauldron before any
+</I>&gt;<i> backports. So we miss no fixes or anything by mistake. We also make sure
+</I>&gt;<i> that cauldron is always the highest version possible, thus permitting at
+</I>&gt;<i> least some form of upgrade. ( either stable to stable, provided
+</I>&gt;<i> backports are used, or stable to cauldron ). And we also ensure that
+</I>&gt;<i> backports are done first on the most recent stable version, for the same
+</I>&gt;<i> reason ( ensure some form of upgrade path, as asked several time by
+</I>&gt;<i> users ).
+</I>&gt;<i>
+</I>
+Sorry, buth this wont work in reality...
+
+Consider this:
+
+version X in Mageia 1
+version X+1 in Cauldron
+
+version X+1 gets backported.
+
+version X+2 uploaded in Cauldron
+version X+2 cant be backported (depends on updated libs/packages in
+Cauldron, and we dont backport libs that can break working setups)
+
+version X+1 in backports need to be fixed (security/maintenance fix)
+(here your logic breaks down, there is no place to fix it)
+
+
+And since we aim for quality backports, the maintainer may want to
+stay with version X+1 in backports even if X+2 could be backported
+if maintainer think X+2 isn't a good candidate for some reason.
+
+--
+Thomas
+</PRE>
+
+
+
+
+
+
+
+
+
+
+
+
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI>Previous message: <A HREF="010314.html">[Mageia-dev] RFC: Opening Backports (once again...)
+</A></li>
+ <LI>Next message: <A HREF="010350.html">[Mageia-dev] RFC: Opening Backports (once again...)
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#10328">[ date ]</a>
+ <a href="thread.html#10328">[ thread ]</a>
+ <a href="subject.html#10328">[ subject ]</a>
+ <a href="author.html#10328">[ 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>