[Mageia-dev] Missing packages in Mageia 1. How to backport?

Fri Jun 10 16:46:47 CEST 2011

'Twas brillig, and Michael Scherer at 10/06/11 13:51 did gyre and gimble:
+> Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit :
+>> So the user that just wants to install supybot has to expose themselves
+>> to the risk of updating to a backported version of gnome or KDE.... this
+>> is hardly ideal. Especially for novice users.
+> 
+> One alternative would be to make sure that backports for version 1 are
+> fully supported and break nothing. 
+
+That's certainly worth considering.
+
+>> This seems like a strange statement as */updates on mdv was allowed to
+>> have new packages in some cases (I've done it before, although I think
+>> only for * == contrib), so I don't see why we have to restrict this
+>> possibility in Mageia.
+> 
+> contrib/updates was basically not watched at all. People could send
+> anything without trouble, and there was no policy ( nor any enforcement
+> ). That's not really the best example to use :)
+
+Hmm, I can't really disagree with that statement :D
+
+>>> We have used backports in the past for that, and I see no reason to
+>>> change that.
+>>
+>> This is fine in the regular course of distro evolution, but here we're
+>> talking about users migrating from Mdv to Mga and finding "stale" Mdv
+>> packages still installed on their system when they want (and we want to
+>> provide) a Mageia version. This is very much a special case for this
+>> transitional period but I feel it's an important one, particularly
+>> *because* it's the first release.
+> 
+> All releases are equal. And we warned that we would not be able to do
+> everything, so of course, we will have problem with those that lived on
+> Mars under a rock, but I think that most people know that we couldn't
+> have all.
+
+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 think you're thinking in absolute terms rather than transitional
+>> terms. In absolute terms I agree with you on principle, but I think we
+>> need to deal with transitional issues gracefully and not treat them as
+>> second class considerations.
+> 
+> It was not clear for me from your mail that this would be temporary. 
+> 
+> So I assume we can agree to enforce the "new packages go to backports
+> unless very specific and defined exceptions" policy for version 2 of the
+> release ? 
+
+Yeah I'd personally be more than happy with that.
+
+> If this is temporary, it would be ok, provided we follows the usual
+> rules about handling updates.
+> 
+> As we do not want to have untested rpms backported in */updates, this
+> mean that package must be checked by QA before ( and proper testing for
+> a new rpm is more that just checking it doesn't break ). 
+> 
+> So it should follow the proper policy ( once we agreed on that ).
+> 
+> As discussed in the previous thread, that would for example mean that
+> the packager that submit the backport is not the one testing it and
+> giving the go, even if he can test before submitting to avoid wasting QA
+> time.
+
+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")
+
+> Since we want to restrict to package that people have used and missed
+> for upgrade, I would also add that this part should be checked and
+> requires :
+> - a bug report saying "upgrade failed due to that"
+> - if we want to be inclusive, a forum post could do the trick ( provided
+> it is in english, or a bug referencing the forum )
+> - package must be kept upgradable from mandriva 2010.1
+> - ideally, the upgrade path should be tested, but I am pretty sure that
+> people will not :).
+
+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!)
+
+
+> Finally, I would also add that as soon a package is in updates or
+> release, the usual rules should apply ( ie, no more exception ). If I
+> push the package to */updates once getmail because it is missing, but
+> the next package do not go to */updates unless it fullfill the usual
+> rules. Any following backports goes to */backports. 
+
+Makes sense yes.
+
+
+> And, just to be clear, the policy only apply to version 1, for x86_64
+> and i586.
+
+WFM.
+
+> One question would be "what is a pacakge requires a complex backport",
+> for example, someone yesterday asked for darcs, that requires ghc, that
+> requires bootstrapping. 
+> 
+> Yes, no ? Why ?
+
+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.
+
+
+>>> If the problem is that backports were too buggy in the past, then we
+>>> should fix backports process, not bypassing them.
+>>
+>> I don't think this is particularly relevant. Backports are unsupported
+>> generally. That's a given. 
+> 
+> Before, it was Mandriva that said "we don't support backport", but we
+> can do thing differently.
+
+True...
+
+> We do offer them, we spoke of the application made by Stormi to manage
+> backports request ( among others ), and it was asked to install it on
+> our servers. So to me, for something unsupported, it seems to be rather
+> well integrated.
+
+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.
+
+> So the question is "what do people mean exactly when they say "backports
+> are unsupported" and what would it change when compared to updates,
+> which is supported by definition" ?
+> 
+> Ie, I think we as a community support them to some extend, and so we
+> should explain what can people expect, and what they cannot.
+> And if possible, in a positive way ( as one issue we had with backport
+> was that people kept telling "do not use it", which is why people do not
+> use it ).
+> 
+> Ie, I have a backport installed, would I receive new version, or not ?
+> I found a bug, can I fill it in bugs.mageia.org, or not ?
+> Etc, etc. 
+
+Yes, this makes sense.
+
+
+>>> And if we start by pushing new version in update, people will soon
+>>> wonder why the new version of X is in updates, while the new version of
+>>> Y is not, just because we didn't have X in release and Y was there.
+>>
+>> I very much consider "nothing -> version X" quite different from
+>> "version X -> version Y". I don't think it's a hard concept for anyone
+>> to grasp.
+> 
+> We kept telling to people that we do not want to place new version in
+> update, and if we start to do the contrary, this is not really coherent.
+> 
+> So while this can be justified, I think we should take in account
+> communication with users to clearly explain why we do, and why this is
+> temporary.
+> 
+> I guess a blog post would do the trick, so would you be volunteer for
+> that if needed ?
+
+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
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+