diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-January/010892.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-January/010892.html | 228 |
1 files changed, 228 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-January/010892.html b/zarb-ml/mageia-dev/2012-January/010892.html new file mode 100644 index 000000000..2ebbfb856 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010892.html @@ -0,0 +1,228 @@ +<!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=%3C201201031145.13981.bgmilne%40zarb.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="010894.html"> + <LINK REL="Next" HREF="010895.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] RFC: Opening Backports (once again...)</H1> + <B>Buchan Milne</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=%3C201201031145.13981.bgmilne%40zarb.org%3E" + TITLE="[Mageia-dev] RFC: Opening Backports (once again...)">bgmilne at zarb.org + </A><BR> + <I>Tue Jan 3 10:45:13 CET 2012</I> + <P><UL> + <LI>Previous message: <A HREF="010894.html">[Mageia-dev] RFC: Opening Backports (once again...) +</A></li> + <LI>Next message: <A HREF="010895.html">[Mageia-dev] RFC: Opening Backports (once again...) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#10892">[ date ]</a> + <a href="thread.html#10892">[ thread ]</a> + <a href="subject.html#10892">[ subject ]</a> + <a href="author.html#10892">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Saturday, 10 December 2011 13:32:12 Michael Scherer wrote: +><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> +</I>><i> Well, the backport issue ( ie : +</I>><i> - no garantee of keep the distribution upgradable +</I> +Backports will probably provide a better probability of upgradability than +3rd-party repos. + +><i> - no security ) +</I> +No means to provide a security updates that has followed a QA process in the +event package version Z no longer builds on distribution with version X in +release and version Y in backports. + +But, note that without backports, users who wanted version Y would either: +-Switch to a distro that has version Y (worse) - I would guess 20% +-Switch to using cauldron, and start contributing (better) - I would guess 5% +or less +-Use Cauldron package on stable release (worse) - I would guess about 30% +-Build package from source (worse) - I would guess about 20% +-Rebuild cauldron package on stable release (same) - I wold guess about 10% +-Keep version X (better) and eventually become upset about age of software +(worse) - I would guess about 15% + +So, only one outcome would be better, one would be the same, and the other 3 +outcomes would be worse, and probably be the majority of outcomes. + +In the case where there is no problem with providing the update, backports is +superiour, and would provide a better outcome in every case. + +Do we have any idea on how many packages this ever affected in Mandriva? + +><i> have also not been fixed, so that's rather unfair to +</I> +... ? + +><i> > So here is a suggestion to get some value to our endusers: +</I>><i> > +</I>><i> > we add a backports branch on svn +</I>><i> > +</I>><i> > So packages for backports would use: +</I>><i> > +</I>><i> > svn.mageia.org/packages/backports/1/<package>/{current,pristine,releases} +</I>><i> > +</I>><i> > and allow that to be used for backports. +</I>><i> > +</I>><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 thought the whole point of Backports was to provide a streamlined way to +provide newer versions of packages that already exist in Cauldron, with +minimal effort, to stable releases. This increases the incentive for users on +stable releases to contribute to Cauldron in some way, and doesn't increase +the burden on the maintainer significantly. There should be no need to have +distribution release-specific content in any of the packages. + +In the rare case a package can't be provided like this, maybe it isn't a good +candidate for backports? + +><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> +</I>><i> +</I>><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> +So, we have two copies of identical packages, that are always in sync, and can +never diverge. + +What is the point then? Just to allow build system rules not to be violated +(by using a branch)? + +><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> +</I>><i> - youri config to let people submit from backports to backports_testing. +</I> +What does this all achieve that would not be achieved by allowing submission +from cauldron to backports_testing ? + +Regards, +Buchan +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="010894.html">[Mageia-dev] RFC: Opening Backports (once again...) +</A></li> + <LI>Next message: <A HREF="010895.html">[Mageia-dev] RFC: Opening Backports (once again...) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#10892">[ date ]</a> + <a href="thread.html#10892">[ thread ]</a> + <a href="subject.html#10892">[ subject ]</a> + <a href="author.html#10892">[ 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> |