1 |
On Fri, Sep 14, 2018 at 8:33 PM Michał Górny <mgorny@g.o> wrote: |
2 |
|
3 |
> > Let's do this the other way around and be react based on facts and not |
4 |
> > speculations. |
5 |
> > Let's change the policy for a year for selected packages as I |
6 |
> > outlined, monitor bugs and after a year see response times, affected |
7 |
> > users and if downstream patches are accumulated. Then we can decide if |
8 |
> > we need to patch upstream packages. |
9 |
> > If we need to patch upstream package anyway, not follow upstream |
10 |
> > policy and not accepting input for various of permutations and |
11 |
> > architecture from all users, this discussion is nearly void. |
12 |
> > |
13 |
> |
14 |
> ...and for how long did you exactly ignore the standing policy that |
15 |
> suddenly we need a new testing period? How about we do the opposite |
16 |
> and you prove a *single* bug found downstream using this method so far? |
17 |
> |
18 |
> Because so far this discussion is not much different than "let's make |
19 |
> the ebuild fail for some values of ${RANDOM}, and add extra values when |
20 |
> users complain". Though the variant with random has probably a greater |
21 |
> chance of failing when *actual* security issues happen. |
22 |
|
23 |
OK, back to personal discussion, unfortunately you question this in |
24 |
this principal thread. |
25 |
|
26 |
Personal response: |
27 |
In all my years in Gentoo, I've never thought the maintainer lose his |
28 |
judgement of how to maintain a package as long as the he/she provide a |
29 |
great service to users. |
30 |
I've never thought or read this (and other) paragraph as a strict |
31 |
white and black nor the holy bible , but a suggestion of how to |
32 |
provide a great service to user with the least overhead to maintainer, |
33 |
the best practice, the common case. |
34 |
I believe there was no complains from users about these packages, on |
35 |
the opposite users report issues and are happy when resolved after |
36 |
proper investigation. |
37 |
I guess something had changed recently in Gentoo in which QA try to |
38 |
take the maintainer judgement try to enforce a black and white |
39 |
perspective and without looking at bug history and other sources. |
40 |
I believe this is a regression and not a progression, I was very |
41 |
disappointed to see this new side of Gentoo in which common sense for |
42 |
a specific case cannot be discussed individually, nor that a fixed bug |
43 |
is hijacked to discuss a principal issue without opening a separate |
44 |
formal QA request to discuss properly, address some of the argument |
45 |
raised by fellow developers and the reaction of requesting to ban |
46 |
developers without any mature discussion. As you can see this in this |
47 |
thread is not black and white. |