| 1 |
On 01/17/2010 03:20 PM, Thilo Bangert wrote: |
| 2 |
> Ben de Groot<yngwin@g.o> said: |
| 3 |
>> I think we have a bigger problem with packages that have a maintainer, |
| 4 |
>> at least nominally, but said maintainer does not actually maintain the |
| 5 |
>> package anymore. |
| 6 |
> |
| 7 |
> full ack. i was thinking that maybe we need an 'easy-fix' team, which can |
| 8 |
> do all the easy fixes, which have been laying around for way too long and |
| 9 |
> which aparently are "easy to fix" (ie. only waiting for somebody to |
| 10 |
> commit)... |
| 11 |
|
| 12 |
I think this is a good idea. Alternatively, perhaps if we just make a |
| 13 |
policy that it is acceptable for a dev to touch a package and leave it |
| 14 |
with QA problems, as long as it ends up with no more QA problems than it |
| 15 |
started with. Of course, devs are encouraged to fix QA problems |
| 16 |
whenever they can. |
| 17 |
|
| 18 |
This way devs will be more willing to make small fixes that generally |
| 19 |
improve the distro without being worried about being chewed out because |
| 20 |
they didn't go through the package with a fine-tooth comb looking for |
| 21 |
issues. |
| 22 |
|
| 23 |
That will at least get poorly-maintained packages trending in the right |
| 24 |
direction. Along with that I think we need to address the problem of |
| 25 |
packages that list a maintainer but which aren't maintained. |
| 26 |
|
| 27 |
Perhaps a solution would be to have some way to periodically ping |
| 28 |
maintainers to confirm they're still looking at a package. That could |
| 29 |
take many forms - a simple one would be to ask the maintainer to touch |
| 30 |
the metadata.xml file or something like that (obviously the manipulation |
| 31 |
has to be something that is noticed by CVS). On the other hand we don't |
| 32 |
want needless churn. Then an automated process can ping maintainers if |
| 33 |
they haven't done this, and after a delay the package would be set to |
| 34 |
maintainer-wanted. |
| 35 |
|
| 36 |
Actively-maintained projects would be allowed to use automation to keep |
| 37 |
packages they track marked fresh. However, the project does then become |
| 38 |
accountable for actually maintaining them. |
| 39 |
|
| 40 |
This would go along with an (unwritten but already in place) policy that |
| 41 |
anybody listed as a maintainer has to actually maintain the package, |
| 42 |
with consequences for not doing so to some defined standard. This |
| 43 |
standard would not be zero-bugs, but certainly anything real flagged by |
| 44 |
repoman or a violation of a written QA policy would be expected to be |
| 45 |
cleaned up in a timely manner. |
| 46 |
|
| 47 |
The goal is to make the maintainer field meaningful. |
| 48 |
|
| 49 |
Then we could figure out a policy for maintainer-wanted builds. My |
| 50 |
feeling is that as long as they build, don't have security issues, and |
| 51 |
don't have QA issues that genuinely get in the way of some Gentoo |
| 52 |
initiative, they can stay around. Once any of the above ceases to be |
| 53 |
the case they're announced on-list and then treecleaned. |
| 54 |
|
| 55 |
The bottom line though is that we can write all the rules we want - |
| 56 |
ultimately Gentoo needs warm bodies to fix bugs. No amount of process |
| 57 |
will get around that. What process can do for us, however, is to |
| 58 |
increase visibility of issues so that QA doesn't waste time hunting down |
| 59 |
inactive devs and so that people running servers or whatever can tell if |
| 60 |
a package is actively maintained. |
Archives