Hi Garrett, > On 10. Dec 2017, at 6:55 AM, Garrett Wollman <[email protected]> wrote: > > <<On Sat, 9 Dec 2017 08:05:51 +0100, Franco Fichtner <[email protected]> > said: > >> Hi, >>> On 8. Dec 2017, at 8:25 PM, FreeBSD Security Officer >>> <[email protected]> wrote: >>> >>> +--------------------------------------------------+-----------------------+ >>> |releng/11.1|11.1-RELEASE|n/a |July 26, 2017 |11.2-RELEASE + 3 months| >>> +--------------------------------------------------+-----------------------+ > >> Is there *any* indication when X + 3 is going to be? Because as a downstream >> vendor X + 3 months usually translates to X, because there is no time to >> prepare >> for any of this, especially when swift adoption is enforced by upstream, e.g. >> by deprecated packages, quarterly branch and locking users out of the ports >> tree. > > Yeah, that's been one of my concerns all along with this new > deprecation schedule. It takes me about a month to qualify a new > release, and we have only two windows a year when I can actually > deploy it (after testing) -- from 12/26 to 12/30, and from the Monday > after the first Saturday in June until the Friday before the first > Monday in September.[1] Release schedules in recent years have been > pretty pessimal for me as it is. I'll be rolling out 11.1 later this > month, but if 11.2 were to happen in March I'd be SOL before I could > even think about upgrading.
That's likely. The issue description was refined on IRC a bit and basically goes like this: If we have to plan upgrades of production systems running FreeBSD 11.1 now for all of 2018 WRT 11.2 and not missing the EoL deadline -- how would we plan for it? We can't, because there is no indication when that is going to be in the first place. There are two solutions: 1. Support 11.(x-1) along with 11.x and keep the unpredictable schedule. 2. Set a predictable schedule as soon as 11.x comes out for when 11.(x+1) is planned, even if that deadline is not met in the end. I slightly favour the first solution, but it is clear that it will mean work for an SO. There is probably a third and fourth action and I would like to see the bright and steering FreeBSD project members to take a constructive interest in this matter and not let it go uncommented. Cheers, Franco _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"
