blanket portmgr approval vs. non-fixing changes

[Matthias Andree]

Am 27.06.2016 um 12:02 schrieb Guido Falsi:

>> 2. What I was meaning to state was that (and I'll not pick at the
>> kind soul who has modernized the port) we should only apply the
>> blanket approval if ports have fallen into disrepair.
> 
> I'd say that it's a matter of urgency for the change. Need for
> urgency is evident for broken ports and also serious security
> issues.
> 
> It could be less evident for infrastructure changes which need to be 
> urgently deployed to a major number of ports, or changes to head
> which require patching a lot of ports (one good example could be the
> recent update to libc++ 3.8.0 in head, even if it could be accounted
> as "broken ports" case, so with a relatively high degree of
> urgency).

Yeah - but then again head or -CURRENT is a moving target and by
definition non-urgent and maintainers are encouraged, but not formally
required, to support it.

Generally you're raising a good point, but I'd wager the guess that most
of these changes do need more extensive planning anyways and portmgr@ or
whoever is driving such a sweeping infrastructure change will want to
seek the maintainer's assistance.

I'll normally be happy to help with such changes, only not under pressure.

[...]

> We are now in a much better situation and most changes are less
> urgent, and can wait some time. I'd say usually such changes should
> go through bugzilla or phabric review, with portmgr adding special
> case blankets for specific changes which should hit the tree as soon
> as possible, if this is not an excessive burden on portmgr.

On a related note, once in a while I am checking what's on Bugzilla's
table only to find that even the stuff that looks easy (maintainer port
submission or similar) breaks early or raises my suspicion.
Unfortunately that often means I drop a PR and don't really help getting
the ports PR cleared.  When Miwi and I think Kris proposed me for a
commits bit the deal used to be "if the project is find if I mostly tend
to my ports"... and not much has changed since.

> I'm not sure I agree on lowering the 14 days timeout for bug reports.
> I usually reply in a matter of hours if at all possible, 2-3 days
> when I take a long time, at least with a "going to test" message, but
> not all people can manage this, lowering timeouts could raise the bar
> on being a maintainer which is something I think we should avoid.

I concur with that. I'll normally respond within 72 hours, often within
24, and sometimes quicker if the urgency catches my eye.  A catchy
subject on a message Cc:d to my @FreeBSD.org address helps a lot.
"SECURITY" is sure to get my attention rather fast.

> I think it could be enough to state a list of make targets which one 
> must warrant keep working, it's obvious that make config, make
> install and make deinstall should work correctly, less obvious for
> other targets.

That would work for me, too, as a first step.