1 |
Hi, |
2 |
|
3 |
I was searching a bit through bugzilla for some ebuilds for programs, |
4 |
that are not yet in portage and I found, there are a lot of programs |
5 |
hanging in buzilla, because no one did take them for maintenance. |
6 |
|
7 |
Now some of them are quite old (no comments/activity for 2 years) and I |
8 |
tried some of them and found out, that sometimes they don't even |
9 |
compile anymore. |
10 |
Now I was wondering, if there is a standard procedure for things |
11 |
like this; I searched the mailing list for sth. like this, but didn't find |
12 |
anything there. |
13 |
So my question is, is there some kind of standard procedure for old |
14 |
ebuilds that lay around bugzilla, and if not, maybe there should be one? |
15 |
|
16 |
I was thinking about something like this: |
17 |
- Categorize ebuild requests, so one category should contain the programs, |
18 |
that aren't developed anymore, one category those, that are still developed, |
19 |
but won't work with a current toolchain/system, and those programs, that |
20 |
will still work with current systems. |
21 |
- Add them to some kind of tracker, so some users that are up to it can try |
22 |
to fix them, and report that, and if it not fixable, resolve the bugs as |
23 |
wontfix. |
24 |
- Maybe make use of the vote system, so bugs with ebuilds, that are |
25 |
quite old |
26 |
and don't have votes, will be closed after something like 2 years with no |
27 |
activity (but that would include to tell users, that they have to vote). |
28 |
|
29 |
Maybe there are better ways handling this. |
30 |
But I think, there is at least a problem with the number of "dead" ebuilds |
31 |
in bugzilla, because I think, that at least those, that will still work |
32 |
should be |
33 |
picked out. |
34 |
|
35 |
Bernd |
36 |
-- |
37 |
gentoo-dev@g.o mailing list |