| 1 |
I agree that packages shouldn't be removed or moved because they have no |
| 2 |
active developer maintaining them - that is going to take the value of |
| 3 |
portage down quite a lot. Outdated packages do too, but not in quite the |
| 4 |
same way. |
| 5 |
|
| 6 |
I like the idea of a list or mailing list of developers willing to help |
| 7 |
update unmaintained packages, and if community submitted ebuilds were |
| 8 |
encouraged a bit more, the job would be pretty simple. Most of the times |
| 9 |
i've done version bumps myself have just involved changing the name and |
| 10 |
fixing up patches. I definitely like the idea of encouraging proxy |
| 11 |
maintainers, as I said before. Becoming a full developer is (from what i've |
| 12 |
seen externally) quite difficult and requires a lot of dedicated time, but |
| 13 |
the user community is much larger - and 100 people doing one ebuild each is |
| 14 |
going to work better than one person doing 100 ebuilds. |
| 15 |
|
| 16 |
As another interesting idea for encouraging proxy maintainence, once an |
| 17 |
easier/more developed system exists for that (such as the mailing list |
| 18 |
mentioned before), perhaps a notice should be added to unmaintained ebuilds |
| 19 |
mentioning that it has no active maintainer, to warn users that a newer |
| 20 |
version may be available (in which case they can file a bug, etc) and |
| 21 |
encourage those with the time and skills to take up some of the work on |
| 22 |
those ebuilds. I would be very willing to work on some ebuilds if it didn't |
| 23 |
involve chasing a trail of vaguely relevant developers down until one pays |
| 24 |
attention. :P |
| 25 |
|
| 26 |
I would think that masking them due to a lack of maintainence should be used |
| 27 |
only as a last resort - if a package is blocking other updates or is |
| 28 |
extremely out of date (unsupported by upstream / everything else). But in |
| 29 |
those situations, deleting might be a better idea anyway, because what |
| 30 |
purpose does it really serve? |
| 31 |
|
| 32 |
- John Brooks |
| 33 |
|
| 34 |
On Mon, Aug 18, 2008 at 5:35 PM, Joe Peterson <lavajoe@g.o> wrote: |
| 35 |
|
| 36 |
> Jeremy Olexa wrote: |
| 37 |
> > Also, devs willing to maintain |
| 38 |
> > packages but then later retiring and leaving the packages in limbo. |
| 39 |
> > Maybe there should be some policy such as, when devs retire if no one |
| 40 |
> > else steps up to maintain the package, then it automatically gets |
| 41 |
> > moved to sunrise overlay and only maintained packages stay in the |
| 42 |
> > portage tree. |
| 43 |
> |
| 44 |
> My opinion is that packages should not be removed from the tree just |
| 45 |
> because |
| 46 |
> there is no assigned maintainer. Even moving a package to sunrise |
| 47 |
> effectively |
| 48 |
> makes it invisible to many users, and a great strength of Gentoo is that it |
| 49 |
> has such a variety of packages in the tree. |
| 50 |
> |
| 51 |
> I do see that there are potential problems with unmaintained packages, so |
| 52 |
> it |
| 53 |
> is a good goal to try to solve that. Perhaps developers who have the time |
| 54 |
> and |
| 55 |
> choose to make themselves available to do simple version bumps on |
| 56 |
> unmaintained |
| 57 |
> packages could put themselves on a mailing list to receive such bug |
| 58 |
> reports. |
| 59 |
> Encouraging users to be proxy maintainers is a great idea too (as others |
| 60 |
> have |
| 61 |
> suggested). As a last resort, otherwise working packages could be masked |
| 62 |
> as |
| 63 |
> "unmaintained", which is probably better than total removal (after all, |
| 64 |
> they |
| 65 |
> could still be useful to some users. |
| 66 |
> |
| 67 |
> -Joe |
| 68 |
> |
| 69 |
> |
Archives