1 |
On 2010.04.24 18:40, Petteri Räty wrote: |
2 |
> 17:34 < Betelgeuse> robbat2|na: how easy to it to prevent commits to |
3 |
> CVS |
4 |
> if the commit message doesn't match a certain pattern? |
5 |
> 17:36 <@robbat2|na> go and checkout the CVSROOT and there should be |
6 |
> an |
7 |
> example there |
8 |
> 17:37 < Betelgeuse> robbat2|na: Ok so doable then. Thanks. |
9 |
> |
10 |
> What do you think about not allowing commits to eclasses without |
11 |
> mentioning an another developer who has reviewed and approved the |
12 |
> diff |
13 |
> in the commit message? There's enough people on gentoo-dev for urgent |
14 |
> stuff too. |
15 |
> |
16 |
> Regards, |
17 |
> Petteri |
18 |
> |
19 |
> |
20 |
In industry, the practice is called peer review. Its generally thought |
21 |
to be a GoodThing as its part of the process of trapping errors as |
22 |
early as possible in the process, where they have lowest cost. |
23 |
|
24 |
We cannot easily attribute cost in terms of money, so think about it in |
25 |
developer and user hours wasted as errors 'escape'. |
26 |
|
27 |
Industry also recognises the need that any process needs to be tailored |
28 |
to the circumstance so the peer review process is not enforced. Project |
29 |
groups are permitted to assess the risk of screwing up against the cost |
30 |
of a fix. (That's overly simplistic). |
31 |
|
32 |
In short, following industry best practice, the peer review process |
33 |
should be strongly encouraged but we should stop short of using tools |
34 |
to enforce it. |
35 |
|
36 |
-- |
37 |
Regards, |
38 |
|
39 |
Roy Bamford |
40 |
(Neddyseagoon) a member of |
41 |
gentoo-ops |
42 |
forum-mods |
43 |
trustees |