1 |
On wto, 2017-08-08 at 13:46 -0700, Daniel Campbell wrote: |
2 |
> On 08/08/2017 09:49 AM, William Hubbs wrote: |
3 |
> > |
4 |
> > All, |
5 |
> > |
6 |
> > here is the council agenda for 8/13: |
7 |
> > |
8 |
> > 1. roll call |
9 |
> > |
10 |
> > 2. decide whether the kernel team can stabilize minor releases on their |
11 |
> > own once the arch teams have stabilized a major release [1]. |
12 |
> > |
13 |
> > 3. open bugs with council involvement |
14 |
> > |
15 |
> > 4. open floor |
16 |
> > |
17 |
> > Thanks, |
18 |
> > |
19 |
> > William |
20 |
> > |
21 |
> > [1] https://wiki.gentoo.org/wiki/Project:Kernel#Kernel_stabilization |
22 |
> > |
23 |
> |
24 |
> I would like the council to consider clarifying the text found in the |
25 |
> devmanual regarding revision bumps. [1] At present, the text indicates |
26 |
> that in general we don't want to touch ebuilds that have hit stable. |
27 |
> However, there are exceptions that are not explicitly laid out, that |
28 |
> some of us expect other developers to "just understand", despite a |
29 |
> complete lack of documentation. Developers can't be expected to follow |
30 |
> policy that isn't clear. "Use your best judgment" isn't good enough when |
31 |
> a developer gets berated for using it. |
32 |
> |
33 |
> Thus, I would ask the council to answer this one question: When is it |
34 |
> acceptable to correct an ebuild that has already gotten stable keywords? |
35 |
> If more intrepid developers would like to make a flow chart or other |
36 |
> guided aid, that'd be even better. |
37 |
> |
38 |
|
39 |
This is a matter for QA, and there are patches for devmanual with a more |
40 |
detailed policy in review already |
41 |
|
42 |
Besides, flow charts won't replace common sense. They will only serve as |
43 |
an excuse to abuse the policy against the spirit it was written on. |
44 |
|
45 |
-- |
46 |
Best regards, |
47 |
Michał Górny |