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/011300.html | 124 ++++++++++++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-January/011300.html (limited to 'zarb-ml/mageia-dev/2012-January/011300.html') diff --git a/zarb-ml/mageia-dev/2012-January/011300.html b/zarb-ml/mageia-dev/2012-January/011300.html new file mode 100644 index 000000000..108e04313 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011300.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

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

+ Florian Hubold + doktor5000 at arcor.de +
+ Thu Jan 12 20:42:37 CET 2012 +

+
+ +
Am 12.01.2012 19:01, schrieb Christian Lohmaier:
+> Hi Juan Luis,
+>
+> On Wed, Jan 11, 2012 at 10:09 PM, Juan Luis Baptiste <juancho at mageia.org> wrote:
+>> [..]
+>> As I said, no one is talking about picking up a fix if there's a bug
+>> fix only release, it's for when it isn't and we need to reduce the
+>> chance of regressions by taking the modifications that *exactly* fix
+>> that bug.
+> I strongly disagree. The policy is stating the exact opposite. And
+> also Michael seems to defend the policy as it is written, and not your
+> interpretation here.
+>
+> That again you might have a different understanding of
+> bugfix-only-release. I think I stated mine often enough (increase in
+> micro version when package follows major.minor.micro versioning scheme
+> and no new features are introduced in micro releases).
+>
+> So please change the wording of the update policy accordingly
+> https://wiki.mageia.org/en/Updates_policy reads:
+> ##########
+> For the most part, an update should consist of a patched build of the
+> same version of the package released with the distribution, with a few
+> exceptions:
+>
+> * Software versions that are no longer supported upstream with updates
+> (firefox and thunderbird seem to fall into this category these days)
+> * Software that is version-bound to an online service (games, virus
+> scanners?) and will only work with the latest version.
+> * We will make exceptions for packages that did not make it into mga1
+> and are additions to the distribution, provided they do not impact any
+> other packages and can pass full QA.
+>
+> Updates are not the appropriate place for packages created to satisfy
+> certain user's urges for "the latest". These types of builds belong in
+> backports.
+> ##########
+> I read it as "no version bumb is allowed (except for the three
+> exception-cases listed) - bugs are only fixed using patches", and I
+> don't see the interpretational freedom to allow upstream's bugfix
+> releases. Updating from 1.3.2 to 1.3.3 would not be in compliance with
+> the policy (if not in one of the three exception cases) - this is what
+> I have called stupid policy (and still do).
+>
+> ciao
+> Christian
+>
+Actually you're right there, currently the only case where a bugfix-only update
+would be allowed would be as an exception. And as those should be rare
+(hence the term exception) i don't think that's the intent of the third point.
+
+So as some already stated this, as it seems to be allowed to ship bugfix-only
+releases as updates, where does the policy state that, and in the case
+where it doesn't, shouldn't we extent the policy if that is considered good
+practice?
+
+
+PS: Maybe next time you could improve on your wording, the policy may
+currently be incorrect, not reflecting good packaging practices, but as it's
+only a policy written by humans, it's not dumb. Just a hint. ;)
+
+ + + + + + + + + + + +
+

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