Date: Wed, 15 May 2019 14:19:15 -0400 From: Greg Veldman <freebsd@gregv.net> To: "Julian H. Stacey" <jhs@berklix.com> Cc: Matt Garber <matt.garber@gmail.com>, Will Andrews <will@firepipe.net>, "freebsd-hackers@freebsd.org" <hackers@freebsd.org>, FreeBSD Core Team <core@freebsd.org>, FreeBSD Stable ML <stable@freebsd.org>, Alan Somers <asomers@freebsd.org> Subject: Re: FreeBSD flood of 8 breakage announcements in 3 mins. Message-ID: <20190515181915.GD42338@aurora.gregv.net> In-Reply-To: <201905151715.x4FHF4eC068579@fire.js.berklix.net> References: <6CE35CEB-C2AB-47B1-AA86-BC9C91B2B8A6@gmail.com> <201905151715.x4FHF4eC068579@fire.js.berklix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 15, 2019 at 07:15:04PM +0200, Julian H. Stacey wrote: > You make some good points, but all depend on variant circustances. I think there's validity to both points of view, and as you say I think a lot of it depends on circumstance. For example on my personal systems, where I can patch/update/change/whatever on a whim, I agree I'd rather know sooner. But I also do this professionally, and at work it's much more difficult to get a maintenance window. In that setting, where you can't patch and reboot a box every day, batching makes sense. It allows several defects to be fixed at once and actually reduces the time you're sitting with publically known issues on your running systems, waiting for RFC approval. That said, there are perhaps some things that can be done to make the process more predictable, which I'd submit for consideration to the various groups on this thread. First, perhaps there could be some advance notice when a large batch of fixes like this is about to drop. Nothing that gives details, but just something to allow enterprise admins to plan ahead and possibly be ready when the details are released. By way of example, I'm thinking of how the Samba project handled a security release which also dropped this week. [1][2] Second, to ensure things are being fixed in a reasonable manner and not waiting excessively long for a batch to queue up, perhaps secteam@ could share vulnerability timing metrics in (for example) quarterly reports, to include such things as time from initial report to released fix, time under embargo, etc. Again, doesn't have to be bug-specific, but an average would be useful. That would set the stage for a meaningful debate based on actual data, instead of just personal preferences. [1] https://lists.samba.org/archive/samba-announce/2019/000477.html [2] https://lists.samba.org/archive/samba-announce/2019/000478.html -- Greg Veldman freebsd@gregv.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190515181915.GD42338>