1 |
Hello, |
2 |
|
3 |
I like the idea of enforcing quality rules in the tree, but I have a few |
4 |
reservations regarding the current plan. |
5 |
|
6 |
On Sun, Jul 29, 2018 at 04:47:47PM +0900, Alice Ferrazzi wrote: |
7 |
> Sent from my phone. Please excuse my brevity. |
8 |
> |
9 |
> On Sun, 29 Jul 2018, 16:39 Fabian Groffen, <grobian@g.o> wrote: |
10 |
> |
11 |
> > Completely agreeing with Sergei, with some additional suggestions: |
12 |
> > |
13 |
> > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: |
14 |
> > > On Sun, 29 Jul 2018 00:40:18 +0300 |
15 |
> > > Mikle Kolyada <zlogene@g.o> wrote: |
16 |
> > > |
17 |
> > > > Hello, |
18 |
> > > > |
19 |
> > > > The Gentoo QA team would like to introduce the following policy that |
20 |
> > > > would be applied to individuals breaking the state and quality of the |
21 |
> > > > main gentoo.git tree |
22 |
|
23 |
If you introduce penalties for breaking prefix as well, I'm afraid many |
24 |
people will be unnecessarily penalized. I think that such penalties are |
25 |
counter productive in most cases. If someone is really being careless it |
26 |
might make sense to get some warning and lose commit access temporarily. |
27 |
If someone made a simple mistake that can be easily fixed, like version |
28 |
bumping a package that starts to fail in some corner case, then |
29 |
punishment doesn't make much sense. |
30 |
|
31 |
I'd rather prefer to see improvements to our automated checks as the |
32 |
mean to improve the quality of the tree, and penalties for people that |
33 |
do not use repoman. Rather than a temporary ban, it would also make more |
34 |
sense to just require someone to go through the ebuild quiz again as |
35 |
penalty for breaking the tree many times. |
36 |
|
37 |
> > > > ( as we do not have this strictly documented yet): |
38 |
> > > > |
39 |
> > > > <policy> |
40 |
> > > > |
41 |
> > > > If recommended |
42 |
> > > |
43 |
> > > It's not called "recommended" but "enforced". |
44 |
> > |
45 |
> > I agree. If you put penalties on these, they become hard rules. I |
46 |
> > think that change should be discussed by the council perhaps? |
47 |
> > |
48 |
> > > > Gentoo workflow policies are not followed by an |
49 |
> > > > individual developer |
50 |
> > > > (e.g make major changes to the widely used eclasses without prior |
51 |
> > > > discussion on the mailing list or |
52 |
> > > > commit changes that lead to multiple CI checks failure) |
53 |
> > > |
54 |
> > > Here should go exhaustive list of links to the policies to be enforced. |
55 |
> > |
56 |
> > At least. And they should be clear and concise. No "common sense" or |
57 |
> > anything involved for exceptions and the like. In addition, new checks |
58 |
> > should be introduced to the community and possibly approved by council |
59 |
> > as to whether being enforced or not. |
60 |
> > |
61 |
> > Fabian |
62 |
> > |
63 |
> > > |
64 |
> > > > the standard QA |
65 |
> > > > procedure is: |
66 |
> > > > |
67 |
> > > > 1.) Two warnings granted by QA team, after two independent breakages |
68 |
> > > > 2.) Revoking the commit access for 14 days |
69 |
> > > > |
70 |
> > > > These violations will be evaluated individually by all QA team members. |
71 |
> > > > Warnings can be revoked, if during 6 months period a developer makes at |
72 |
> > > > least 20 non trivial changes not producing more breakages. |
73 |
> > > > |
74 |
> > > > </policy> |
75 |
> > > |
76 |
> > > -- |
77 |
> > > |
78 |
> > |
79 |
> if you want to enforce rules, would be productive to also have extensive |
80 |
> documentation on how to avoid to make such problems. |
81 |
> Better would be to invest more time in something like the breckage checker |
82 |
> script, similar at what mgorny is doing, than adding more ways to block |
83 |
> developers contributions. |
84 |
|
85 |
I agree with Alice here. We already have the devmanual and repoman, as |
86 |
well as the CI system, which are all very good. Extending them is the |
87 |
best way to keep Gentoo in good shape. Also, if we have enough |
88 |
resources, we can try to reject broken pushes, rather than punishing |
89 |
devs after broken changes reach the main tree. |
90 |
|
91 |
Cheers, |
92 |
-Guilherme |