svn commit: r402813 - head/misc/astrolog

[John Marino]

On 12/2/2015 10:23 AM, Andrey Chernov wrote:
> On 02.12.2015 12:02, John Marino wrote:
>> On 12/2/2015 9:54 AM, Andrey Chernov wrote:
>>>
>>> 3) Contact the person who does most commits to this port.
>>
>> I think this is a dream.  I don't expect people to sort through the
>> history and try to figure out a commit pattern, plus the presence of a
>> prior commit doesn't imply a willingness for a future commit.
> 
> In that case we need some UNLOCKED_FOR_COMMITS = Yes (or some other
> name) field. F.e. due to my personal circumstances I can't take full
> responsibility to reply to change requests (even for several months
> sometimes) and so to be maintainer for some ports, and I don't want to
> prevent any people to modify it quickly too.

It's a solution seeking a problem.
There's no problem.  What we have now works.
I just objected to you thinking that a full-up upgrade of a port is an
obligation for somebody that notices a port doesn't build and marks it
broken.



>>> IMHO ports at freebsd.org means "collectively maintained" (without any
>>> obligation, but with good intentions). There is no reason to put e-mail
>>> address in this field otherwise, just the word "unmaintained" which
>>> clearly indicates no contacts.
>>
>> This is incorrect.  It's ports at FreeBSD.org because it needs a valid
>> email address, in this case a mail list.
> 
> It is not an argument. "Valid email address" is just technical current
> scripts requirement which can be easily fixed to count "unmaintained"
> word too.

At least actions to unmaintained ports get documented.  If we went with
"unmaintained", all actions would be silent.  Unless, of course, you
modified the scripts to look for unmaintained, and then you would have
the *EXACT SAME* situation as we do now.  Changing the value of
MAINTAINER is only cosmetic.  It changes nothing except perhaps it
removes the false impression that the port is maintained (which I would
actually enjoy tbh)



>> The good news is that after 3 timeouts (or less depending on
>> circumstances) you can reset the maintainer.  If it's a one time
>> timeout, that's life.  If it's a theme, then we have options.
> 
> Reset it to unmaintained which you plan to eliminate? Very funny.

what?  I don't plan to eliminate unmaintained state.  It is very useful.
 It justifies the death blow.  There's nothing inherently wrong with
"unmaintained" except when people expect any ports committer to have an
obligation to that port.  That's what I object to -- like what you
implied, that role#1 was obligated to fix an unmaintained port.  Sorry, no.

John