webchick/gist:11268260

## gistfile1.txt
https://drupal.org/node/2136029

Our current policy is to stop security supporting Drupal X when Drupal (X+2) is released. In other words, stop security supporting D6 when 8.0.0 is released. Which means, if the day after 8.0.0 is released, a security vulnerability is discovered in D7 and/or D8, an SA that discloses that vulnerability publicly can be made once it is fixed for those versions, even if the same vulnerability also exists in D6. Which potentially puts sites running D6 at high risk.

The <a href="https://groups.drupal.org/imp">Import API in Drupal 8 core</a> team is working hard to support a direct D6 to D8 migration path (the initial patch was just committed). However, in practice, few sites will be able to migrate their D6 site to 8.0 the day that it's released. It'll take some time for contrib modules to be ready on D8. With D6 and D7, it took over a year from the core release for some of the most popular modules to get ported and released. Some of that time can be attributed to waiting on Views, so now that that's in core, let's make a rough (possibly optimistic) guess that the majority of D6 site migrations can happen 6 months after 8.0 is released.

Part of [#2135189], which was adopted in December, was to extend the support for D6 <em>for security fixes only</em> past the day that 8.0.0 is released for some length of time, to account for this reality. There are a number of very good reasons to do so:

<ul>
<li>There are currently around 200,000 (or ~20% of all known) Drupal sites running Drupal 6, including some extremely high-profile ones. This is an awfully big chunk of our community to just leave behind.</li>
<li>With that big of a footprint, if D6 security fixes were to be made public knowledge without patches provided, this could result in some very embarrassing and very public epxloits that could compromise the integrity/reputation of the project.</li>
<li>We explicitly committed to a D6 => D8 migration path to allow D6 sites to have D8 as a viable destination point for their old sites. But in reality, because contrib will not be ready on Day 0 of Drupal 8's release (and even Day 365), 8.0.0 will not actually provide a viable migration for the vast majority of D6 sites.</li>
</ul>


There are a number of challenges associated with this, however, as well:

<ul>
<li>There is next to no automated test coverage for Drupal 6, which makes pushing any changes extremely risky, and requiring extremely tedious manual testing of multiple aspects of the system.</li>
<li>7.x security fixes are often held up on their 6.x counterparts as a result, delaying the release of fixes for the majority of Drupal users. This is bad for Drupal users as a whole as well.</li>
<li>Drupal contrib has generally moved away from Drupal 6 already, prior to D8's release. Yet supporting Drupal 6 core for N months/years after Drupal 8 means contrib support would be expected to be there as well. (Though obviously individual maintainers can and will opt out of this by marking their 6.x modules unsupported, ideally handing 6.x branch access to other contributors first.)</li>
<li>Drupal developers and site builders have been touting the "party line" with their customers that when D8 comes out, D6 is toast, so many are currently in the midst of D6 => D7 upgrades. Making a policy shift will require them having to backpedal and lose face with customers. (Though may also bring said customers relief.)</li>
<li></li>
</ul>

There are a number of different solutions proposed in the discussion below. The one proposed by Dries in #78, and which currently seems to have support, is:

<h3>Drop 6.x support one year after Drupal 8.0.0 comes out, in 8.2.0.</h3>
(To possibly be revisited + extended, based on the viability of the migration path at that time, but unlikely.)

<h4>Advantages:</h4>
<ul>
<li>Gives developers 12 months to work on a migration path for contrib modules and custom code</li>
<li>Limited additional work to support Drupal 6 as soon as there's a migration path available.</li>
<li>Accepts the reality that the vast majority of the community (including clients + contributors) will not seriously look at Drupal 8 until it has a stable release, based on past experience of API/UI "freezes."</li>
<li>Communication of Drupal 6 EOL can be coupled with promotion around new Drupal 8 releases, no need to spin up separate effort at an "off-peak" time.</li>
</ul>

<h4>Disadvantages:</h4>

<ul>
<li>12 months where both 6.x and 8.x are supported for security at the same time. Contrib projects may get 6.x branches marked unsupported before core does.</li>
<li>More burden on security team + contrib maintainers as many will need to support 3 branches at once. Speaking of which: [#2140299]</li>
<li>Drupal 6 core/contributed module security issues that affect Drupal 6.x core will block an 8.x security release until they're either resolved or support is dropped. (However, this is somewhat mitigated by the fact that clearing the highly critical/critical core security fixes that affect D6 is a blocker to D8.0.0 shipping. See [#2139769])</li>
</ul>

<h4>What we need</h4>

We're looking for contrib maintainers, in their capacity as contrib maintainers, to weigh in on this proposal. Are you willing and able to support your 6.x branches <em>for security fixes only</em> for an additional year past Drupal 8's release, and/or appoint co-maintainers handle them in your stead? Are there tweaks we could make to this proposal that would make you more likely to do so, such as the length of time? Other comments/feedback?
	https://drupal.org/node/2136029

	Our current policy is to stop security supporting Drupal X when Drupal (X+2) is released. In other words, stop security supporting D6 when 8.0.0 is released. Which means, if the day after 8.0.0 is released, a security vulnerability is discovered in D7 and/or D8, an SA that discloses that vulnerability publicly can be made once it is fixed for those versions, even if the same vulnerability also exists in D6. Which potentially puts sites running D6 at high risk.

	The <a href="https://groups.drupal.org/imp">Import API in Drupal 8 core</a> team is working hard to support a direct D6 to D8 migration path (the initial patch was just committed). However, in practice, few sites will be able to migrate their D6 site to 8.0 the day that it's released. It'll take some time for contrib modules to be ready on D8. With D6 and D7, it took over a year from the core release for some of the most popular modules to get ported and released. Some of that time can be attributed to waiting on Views, so now that that's in core, let's make a rough (possibly optimistic) guess that the majority of D6 site migrations can happen 6 months after 8.0 is released.

	Part of [#2135189], which was adopted in December, was to extend the support for D6 <em>for security fixes only</em> past the day that 8.0.0 is released for some length of time, to account for this reality. There are a number of very good reasons to do so:

	<ul>
	<li>There are currently around 200,000 (or ~20% of all known) Drupal sites running Drupal 6, including some extremely high-profile ones. This is an awfully big chunk of our community to just leave behind.</li>
	<li>With that big of a footprint, if D6 security fixes were to be made public knowledge without patches provided, this could result in some very embarrassing and very public epxloits that could compromise the integrity/reputation of the project.</li>
	<li>We explicitly committed to a D6 => D8 migration path to allow D6 sites to have D8 as a viable destination point for their old sites. But in reality, because contrib will not be ready on Day 0 of Drupal 8's release (and even Day 365), 8.0.0 will not actually provide a viable migration for the vast majority of D6 sites.</li>
	</ul>


	There are a number of challenges associated with this, however, as well:

	<ul>
	<li>There is next to no automated test coverage for Drupal 6, which makes pushing any changes extremely risky, and requiring extremely tedious manual testing of multiple aspects of the system.</li>
	<li>7.x security fixes are often held up on their 6.x counterparts as a result, delaying the release of fixes for the majority of Drupal users. This is bad for Drupal users as a whole as well.</li>
	<li>Drupal contrib has generally moved away from Drupal 6 already, prior to D8's release. Yet supporting Drupal 6 core for N months/years after Drupal 8 means contrib support would be expected to be there as well. (Though obviously individual maintainers can and will opt out of this by marking their 6.x modules unsupported, ideally handing 6.x branch access to other contributors first.)</li>
	<li>Drupal developers and site builders have been touting the "party line" with their customers that when D8 comes out, D6 is toast, so many are currently in the midst of D6 => D7 upgrades. Making a policy shift will require them having to backpedal and lose face with customers. (Though may also bring said customers relief.)</li>
	<li></li>
	</ul>

	There are a number of different solutions proposed in the discussion below. The one proposed by Dries in #78, and which currently seems to have support, is:

	<h3>Drop 6.x support one year after Drupal 8.0.0 comes out, in 8.2.0.</h3>
	(To possibly be revisited + extended, based on the viability of the migration path at that time, but unlikely.)

	<h4>Advantages:</h4>
	<ul>
	<li>Gives developers 12 months to work on a migration path for contrib modules and custom code</li>
	<li>Limited additional work to support Drupal 6 as soon as there's a migration path available.</li>
	<li>Accepts the reality that the vast majority of the community (including clients + contributors) will not seriously look at Drupal 8 until it has a stable release, based on past experience of API/UI "freezes."</li>
	<li>Communication of Drupal 6 EOL can be coupled with promotion around new Drupal 8 releases, no need to spin up separate effort at an "off-peak" time.</li>
	</ul>

	<h4>Disadvantages:</h4>

	<ul>
	<li>12 months where both 6.x and 8.x are supported for security at the same time. Contrib projects may get 6.x branches marked unsupported before core does.</li>
	<li>More burden on security team + contrib maintainers as many will need to support 3 branches at once. Speaking of which: [#2140299]</li>
	<li>Drupal 6 core/contributed module security issues that affect Drupal 6.x core will block an 8.x security release until they're either resolved or support is dropped. (However, this is somewhat mitigated by the fact that clearing the highly critical/critical core security fixes that affect D6 is a blocker to D8.0.0 shipping. See [#2139769])</li>
	</ul>

	<h4>What we need</h4>

	We're looking for contrib maintainers, in their capacity as contrib maintainers, to weigh in on this proposal. Are you willing and able to support your 6.x branches <em>for security fixes only</em> for an additional year past Drupal 8's release, and/or appoint co-maintainers handle them in your stead? Are there tweaks we could make to this proposal that would make you more likely to do so, such as the length of time? Other comments/feedback?