On Wed, Jan 11, 2012 at 16:48, Christian Lohmaier <lohmaier+mag...@googlemail.com> wrote: > On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse > <guillomovi...@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," > > 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. > >>> 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? > >> 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.
Don't assume the opposite either, it really depend on each project. > 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. Yes, bugfix only release have always been accepted, this should be added to the exceptions on the wiki. > 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? Because the most changes you had, the most likely a regression is > Regressions have the nice habit of being triggered by changes in > apparently unrelated code... > > 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. Yes, they are actually allowed.