diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005364.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005364.html | 314 |
1 files changed, 314 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005364.html b/zarb-ml/mageia-dev/2011-June/005364.html new file mode 100644 index 000000000..50787d543 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005364.html @@ -0,0 +1,314 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Missing packages in Mageia 1. How to backport? + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Missing%20packages%20in%20Mageia%201.%20How%20to%20backport%3F&In-Reply-To=%3C4DF22E57.2080900%40colin.guthr.ie%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="005346.html"> + <LINK REL="Next" HREF="005336.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Missing packages in Mageia 1. How to backport?</H1> + <B>Colin Guthrie</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Missing%20packages%20in%20Mageia%201.%20How%20to%20backport%3F&In-Reply-To=%3C4DF22E57.2080900%40colin.guthr.ie%3E" + TITLE="[Mageia-dev] Missing packages in Mageia 1. How to backport?">mageia at colin.guthr.ie + </A><BR> + <I>Fri Jun 10 16:46:47 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005346.html">[Mageia-dev] Missing packages in Mageia 1. How to backport? +</A></li> + <LI>Next message: <A HREF="005336.html">[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5364">[ date ]</a> + <a href="thread.html#5364">[ thread ]</a> + <a href="subject.html#5364">[ subject ]</a> + <a href="author.html#5364">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>'Twas brillig, and Michael Scherer at 10/06/11 13:51 did gyre and gimble: +><i> Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit : +</I>>><i> So the user that just wants to install supybot has to expose themselves +</I>>><i> to the risk of updating to a backported version of gnome or KDE.... this +</I>>><i> is hardly ideal. Especially for novice users. +</I>><i> +</I>><i> One alternative would be to make sure that backports for version 1 are +</I>><i> fully supported and break nothing. +</I> +That's certainly worth considering. + +>><i> This seems like a strange statement as */updates on mdv was allowed to +</I>>><i> have new packages in some cases (I've done it before, although I think +</I>>><i> only for * == contrib), so I don't see why we have to restrict this +</I>>><i> possibility in Mageia. +</I>><i> +</I>><i> contrib/updates was basically not watched at all. People could send +</I>><i> anything without trouble, and there was no policy ( nor any enforcement +</I>><i> ). That's not really the best example to use :) +</I> +Hmm, I can't really disagree with that statement :D + +>>><i> We have used backports in the past for that, and I see no reason to +</I>>>><i> change that. +</I>>><i> +</I>>><i> This is fine in the regular course of distro evolution, but here we're +</I>>><i> talking about users migrating from Mdv to Mga and finding "stale" Mdv +</I>>><i> packages still installed on their system when they want (and we want to +</I>>><i> provide) a Mageia version. This is very much a special case for this +</I>>><i> transitional period but I feel it's an important one, particularly +</I>>><i> *because* it's the first release. +</I>><i> +</I>><i> All releases are equal. And we warned that we would not be able to do +</I>><i> everything, so of course, we will have problem with those that lived on +</I>><i> Mars under a rock, but I think that most people know that we couldn't +</I>><i> have all. +</I> +Quite. But if the only reason for not providing a particular service or +offering is due to a policy (i.e. people want to provide and others want +to consume) then it's perhaps the policy that need re-evaluating. Just +because it's policy, doesn't mean it's the best solution. Pragmatism +often solves a lot of problems. As I said before I think we can easily +over analyse things... + +>><i> I think you're thinking in absolute terms rather than transitional +</I>>><i> terms. In absolute terms I agree with you on principle, but I think we +</I>>><i> need to deal with transitional issues gracefully and not treat them as +</I>>><i> second class considerations. +</I>><i> +</I>><i> It was not clear for me from your mail that this would be temporary. +</I>><i> +</I>><i> So I assume we can agree to enforce the "new packages go to backports +</I>><i> unless very specific and defined exceptions" policy for version 2 of the +</I>><i> release ? +</I> +Yeah I'd personally be more than happy with that. + +><i> If this is temporary, it would be ok, provided we follows the usual +</I>><i> rules about handling updates. +</I>><i> +</I>><i> As we do not want to have untested rpms backported in */updates, this +</I>><i> mean that package must be checked by QA before ( and proper testing for +</I>><i> a new rpm is more that just checking it doesn't break ). +</I>><i> +</I>><i> So it should follow the proper policy ( once we agreed on that ). +</I>><i> +</I>><i> As discussed in the previous thread, that would for example mean that +</I>><i> the packager that submit the backport is not the one testing it and +</I>><i> giving the go, even if he can test before submitting to avoid wasting QA +</I>><i> time. +</I> +That all seems reasonable to me (although I think the QA people can also +be a bit "fast and loose" with some requests (obviously at their own +discretion) - e.g. I doubt they really need to massively test the impact +to other packages of adding something like dd_rescue, more just test +that it "runs OK") + +><i> Since we want to restrict to package that people have used and missed +</I>><i> for upgrade, I would also add that this part should be checked and +</I>><i> requires : +</I>><i> - a bug report saying "upgrade failed due to that" +</I>><i> - if we want to be inclusive, a forum post could do the trick ( provided +</I>><i> it is in english, or a bug referencing the forum ) +</I>><i> - package must be kept upgradable from mandriva 2010.1 +</I>><i> - ideally, the upgrade path should be tested, but I am pretty sure that +</I>><i> people will not :). +</I> +Yeah I agree to that. I think that while you're right about testing the +upgrade and that it will likely not be fully tested, we can still do a +"what version does mdv 2010.2 have?, what version do we have? Will it +upgrade?" conceptual test (i.e. ask the questions!) which should cover +98.23% of the cases). (made up stat obviously!) + + +><i> Finally, I would also add that as soon a package is in updates or +</I>><i> release, the usual rules should apply ( ie, no more exception ). If I +</I>><i> push the package to */updates once getmail because it is missing, but +</I>><i> the next package do not go to */updates unless it fullfill the usual +</I>><i> rules. Any following backports goes to */backports. +</I> +Makes sense yes. + + +><i> And, just to be clear, the policy only apply to version 1, for x86_64 +</I>><i> and i586. +</I> +WFM. + +><i> One question would be "what is a pacakge requires a complex backport", +</I>><i> for example, someone yesterday asked for darcs, that requires ghc, that +</I>><i> requires bootstrapping. +</I>><i> +</I>><i> Yes, no ? Why ? +</I> +If this kind of thing crops up, I think we can discuss it at the time. +As we will have to go through QA process anyway (albeit fast tracked) +there will have to be some packager<->QA interaction anyway. + + +>>><i> If the problem is that backports were too buggy in the past, then we +</I>>>><i> should fix backports process, not bypassing them. +</I>>><i> +</I>>><i> I don't think this is particularly relevant. Backports are unsupported +</I>>><i> generally. That's a given. +</I>><i> +</I>><i> Before, it was Mandriva that said "we don't support backport", but we +</I>><i> can do thing differently. +</I> +True... + +><i> We do offer them, we spoke of the application made by Stormi to manage +</I>><i> backports request ( among others ), and it was asked to install it on +</I>><i> our servers. So to me, for something unsupported, it seems to be rather +</I>><i> well integrated. +</I> +Well we didn't purposefully break backports before either, and of course +some people did look after it nicely. Just because it's not actively +supported doesn't necessarily mean it's not well integrated either. They +are not mutually exclusive. + +><i> So the question is "what do people mean exactly when they say "backports +</I>><i> are unsupported" and what would it change when compared to updates, +</I>><i> which is supported by definition" ? +</I>><i> +</I>><i> Ie, I think we as a community support them to some extend, and so we +</I>><i> should explain what can people expect, and what they cannot. +</I>><i> And if possible, in a positive way ( as one issue we had with backport +</I>><i> was that people kept telling "do not use it", which is why people do not +</I>><i> use it ). +</I>><i> +</I>><i> Ie, I have a backport installed, would I receive new version, or not ? +</I>><i> I found a bug, can I fill it in bugs.mageia.org, or not ? +</I>><i> Etc, etc. +</I> +Yes, this makes sense. + + +>>><i> And if we start by pushing new version in update, people will soon +</I>>>><i> wonder why the new version of X is in updates, while the new version of +</I>>>><i> Y is not, just because we didn't have X in release and Y was there. +</I>>><i> +</I>>><i> I very much consider "nothing -> version X" quite different from +</I>>><i> "version X -> version Y". I don't think it's a hard concept for anyone +</I>>><i> to grasp. +</I>><i> +</I>><i> We kept telling to people that we do not want to place new version in +</I>><i> update, and if we start to do the contrary, this is not really coherent. +</I>><i> +</I>><i> So while this can be justified, I think we should take in account +</I>><i> communication with users to clearly explain why we do, and why this is +</I>><i> temporary. +</I>><i> +</I>><i> I guess a blog post would do the trick, so would you be volunteer for +</I>><i> that if needed ? +</I> +If required yeah I can write up the outcome of this once the dust has +settled :) + +Cheers as always. + +Col + + +-- + +Colin Guthrie +mageia(at)colin.guthr.ie +<A HREF="http://colin.guthr.ie/">http://colin.guthr.ie/</A> + +Day Job: + Tribalogic Limited [<A HREF="http://www.tribalogic.net/">http://www.tribalogic.net/</A>] +Open Source: + Mageia Contributor [<A HREF="http://www.mageia.org/">http://www.mageia.org/</A>] + PulseAudio Hacker [<A HREF="http://www.pulseaudio.org/">http://www.pulseaudio.org/</A>] + Trac Hacker [<A HREF="http://trac.edgewall.org/">http://trac.edgewall.org/</A>] +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005346.html">[Mageia-dev] Missing packages in Mageia 1. How to backport? +</A></li> + <LI>Next message: <A HREF="005336.html">[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5364">[ date ]</a> + <a href="thread.html#5364">[ thread ]</a> + <a href="subject.html#5364">[ subject ]</a> + <a href="author.html#5364">[ 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> |