port maintainer duties

Jon Noack 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.
> 
> mcl

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.

Jon Noack

-- 
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 mailing list