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. |