View of non maintained packages

[Ryan Schmidt]

On Jan 13, 2008, at 17:37, Rolf Würdemann wrote:

> Am 14.01.2008 um 00:21 schrieb Rainer Müller:
>
>> Rolf Würdemann wrote:
>>
>>> But it seems that we need more committers before asking on
>>> the website - if we get mainatiners for a quarter of the ports
>>> there will be much work (if my case with the one to three weeks
>>> was not a single case) ;)
>>
>> Maybe we should have someone who is responsible for committing  
>> updates
>> for particular port categories. I think the problem at the moment is
>> that a port update is committed if someone looked into Trac to see  
>> any
>> pending updates... So this is rather random when a port update is  
>> committed.
>
> Maybe an commit-group would be an idea ;) (something like the  
> support-group
> at our office ;)

Do you mean a group of people who do nothing but commit things that  
others submit? If we have people who are interested in performing  
that function, then sure.

But we don't want everything that's submitted into Trac just blindly  
committed into Subversion. We need the committer to be aware of the  
changes that are being made, to police the changes in a way. Don't  
commit patches that do multiple things; break it into separate  
patches or ask the contributor to do so. Don't commit patches that  
make whitespace changes to the entire portfile in addition to  
functional changes. Don't commit patches that obviously revert a  
previous revision without the contributor explaining why. Don't  
commit patches that use inadvisable practices without first  
discussing these with the contributor. And so forth. In order to know  
these things, it helps if such a committer is also an accomplished  
port maintainer/author.

I think what we need are committers who are interested in each  
category of software. I occasionally look through the unassigned  
tickets and either try to handle them (new ports, or patches for  
unmaintained ports) or assign them to their ports' maintainers. But  
some tickets I don't deal with, like most tickets for Python modules  
or most Gnome tickets, because I don't use or sufficiently understand  
Python and Gnome. We need committers who are interested in and  
proficient in Python and Gnome (and maybe some other categories) who  
will deal with those tickets.