From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-January/011240.html | 144 ++++++++++++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-January/011240.html (limited to 'zarb-ml/mageia-dev/2012-January/011240.html') diff --git a/zarb-ml/mageia-dev/2012-January/011240.html b/zarb-ml/mageia-dev/2012-January/011240.html new file mode 100644 index 000000000..7e84c9d19 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011240.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

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

+ Pascal Terjan + pterjan at gmail.com +
+ Wed Jan 11 17:54:57 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 16:48, Christian Lohmaier
+<lohmaier+mageia at googlemail.com> wrote:
+> 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,"
+>
+> 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.
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1