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. _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"