port maintainer duties (was: www/squid maintainer: 3 months and still timing out...)

Mark Linimon linimon at lonesome.com
Tue Dec 16 16:52:12 PST 2003


> There has been no response.  I understand that we all get busy and
> can't handle things immediately -- I'm not trying to be demanding.

(I'm just thinking out loud here, I don't have any hard-and-fixed
answers for you).

I don't know if it's possible on a volunteer project to achieve any
working consensus on how much time is "too long".  I think you could
even argue that picking an arbitrary time period might be too much
of a "one size fits all" solution (e.g. it might not matter to as
many people if games/blackjack gets stale :-) )

As far as I can tell, the only "fixed" limit is the stated ability
of core to rescind commit bits that haven't been used for a year.
While this is probably a good policy for commit bits, in terms of
ports maintainership, given how quickly applications change out in
the wider community, a year is an eternity.

On the other hand, from my own research, we have the following
situations for our maintained ports:

 a) over 100 ports PRs that are at least a year old;
 b) over 100 ports that are marked broken on -current (as evaluated
    on i386), some of which have been failing on bento for quite
    some time.  (Nearly 50 of those are also marked broken on -stable).

This is clearly undesirable, but I would rather not see some kind
of fixed policy enacted to fix it -- common sense ought to suffice.

Perhaps ports maintainers should consider these suggestions for
when it's time to release their maintainership(s):

 a) when PRs for a port are piling up faster than you can
    keep up with them;
 b) when you're no longer actively using the port any more;
 c) when it's been more than a month or two since you've been
    able to look at outstading PR or build issues;
 d) when you feel like you're obligated to do it because otherwise
    it might not be maintained;
 e) when you're having your commit bit "stored for safekeeping"
    when taking a leave of absence from FreeBSD;
 f) when it's just no damned fun anymore :-)

Now, there's no question that we need more port maintainers to
help share the maintainence burden, but if we consider the PR
submitters to be a "pool of talent waiting to be used", rather
than just seeing the individual PRs as problems to be solved, 
perhaps we can get those problems to cancel each other out ...

A final observation: even if we were to try to achieve some kind
of consensus in this thread, so many people are away from FreeBSD
during the holidays that are observed in the U.S. (among many other
places), there are just too many people who would't see the discussion.

mcl



More information about the freebsd-ports mailing list