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

[Michael Scherer]

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