1 |
On 01/30/2014 03:10 PM, William Hubbs wrote: |
2 |
> On Thu, Jan 30, 2014 at 12:47:01AM -0500, Chris Reffett wrote: |
3 |
>> -----BEGIN PGP SIGNED MESSAGE----- |
4 |
>> Hash: SHA1 |
5 |
>> |
6 |
>> Hello all, |
7 |
>> The new QA team has completed its first meeting, and so I would like |
8 |
>> to announce policy changes agreed upon during the meeting which are |
9 |
>> relevant to the developer community. In the future, when a meeting |
10 |
>> results in changed or amended policy, we will notify the community via |
11 |
>> - -dev and -dev-announce, so there will probably be a summary email like |
12 |
>> this coming out about once a month. Changes to policy from this meeting: |
13 |
>> |
14 |
>> - -USE-controlled optional RDEPENDs policy clarified to say that those |
15 |
>> dependencies are not allowed, but QA will grant exceptions for certain |
16 |
>> circumstances (such as a package not working unless one of a set of |
17 |
>> optional deps is installed) |
18 |
>> |
19 |
>> - -The QA team policymaking workflow will look like the following: |
20 |
>> * User/dev/team member brings us an issue |
21 |
>> * Team investigates |
22 |
>> * Team discusses at the next meeting |
23 |
>> ** If the person is violating policy, we inform them of that and |
24 |
>> request that they stop violating policy |
25 |
>> ** If the existing policy is unclear, we update it |
26 |
>> ** If there is no existing policy, make one |
27 |
>> If we think a developer's actions are causing problems, we may ask |
28 |
>> them to stop/undo pending discussion by the QA team at the next meeting. |
29 |
>> |
30 |
>> - -Rules for the QA team editing peoples' packages: |
31 |
>> *For trivial fixes, such as repoman errors, we fix the issue and send |
32 |
>> the developer a friendly reminder |
33 |
>> *For large but non-critical fixes, we open a bug, wait 2 weeks, and if |
34 |
>> it is not fixed within that time frame we make the change. |
35 |
>> *For critical fixes, such as a problem that breaks the tree or a |
36 |
>> package, we fix the issue and send the developer a notice about our change |
37 |
>> |
38 |
>> - -The QA team will communicate changes to policy via emails to |
39 |
>> gentoo-dev and gentoo-dev-announce and by updating the QA policy page |
40 |
>> on the Gentoo Wiki. |
41 |
>> |
42 |
>> For anyone interested, the summary of the meeting can be found at |
43 |
>> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries |
44 |
>> and the current set of QA policies can be found at |
45 |
>> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies. If |
46 |
>> you have any questions or concerns about these policies, feel free to |
47 |
>> discuss them with us in #gentoo-qa or by emailing qa@g.o. |
48 |
> |
49 |
> I have one. |
50 |
> |
51 |
> The way I read that email, we are saying that our only policies are on |
52 |
> the wiki. |
53 |
> |
54 |
> Is that right, or is the DevManual stil relevant? |
55 |
> |
56 |
> If it is, I would suggest that on the wiki we make it clear that our |
57 |
> technical policies are all in the devmanual. Along that line, I would |
58 |
> suggest moving the stabilization policy to the devmanual. I'll look for |
59 |
> a place for a patch. |
60 |
> |
61 |
> William |
62 |
> |
63 |
|
64 |
That's my mistake, the devmanual is still relevant. My idea is to use |
65 |
the wiki page for smaller or more specific items which probably don't go |
66 |
in the devmanual (for example, policy which is about specific packages |
67 |
or USE flags, or policies which just affect the QA team). Stabilization |
68 |
should go to the devmanual, then. |
69 |
|
70 |
Chris Reffett |