Consider possible ways to shorten code freeze [policy, no patch]

Could you elaborate on why current thesholds are an inadequate solution? I can't parse " it's possible to fix hundreds of them via throughput."

My one worry is that the period before freeze is typically a tremendously productive period for Drupal. We often get high profile features like drap+drop on block admin,garland theme (picked some oldies here - sorry), etc. It would be a shame for all our users if RTBC was in feature shutdown during this period. It kinda muddies the effectiveness of a single deadline.

Huge +1 here.

I think this would go a long way to avoiding what went on the last year of D7's cycle and getting us launch ready efficiently while still allowing some changes in. It's almost like turning up the 'agile' meter from level 5 to 9 progressively before launch, so that by the time we want to be launch ready, we're fully agile - ie. always ready to do the full official release while still working on improvements.

This would also superbly improve on morale of those whose work doesn't qualify for the kinds of extensions that some features got in D7. It was so disheartening to have to stop working on small changes while huge changes continued for another year.

As far as the work that happens in the final crunch, it will just have to happen a bit earlier. And once people get used to working like this, the release cycles should also speed up a bit so it won't be such a panic that if the feature doesn't get in now it has to wait 3 more years. I could see us getting down to even 18 month cycles with a system like this.

Aside: Scope creeping the conversation slightly... [Edit: as I'm not sure where this should actually go, people were saying not to discuss it on the other thread.]

I was skimming this Debian stuff that damien_vancouver was posting about http://wiki.debian.org/DebianReleases#Introduction and it sounds like (despite being a fairly big change in how we think about our major versions), it could make a lot of sense. (Just skimming the intro will give you a quick idea of the system.)

So, the idea that damien_vancouver was talking about is when D8 is released and D6 becomes unsupported, D7 remains the "stable" release which most end users use in production, D8 becomes "testing" which more advanced companies and those who are contributing work with, and D9 becomes "unstable" most recent version. And everything trickles down in backports as usual. It seems like a much more accurate way of naming/thinking of things to what we actually do, how the contrib lag affects the broader community, etc.

Updated issue summary.

Updated issue summary.

Debian is distributed as one big "thing", with all packages. They (sort of) have control over that repo.

Core devs have 0 control over when contrib devs update modules, or decide to rewrite modules, or decide to abandon modules. Any such plan is predicated on the idea that holding back core development for a period will make contrib development move faster. There is no empirical evidence for that claim whatsoever as far as I am aware.

@crell I don't think the point was that contrib development would go *faster*. I think the point was that it would make it clearer, and easier for end users to know what version to use (partly depending on what level they're at). So.... are you totally against the idea of thinking of the major versions like described in #3? (And if so, would love to hear why, as well as your thoughts on how this might relate back to how we hone in on releasability.)

I think the argument against it is that until the newest version is stable, clients don't have a reason to request it, so developers don't have anyone paying them to update modules, so modules only get ported on a "when I get around to it" schedule. Which is basically the same situation that we have each release during code freeze, when APIs are stable (more or less).

In terms of empirical evidence to support this view, see http://webchick.net/node/89. Both Drupal 6 and Drupal 7 (which actually did have an entire year of code freeze) repeated the pattern of "when I get around to it" accounting for a small handful of module porting before release, versus 6 months post-release more than doubling that number. Many of those ported modules come from client work, from both large and small sites.

We also know from http://drupal.org/node/1333898#comment-5301952 that the community (including contributed module authors) doesn't give a flying hoot about Drupal N+1 until it's stable (N.0). The installs of Drupal 7 shot from around 6500 to around 25,000 *overnight*. So in order to ensure you ever get out of a deadlock situation wrt contrib, you *have* to announce the stable version, promote the crap out of it, and get people moving to it so "trickle down" occurs.

Based on that data, releasing 8.0, then calling it "unstable" for a year, is likely only going to mean that we reach that "plateau of productivity" two years after release instead of one.

(This whole discussion doesn't really seem on-topic for the discussion of how we should handle code freeze, however. :))

Contrib porting has nothing do with this issue.

(But for the record, I need to add that it was wrong to declare a plateau of productivity, whereas only having ~66% of contrib modules ported. That said: Wrong issue, wrong topic, wrong discussion. To explore this topic further, please create a new issue and link to it from here. Thanks!)

This issue is about making sense of issue queue thresholds during the last release cycle phases/periods.