[Mageia-dev] please stop doing "bugs" for updating magia 1

Wed Jan 11 20:32:59 CET 2012

Le mercredi 11 janvier 2012 à 17:48 +0100, Christian Lohmaier a écrit :
+> On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse
+> <guillomovitch at gmail.com> wrote:
+> > Le 11/01/2012 16:09, Antoine Pitrou a écrit :
+> >
+> >> As a Mageia user I would expect Mageia to package significant *bugfix
+> >> releases* and ship them in the updates for the stable distro.
+> >
+> > You'd rather read the current update policy, rather than expect blind
+> > assertions:
+> > https://wiki.mageia.org/en/Updates_policy
+> 
+> Whoa - this is a rather stupid policy. (my opinion, yours obviously differs).
+> "For the most part, an update should consist of a <bold>patched build
+> of the same version</bold> of the package released with the
+> distribution,"
+
+I am pretty sure that you can express yourself without starting by
+insulting people. That would surely help to be listened ( cause right
+now, I must tell that I am not very keen on that )
+
+> Welcome to distro-isolation, putting burden on maintainers, giving
+> them all the reason to deny a reasonable request for a bugfix release
+> because it just is too much work to hunt for a specific commit that
+> fixed bug x.
+
+If that's too much work for a maintainer and if that's important for
+you, you can :
+- do your own package, supported by yourself for yourself
+or :
+- provide the patch
+
+If that's too much work for you too, then that's likely too much work
+for others too.
+
+> >> For example, it would be nice if an up-to-date Mageia 1 system had
+> >> Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course,
+> >> but nice). There's more than a hundred bug fixes between the two
+> >> versions and I don't expect Mageia to have independently fixed many of
+> >> these bugs.
+> >
+> > A bug may vary from a typo in a man page to a critical security update,
+> 
+> And a typo-fix is not worthwhile to have?
+
+When we take in account the fact it would still need proper QA, there is
+likely stuff that are more important than a typo. And a typo is just a
+extreme case, and a simplificaition. If we start to have a complex
+update policy, we are just losing time for almost nothing.
+
+> > which make the number of claimed bugfix a poor decision metric. A
+> > non-regression ensurance would be a better one, but it's quite difficult to
+> > assert.
+> 
+> Don't assume all upstream projects are a bunch of clueless idiots.
+
+We didn't say that. We just assume that errors happen to everybody.
+
+> For upstream releases that have a clear version/release scheme, with
+> micro releases being compatible bugfixes only, the above mentioned
+> policy is completely nonsense, same for your fear of regressions, etc.
+
+Regressions do happens. 
+
+> Sure, you cannot be save of regressions, but what makes you think you
+> are smarter than upstream? What makes you so sure that not the one
+> commit you add as a patch to your package is the one that causes the
+> regressions?
+
+For 1, we usually do not do distro patch. I personnaly think this should
+be avoided as much as possible, and that we should push as much patch
+upstream. We have a rather huge backlog to clean.
+
+For 2, we also usually take patch from upstream. Some of us are also
+good enough to understand patchs, and to see what they mean, if they fix
+something, etc. Of course, there is some software that are rather
+specialized or obscure, but that's far from being the majority.
+
+> Regressions have the nice habit of being triggered by changes in
+> apparently unrelated code...
+
+
+And that's why we should reduce the number of changes. 
+
+> My 0.02€ only, but I strongly suggest for that update policy to be clarified.
+> When there is no dedicated bugfix release procedure in the upstream
+> package, an update is a rebuild of the same version with a
+> corresponding patch. That's reasonable (as opposed to using a newer
+> minor or even major release, those are backports).
+> But once again: if upstream has a major.minor.micro scheme with micro
+> versions being bugfix releases, I really don't see any sane reason for
+> not "allowing" those updates.
+
+Maybe if you started to be less insulting, and instead started to look
+at the discussion on the ml in the past on the list, when the policy was
+discussed ( and access to the old wiki too ), you would likely find the
+reasons saner.
+
+-- 
+Michael Scherer
+
+