From owner-freebsd-ports@freebsd.org Tue Jun 28 20:52:18 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA715B850D6 for ; Tue, 28 Jun 2016 20:52:18 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B6542EFD for ; Tue, 28 Jun 2016 20:52:17 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mandree.no-ip.org ([77.181.5.243]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LzKmP-1bMRuC3IeH-014TTG for ; Tue, 28 Jun 2016 22:52:09 +0200 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 5A46C23D856 for ; Tue, 28 Jun 2016 22:52:08 +0200 (CEST) Subject: Re: blanket portmgr approval vs. non-fixing changes To: freebsd-ports@freebsd.org References: <201606261724.u5QHOLdG081392@repo.freebsd.org> <57701AEB.1050001@tu-dortmund.de> <5770A392.6010605@tu-dortmund.de> <84e4fcf5-7b99-1cc6-e6bd-d3c594a5d102@marino.st> <91BC5F8F9FDB9246529D0693@atuin.in.mat.cc> <5770EED4.1070202@tu-dortmund.de> <18e609c1-e095-99b0-893a-0bb30d3c3d45@madpilot.net> From: Matthias Andree Message-ID: <5772E377.1050509@gmx.de> Date: Tue, 28 Jun 2016 22:52:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <18e609c1-e095-99b0-893a-0bb30d3c3d45@madpilot.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:uDPqCQDFFiFjplBxZdP8N7k22KMmj6ydpqq2zzBX9smRP9nyDFj tl2ZvvKOGBAymqKfZrMdYaYRa3Hnl7dozcdjCLgjo0yQmtFdQTzG4tG939Vrqu/GU5Uj5mI uE3W4Yl7NMJPE+iJUav8Ni134EQryrlhmw67HIToZq9WP/G87LhcGeBKDNzQeqjikw8F/Mm fbbjQTufI74Sj6PewwthA== X-UI-Out-Filterresults: notjunk:1;V01:K0:rOzjBuA6U+s=:H8ac5gz/qIM3drQp0h/BEo cjj44Wer9imzs+QsXwXp3LGIqYzm8RHFomMCnvPjZq0w6l1PssAB0uwnW1VRxLIW95bjcQVks dBDjad2xQQmjm+puqrTccIAYX/0N2DhjttlF8UH8oFSXoUXqdH0nlsDznNvYiMbpMeTrteR+L jIhp3/Fl0JPMa1wRNdA5fP0BX9VR0cZYToYrSw3xCE66kDloF3vZ1XZmGQ3fYaZDYblaUGH7u dAQV2dtE6qnSrWuqYkGHapZBS2p9Ea4IM2uGh20hoYvrHeamN5m5QDsIQZryznXupDe6OmObl ZcaTnqyLwW0ludKEzhVZvsFDTJsoKvUoE/tBVw4KVjgSHABAGV4kgKs5ugYQetgDIbWAejJaG xcTNV143+TfbQGXGzDmX1Vr56yeOKZLLYKqOFzvo98tyaZJyVOiuZMBQbkzo0VVx430+Jen9+ TVJqrPzwGZYn2CA9jYbUmiH6xh2FJo8qj9HRw82ShrdzPZWpLgpp3jkglJYhz4WtdfJNPvXDs iRLYYGSu0RNqsQ59C8goWJAAJh7MoakES/+v9uri5XefM99Ut/KH5uN5X5TUxd2rNFaIY/M1c Uw/NcCkiej1JTNdhWs+kBHmHyCoYCTwPzzAywL/e7HCUKDPTQ7HoO/8MPdczbl7cuzWYeGWWr 1xNaCnb7N6ZNoznf2UQx7hWLbW1deDy4lyIyEtlT81DUMIWVYFltAS6dqQtbbZ7E0J8RlVmbf /eGwrijbCnSWmzt1Nhu8aQqT9XsUSH1GLkdTe0wI9QaAYPFrspKeiyaSCjmrRLmhB3OHwRFeg LenO4Oc X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 20:52:19 -0000 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. >=20 > 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. >=20 > It could be less evident for infrastructure changes which need to be=20 > 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=20 > 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.