| 1 |
On Mon, Oct 29, 2012 at 2:30 PM, Peter Stuge <peter@×××××.se> wrote: |
| 2 |
> I expect that anyone and everyone who contribute to any open source |
| 3 |
> project will do their damndest to contribute only "perfect" work. |
| 4 |
|
| 5 |
Setting aside issues of tone, I want to touch on the more direct issue |
| 6 |
of "quality" and "perfection." |
| 7 |
|
| 8 |
I do think that most developers aim for high quality, but quality |
| 9 |
means something different to everybody. |
| 10 |
|
| 11 |
Quality could be: |
| 12 |
1. Having a newer package in the tree, perhaps with resolved upstream issues. |
| 13 |
2. Having more integration testing. |
| 14 |
3. Having good documentation. |
| 15 |
4. Having good communications to the end users about impending changes. |
| 16 |
5. Being better integrated with other projects (such as chromium in this case). |
| 17 |
6. Maintainability of the actual ebuild code. |
| 18 |
7. Compliance with formal policies. |
| 19 |
|
| 20 |
All of those have a connotation of quality, and they are at odds with |
| 21 |
each other. The more time you spend on any of them the less time you |
| 22 |
have to spend on others. Complying with any of #2-7 takes time, and |
| 23 |
thus conflicts with #1. |
| 24 |
|
| 25 |
I think we should have a pool of developer proxies who are interested |
| 26 |
in supporting proxy maintenance. I don't think we get anywhere by |
| 27 |
punishing them when the inevitable mistake occurs. However, we also |
| 28 |
don't get anywhere by turning a blind eye to real issues that |
| 29 |
repeatedly come up. It sounds like there are some of those with ICU. |
| 30 |
|
| 31 |
I don't think we need drastic action. Maybe we just need a proxy dev |
| 32 |
who can be a little more closely associated with the package so |
| 33 |
they're aware of the issues that routinely come up and can help |
| 34 |
prevent them. Maybe Arfrever can work a little more closely with some |
| 35 |
of the other teams. |
| 36 |
|
| 37 |
I do think we need reasonable quality policies so that we're all on |
| 38 |
the same page. Testing packages should at least be confirmed as |
| 39 |
generally working and free of obvious problems. Stable packages |
| 40 |
should have been in testing for 30 days. Packages with highly |
| 41 |
impactful changes should have news items before being unmasked or |
| 42 |
stabilized. And so on. They don't have to be out-of-hand, and we |
| 43 |
don't have to shoot our wounded either. |
| 44 |
|
| 45 |
Rich |
Archives