Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Dec 2003 21:56:26 -0600
From:      Jon Noack <noackjr@alumni.rice.edu>
To:        Mark Linimon <linimon@lonesome.com>
Cc:        tmseck@netcologne.de
Subject:   Re: port maintainer duties
Message-ID:  <3FDFD3EA.4050400@alumni.rice.edu>
In-Reply-To: <Pine.LNX.4.44.0312161751270.31519-100000@pancho>
References:  <Pine.LNX.4.44.0312161751270.31519-100000@pancho>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FDFD3EA.4050400>