Gentoo Archives: gentoo-dev

From: Alon Bar-Lev <alonbl@g.o>
To: gentoo-dev@l.g.o
Cc: ryao@g.o
Subject: Re: [gentoo-dev] Changing policy about -Werror
Date: Fri, 14 Sep 2018 18:00:58
Message-Id: CAOazyz1QLk4nh5TGeLV6eBgOzPAm3YejJSpWtdhYtP=K0+7ZNA@mail.gmail.com
In Reply to: Re: [gentoo-dev] Changing policy about -Werror by "Michał Górny"
1 On Fri, Sep 14, 2018 at 8:53 PM Michał Górny <mgorny@g.o> wrote:
2 >
3 > On Fri, 2018-09-14 at 20:48 +0300, Alon Bar-Lev wrote:
4 > > On Fri, Sep 14, 2018 at 8:33 PM Michał Górny <mgorny@g.o> wrote:
5 > >
6 > > > > Let's do this the other way around and be react based on facts and not
7 > > > > speculations.
8 > > > > Let's change the policy for a year for selected packages as I
9 > > > > outlined, monitor bugs and after a year see response times, affected
10 > > > > users and if downstream patches are accumulated. Then we can decide if
11 > > > > we need to patch upstream packages.
12 > > > > If we need to patch upstream package anyway, not follow upstream
13 > > > > policy and not accepting input for various of permutations and
14 > > > > architecture from all users, this discussion is nearly void.
15 > > > >
16 > > >
17 > > > ...and for how long did you exactly ignore the standing policy that
18 > > > suddenly we need a new testing period? How about we do the opposite
19 > > > and you prove a *single* bug found downstream using this method so far?
20 > > >
21 > > > Because so far this discussion is not much different than "let's make
22 > > > the ebuild fail for some values of ${RANDOM}, and add extra values when
23 > > > users complain". Though the variant with random has probably a greater
24 > > > chance of failing when *actual* security issues happen.
25 > >
26 > > OK, back to personal discussion, unfortunately you question this in
27 > > this principal thread.
28 > >
29 > > Personal response:
30 > > In all my years in Gentoo, I've never thought the maintainer lose his
31 > > judgement of how to maintain a package as long as the he/she provide a
32 > > great service to users.
33 > > I've never thought or read this (and other) paragraph as a strict
34 > > white and black nor the holy bible , but a suggestion of how to
35 > > provide a great service to user with the least overhead to maintainer,
36 > > the best practice, the common case.
37 > > I believe there was no complains from users about these packages, on
38 > > the opposite users report issues and are happy when resolved after
39 > > proper investigation.
40 > > I guess something had changed recently in Gentoo in which QA try to
41 > > take the maintainer judgement try to enforce a black and white
42 > > perspective and without looking at bug history and other sources.
43 > > I believe this is a regression and not a progression, I was very
44 > > disappointed to see this new side of Gentoo in which common sense for
45 > > a specific case cannot be discussed individually, nor that a fixed bug
46 > > is hijacked to discuss a principal issue without opening a separate
47 > > formal QA request to discuss properly, address some of the argument
48 > > raised by fellow developers and the reaction of requesting to ban
49 > > developers without any mature discussion. As you can see this in this
50 > > thread is not black and white.
51 > >
52 >
53 > I should point out *once again* that:
54 >
55 > a. nobody requested banning developers,
56 >
57 > b. Bugzilla access suspension was requested because of your hostility
58 > in closing the bug and not the technical issue in question --
59 > or in other words, to prevent you from closing the bug again.
60 >
61 > However, if you continue spreading harmful misinformation about my
62 > intentions in attempt to prove your point in technical matter, then
63 > I believe we have much more serious problem to address here.
64
65 Unfortunately you still continue the personal discussion in principal
66 thread. I will not cooperate with that as it missing the point. Throw
67 the entire process you are trying to enforce your view and your
68 interpretation of the process as if enforcing that may have benefit.
69 Your request to ban via bugzilla access was rejected with explanation.
70 The bug that was closed was fixed, if you wanted to have a principal
71 discussion you should had opened a different principal one and discuss
72 the issue in opened mind, reaching to a conclusion that we need to
73 escalate the discussion together. I beg you as I beg you in bugzilla,
74 please do not turn this thread to personal one, it is not productive.