port maintainer duties
noackjr at alumni.rice.edu
Tue Dec 16 19:56:48 PST 2003
On 12/16/2003 6:52 PM, Mark Linimon wrote:
>>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.
Thanks for the well-reasoned response. I knew some of this -- I was
just asking to ensure I wasn't missing some obvious step that could make
it all better.
Doing linear scans over an associative array is like trying to club
someone to death with a loaded Uzi.
- Larry Wall
More information about the freebsd-ports