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

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

+ Juan Luis Baptiste + juancho at mageia.org +
+ Wed Jan 11 22:09:56 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 3:53 PM, Christian Lohmaier
+<lohmaier+mageia at googlemail.com> wrote:
+> adding patches to the packages and releasing them instead of waiting
+> for a new upstream release is different from having the policy to
+> stick with whatever release was used when releasing the distro and
+> then only apply fixes via patches.
+>
+
+Some times you can't wait for an upstream release, think for example
+of a security update. Also not all projects do bugfix only releases,
+but include new features as well so per our policy, we can't update to
+that version and that's when we have to cherry pick updates to apply
+to package in the stable version of mga. The problem seems to be that
+that isn't clear on the policy.
+
+> I'm not saying that you must not use patches to fix bugs. There are
+> cases where a bug is homegrown/specific to the distro and thus not
+> suitable for fixing upstream, there are cases where development cylce
+> is too slow/it is not sensible to wait for upstream.
+>
+
+Exactly, plus the other case I just said.
+
+> It is not a question whether it is possible. It is a question whether
+> it makes sense in the first place.
+> And no doubt it creates a lot more work for package maintainers.
+> Both for initially hunting for the commit that fixes the bug, and
+> later when patches conflict, and later when a package is updated to a
+> new release.
+
+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.
+
+>
+>> Because as I said earlier, we backport the "commit" that fixes that
+>> single issue,
+>
+> Every change, also those that introduce a regression is a "commit".
+> So implicitly you're saying that you will only fix the "easy" bugs,
+> but anything that involves more than touching 10lines of code will not
+> be chosen, since it might introduce regressions.
+>
+
+No, I'm saying that we will look for the commit that fixes the issue
+in question and not anything else, it doesn't matter if the fix is
+one, 10, 50 lines and/or touches 1, 2 or 10 files.
+
+And again, if there's a bugfix *only* release available when we are
+working on a bug, or we know that there will be one soon, then we can
+update to that version. In the other cases we have to go the long
+route and patch the packges with individual fixes.
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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