diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-December/010314.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-December/010314.html | 169 |
1 files changed, 169 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-December/010314.html b/zarb-ml/mageia-dev/2011-December/010314.html new file mode 100644 index 000000000..5053fa220 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-December/010314.html @@ -0,0 +1,169 @@ +<!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=%3C201112101400.21697.alien%40rmail.be%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="010310.html"> + <LINK REL="Next" HREF="010328.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] RFC: Opening Backports (once again...)</H1> + <B>Maarten Vanraes</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=%3C201112101400.21697.alien%40rmail.be%3E" + TITLE="[Mageia-dev] RFC: Opening Backports (once again...)">alien at rmail.be + </A><BR> + <I>Sat Dec 10 14:00:21 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="010310.html">[Mageia-dev] RFC: Opening Backports (once again...) +</A></li> + <LI>Next message: <A HREF="010328.html">[Mageia-dev] RFC: Opening Backports (once again...) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#10314">[ date ]</a> + <a href="thread.html#10314">[ thread ]</a> + <a href="subject.html#10314">[ subject ]</a> + <a href="author.html#10314">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Op zaterdag 10 december 2011 12:32:12 schreef Michael Scherer: +><i> Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit : +</I>><i> > Now, +</I>><i> > +</I>><i> > here comes the question about backports once again. +</I>><i> > +</I>><i> > We are now 6+ months into Mageia 1, and we are nowhere closer to opening +</I>><i> > backports that we were at Mageia 1 release time. +</I>><i> > +</I>><i> > Because of that there are 3rdparty repos popping up everywhere..., +</I>><i> > something we hoped to avoid atleast partly when starting this project. +</I>[...] +><i> > And to be honest I dont see that changing anytime soon... +</I>><i> +</I>><i> Then we have a bigger problem to solve. +</I> +This is likely correct, i think we have shortage of people in various parts, +but perhaps sysadmin (which is arguably the most important team), has not +enough active people to follow up all the issues (or they are busy with other +teams). + +because other teams are counting on sysadmin team and even though it's all on +svn, it's not that easy (i think; at least for me) to learn this system and +put some patches for sysadmin to follow, perhaps sysadmin team should grow a +bit more people. + +[...] +><i> > Using a separate branch is also a cleaner way of providing +</I>><i> > backports, and makes it easy to separate changes needed only +</I>><i> > for Cauldron (or backports). +</I>><i> +</I>><i> Then in practice, that mean having a 2nd/3rd distribution ( because +</I>><i> there is a separate 2nd svn branch, and a 3rd one for later ) and so +</I>><i> that's a big no for me. Having 2+ branchs is just asking for trouble +</I>><i> when they are not in sync ( and since keeping everything in sync +</I>><i> properly with svn is a pain if there is a divergence, this will not be +</I>><i> done ). +</I>><i> +</I>><i> Worst, if we do like in mdv and propose 2 way of backporting ( submit +</I>><i> from cauldron, submit from a branch ), this will create a mess of having +</I>><i> some packages from cauldron, some from the branch, and people having no +</I>><i> way from knowing where does a package come from. This also make the +</I>><i> system harder to maintain and to follow, and rather impossible to script +</I>><i> properly. +</I>><i> +</I>><i> So that's also to be avoided. +</I>><i> +</I>><i> Having a separate branch where people can write also remove the only +</I>><i> incentive I have seen for backports, ie, wider testing of our packages, +</I>><i> because they may not really the same as in cauldron. +</I> +I think there are more incentives than just that for backports, at least imho. + +plus, if the problem is you don't know where it's from, perhaps we should fix +that problem instead of having an arguably less flexible solution. also, iirc, +when branching svn, afaik it mentions where it's been branched from? + +><i> So here is what I propose : +</I>><i> +</I>><i> - have X branchs, but do not let anyone commit on it, besides a system +</I>><i> user. When a package is submitted to cauldron, it is also copied to this +</I>><i> branch, ie, we make sure current is in sync. The same goes for version +</I>><i> N-1 being copied from N once a backported rpm have been submitted to be +</I>><i> used by people. Once a distribution is no longer supported, we close the +</I>><i> branch, and disable the sync. +</I>><i> +</I>><i> - backports are only submitted from the branch, with separate +</I>><i> markrelease, tags, whatever. This let us have proper audit of backports, +</I>><i> and who did what. +</I>><i> +</I>><i> - packagers still need to commit and submit on cauldron before any +</I>><i> backports. So we miss no fixes or anything by mistake. We also make sure +</I>><i> that cauldron is always the highest version possible, thus permitting at +</I>><i> least some form of upgrade. ( either stable to stable, provided +</I>><i> backports are used, or stable to cauldron ). And we also ensure that +</I>><i> backports are done first on the most recent stable version, for the same +</I>><i> reason ( ensure some form of upgrade path, as asked several time by +</I>><i> users ). +</I>><i> +</I>><i> And we can still use %ifdef if a need arise for a different spec between +</I>><i> distribution versions. While that make spec less readable, that's more +</I>><i> readable than having forked specs 2 or 3 times. +</I>><i> +</I>><i> This requires : +</I>><i> +</I>><i> - 1 youri action to copy the package to current backport branch ( can be +</I>><i> done based on the markrelease action and the others ) +</I>><i> +</I>><i> - 1 svn configuration to prevent people from writing directly there ( or +</I>><i> just say to not do it, and burn people who do it ) +</I>><i> +</I>><i> - youri config to let people submit from backports to backports_testing. +</I> +for me this solution would be ok, but iirc tmb requires for kernel a bit more +flexibility? + +and tbh, having a more dirty spec file is not something i'd wish for... + +but, even if this is a nice solution, we still have the problem listed above +that we'd get backports since before mageia1 and it's still not here? since +it's also not the priority (updates are more important) what chances do we +have of actually having backports before mga2? +</PRE> + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="010310.html">[Mageia-dev] RFC: Opening Backports (once again...) +</A></li> + <LI>Next message: <A HREF="010328.html">[Mageia-dev] RFC: Opening Backports (once again...) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#10314">[ date ]</a> + <a href="thread.html#10314">[ thread ]</a> + <a href="subject.html#10314">[ subject ]</a> + <a href="author.html#10314">[ 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> |