On Mon, May 16, 2016 at 1:26 PM, Gregg Smith <g...@gknw.net> wrote: > On 5/16/2016 11:03 AM, Eric Covener wrote: > >> On Tue, May 10, 2016 at 1:38 PM, William A Rowe Jr<wr...@rowe-clan.net> >> wrote: >> >>> Are we ready to start the 12 month countdown as of the next/final bug >>> fix release of 2.2, and highlight this in both the 2.2 and 2.4 announce >>> broadcasts? >>> >> One shortcoming of a 12 month countdown is that some folks will not be >> able to plan/pitch/budget/execute a migration in 12 calendar months >> because of bad timing. >> >> As long as we're not committing to releases in this window, I'd >> personally be okay with pushing out to 18 months re: the later >> feedback in this thread. I don't feel too strongly about> 12 months >> notice, but I will still have a 2.2-derivative in support beyond that >> window anyway. >> > > We should just pick a date right now (say 31/12/2017) and begin announcing > (website/download page/mail lists) it now. Include that one last release > will come out before the end of the year and it will be patches only after > final release and until EOL date. That is 18 and a half months to EOL with > a final release within 6 and a half. This should leave any admin time to > plan/pitch/budget/execute a migration and give everyone a firm date to EOL > to plan around. >
To square this circle... I had expect that the 'final release' for httpd 2.2 would be based on the need for a security fix release, and expected that this may happen as many times over that year long period as were necessary. So from the 'next release' (using that release as a vehicle to make these important announcements) throughout a fixed period, they should be able to get security 'releases' for that period as part of a full tarball. That's the model that we've observed, that the Tomcat project and other ASF efforts have observed. It isn't cast in stone, but it seems to have been workable. If there were no significant security issues, we would probably have no further release candidates tarred and rolled and voted on. Perhaps what Eric and Gregg are asking for is a longer 'official window' of our offering security patches as incidents come up? E.g. after the one year EOL period of creating security releases, we would commit to offering security fix backports to 2.2.x over the following 6 mos? 1 year? These would all be noted under http://httpd.apache.org/security/vulnerabilities_22.html - they would not be 'releases' - would not require 3 PMC +1's, they could be provided so long as a committer wanted to prepare the backported patch, and would be subject to discussion on security@ before publication, and discussion on dev@ after they are publicized/disclosed. Then it becomes a matter of how long we have a group of committers dedicated to making these happen, and whether that group can agree upon a timeframe we can communicate to users. WDYT? I read my proposal, Gregg's and Eric's as trying to state sort of the same thing in three different ways, and I'd like to offer users a single statement that accomplishes these aligned but differently-worded goals.
