1 |
On 04/03/10 18:03, Alec Warner wrote: |
2 |
> - date of last commit: Gentoo is fast moving and packages that |
3 |
> haven't had commits since 200{4,5,6} are probably old, unmaintained |
4 |
> and may not even compile or run. |
5 |
> - date of last listed maintainer commit versus last commit: |
6 |
> Basically if the maintainer hasn't touched the ebuild in a while but |
7 |
> someone else (herd members?) have, the metadata.xml is probably out of |
8 |
> date. |
9 |
|
10 |
Have the result of that analysis collected somewhere? |
11 |
|
12 |
|
13 |
> The above are all pretty easy to do with the data in the tree. Some |
14 |
> other useful ideas might be: |
15 |
> - compare open bugs for the package, when was the last bug for a |
16 |
> package closed (bugs data kinda sucks for this) |
17 |
|
18 |
Right, but we can get that working. I have a regex to get package |
19 |
names from bug titles around that works well. All we need to do is fix |
20 |
all bug titles ever to contain package names: Could take a whole bugday |
21 |
or two :-) |
22 |
|
23 |
|
24 |
> - for a given package in a herd, check the version in the tree |
25 |
> against freshmeat or similar to see how far behind it is (I think |
26 |
> someone wrote something for this already, exherbo?) |
27 |
|
28 |
That's a larger project. GSOC ideas should contain such thing. |
29 |
|
30 |
|
31 |
> - check imlate to see if keywording is behind (is the maintainer |
32 |
> filing stablereqs?) |
33 |
|
34 |
While you mention that: it's the first time I hear a maintainer should |
35 |
do that. if so can you raise awareness of it and explain the what and |
36 |
why in another thread on gentoo-dev? |
37 |
|
38 |
|
39 |
|
40 |
Sebastian |