Please explain what is still considered for D7

Marking issues as non-critical doesn't mean you have to postpone them to D8, does it?

But I too, could use some clarification on this.

It is my understanding that non-API changing actual bugs can *always* be fixed past the initial release (7.0). In fact, we're still fixing bugs in D6 right now. Several of those types of issues are exactly were what you bumped to D8 yesterday, while several were perfectly valid to get bumped to D8 (and I'm very glad someone did that for those).

It's a matter of priority. To get D7.0 out the door, it does us no good (both to the project, the community, and core contributor time) to focus on non-critical bugs. Allowing exceptions though hurts this effort and I cringe every time I see that happen. I applaud webchick for getting strict and having to play the tough cop on this, but it's what's best for getting 7.0 released. We can fix those non-API-changing non-criticals after that.

Just because an issue is marked 7.x it does not mean 7.0 indeed. It can get into 7.1. Whether it gets into D8 first or not is a matter of discussion for later.

Right now, criticals are the first priority to be committed.

If there are no ready criticals then committers can look at other bugs. Real bugs affecting users. Cleanup patches probably indeed belong to Drupal 8.

I hope I got this right.

Please explain the exact conditions and rules for patches that will still be considered for D7.

Sure. This is going to take me awhile to write up. I'll be back later today.

About this subject I have some doubts too: some days ago I have been told to have abused the beta blocker tag because an issue I marked was not actually critical (I apologize with Damien for being somehow harsh in that situation). My point was (and is) that if an issue needs committer consideration before a certain deadline (say beta release), it must be allowed to gain the needed prominence, above all an issue that is in RTBC status and thus is likely to be ready to go.

I feel there must be a way to gain such a prominence: maybe the beta blocker tag is the wrong one, but IMO we need a tag saying "Hey, this might not be the most important issue on the earth but must be considered (and possibly rejected) before this deadline". The only alternative I know is turning on IRC and bugging webchick while she is working, since we are on different timezones. Obviously also this tag would risk to be abused, but the entire project infrastructure can.

IMO we need a tool on d.o. to do this and tags seem to be the far easiest way.

sub

sub

I'd like some clarification on what chx describes as "Cleanup patches", for example we have a number of patches floating about that clean up CSS files (mostly removing legacy stuff that went overlooked during Seven and Bartiks dev periods). I would think these might be performance patches since they add needless bytes.

sub

Mooching on by...

If I understand correctly, the current situation, with Drupal 7 beta probably coming soon, is more or less the following (please correct me where I'm wrong):

• Although critical issues do not have exclusivity for fixes and reviews, they do have the priority.
• Before beta, a possible priority order for D7 issues can be:
  
  1. Beta blockers: critical upgrade path or API change issues.
  2. Critical and non-critical issues needed to fix beta blockers.
  3. Other critical issues, trying to fix all before the first D7 release candidate.
  4. Non-critical issues needed to fix critical issues.
  5. Other non-critical issues, mainly bugs.
• All feature requests go directly to D8.
• Naturally, bugs will continue to be fixed after the D7 release, for D7.1, D7.2, etc.

As promised, this is long. If you just want the answer to sun's question about what patches are allowed, skip here.

---

The best documentation I can find for how our release cycles work are unfortunately buried in Dries's Drupalcon Paris slides, which perhaps explains why there's so much confusion and frustration all around. I'll make an attempt here at summarizing, and then hopefully we can move parts of that to the handbook for the benefit of everyone.

Phases of Drupal core's release cycle

Each release of core goes through the following phases:

Code thaw

Just after release of the previous version of Drupal, Drupal HEAD is opened for features. We call this phase "code thaw." During this phase, world domination is the name of the game. Absolutely anything goes. Fix annoying inconsistencies that have always annoyed you, re-write the entire Form API, pull useful contributed modules into core, remove useless modules from core ;), change APIs, add/remove template files, whatever you can dream up. The drop is always moving, and code thaw is the Drupal core team's chance to make their wildest dreams come true.

When code thaw is done, we enter the code freeze state, when we start to severely lock down the patches that are accepted.

Code slush

Newly added in Drupal 7, since Drupal 7 had such an uncharacteristically long code thaw. In this very strictly timeboxed phase, the core committers identify certain important features that are either just about done, and/or are extremely important to the future of the project, and exemptions for these select features (and only them) are allowed from code freeze, as long as they're completed before slush ends.

This phase is also for last-minute API changes and additions related to existing features that already got in during code thaw. No new features. No other API changes or additions. An example here is if there was a clear oversight in a new API that overlooked a common use case.

At the end of this phase, we declare a formal API freeze, and no more API changes are allowed, unless they fix critical, release-blocking bugs. API changes include the changing of function signatures, the adding or removing of hooks, the addition or subtraction of template files or template variables, and anything else that would cause someone who was chasing HEAD with their modules or themes to have to undo work.

Polish phase

Now comes the time for things that didn't get full attention while everyone was crazily breaking Drupal and stuffing it full of new features. Here we work on putting the finishing touches on performance, usability, accessibility, documentation, and string/UI changes. This is a great time to go through and make sure all of Drupal core's help pages are correct, or to clean up odd markup syntax that sneaked in.

At the end of this phase, we enter a string freeze and UI freeze. Like API freeze, this means that we no longer change user interface text or other aspects of the UI unless it's to fix a critical, release-blocking issue.

Release phase

Finally, comes release phase. Here's where we see alphas, betas, release candidates, and finally stable releases of Drupal core.

The main focus during this period of time becomes whacking the count of critical issues down to zero. Once we hit zero (or very close to it), we roll the first release candidate, and once we've released a release candidate that doesn't incur any further critical bugs, the new version of Drupal is released. Everyone rejoices, slaps each other on the back, and then we re-start the process back at code thaw once more.

It's probably easiest to visualize this process as a funnel of sorts:

Here we see that each phase of the release cycle gets progressively less and less permissive about the types of patches that are allowed, and also changes the focus of the core maintainers.

• During code thaw, major API revamp patches are given much more attention than adjustments to the UI text.
• During polish phase, patches that make adjustments to the UI text get full attention, and feature patches are no longer allowed.
• During release phase, we focus only on critical bugs, and other bugs that help lead directly to release. Patches that do "polish" or non-critical API changes are bumped to the next version for the next cycle's code thaw, to build up momentum for the next cycle.

What's an API change?

As a general rule, an API change means anything that would cause a module or theme developer, or someone writing documentation about the next version of Drupal, to have to redo work. Changing function or hook signatures, adding/removing API functions and hooks, adding/removing/changing theme functions, adding/removing/changing template files or template variables, and so on.

Once we hit code freeze, we only allow API changes if they go towards fixing critical bugs. If there's a way to fix a "major" or "normal" bug without changing the API, we go with that, same as we do in stable releases.

What's a critical bug?

A critical bug is something that breaks Drupal so horribly in a way that affects so many users that we can't possibly release without it being fixed. Priority levels of issues has a good breakdown of the differences in priority levels.

As a general rule, these include:

• Upgrade path-related bugs
• Bugs that cause data loss
• Bugs that create security vulnerabilities
• Serious regressions from behaviour that worked in previous releases
• Bugs that cause testbot to fail

The ultimate call on what is critical or not is with the core maintainers.

There is, however, a much longer list of things that are not critical bugs, including:

• Awful problems that also existed in previous releases. If they were not bad enough to block the release of the previous version of Drupal, they will not block the next release, either.
• Edge cases that, while pretty terrible, will only affect a small sub-set of users or circumstances.
• Developer Experience (DX) problems that do not prevent Drupal from being used.
• User Experience (UX) problems that do not prevent Drupal from being used.
• Themer Experience (TX) problems that do not prevent Drupal from being used.

Drupal 7's release cycle

Drupal 7 opened for development in February 2008, once Drupal 6.0 was released. Code thaw ended and code freeze began on September 1, 2009. There were 82 weeks in between. We started shipping alpha releases of Drupal 7 in January 2010. We just rolled the 7th alpha release a couple of weeks ago, and are honing in on beta.

This was, by far, the longest code thaw we've ever done on the Drupal project. In some ways, this was really good. We were able to fix tons of really critical problems, including severe limitations with our database abstraction layer, the lack of field support in core, the lack of image handling in core, and deep-seated usability and accessiblity issues. We were also able to add an automated testing framework and over 20,000 legacy tests. This was a huge accomplishment, and once Drupal 7.0 is released, it will truly be a game changer (and already is, for early adopters).

On the flip side, cramming in all of that awesomeness has left quite a mess for us all to to clean up. :\ Back in September 2009, here's what Dries and I envisioned for a schedule:

"On paper," we estimated that a 4-week "code slush" cycle should be fine for fleshing out the remaining bugs in new APIs such as Field and Entity API, testing framework limitations, etc. "In practice," we are still finding and cleaning up these bugs even now, 1 year+ later.

The result is that core contributors are seeing more and more pushback from the core maintainers when trying to direct their attention on something that does not lead directly to Drupal 7 shipping, especially if there was a designated point in the cycle already (code thaw, polish, etc.) for making such changes.

So what patches are still allowed in D7?

Patches which meet any of the following criteria:

• Fix critical, release-blocking bugs. Certain API and UI changes are allowed here, if they're strictly required to fix critical bugs. In case of disagreement, this falls to the core maintainers' discretion.
• Fix "major" bugs, without changing APIs or UIs.
• Fix "normal", or "minor" bugs, without changing APIs or UIs.
• Documentation improvements (as in API documentation, not UI text).

Probably a few other things I'm not thinking of. But basically, not much, other than straight-up bug fixes. Our focus should collectively as a community be on getting Drupal 7.0 out the door, so it becomes "real" for people, including module developers, theme developers, and our clients. Only then will we grow the base of core contributors and see our long, hard work out in the wild.

But what's the harm?

I was asked to explain what the harm was, really, about allowing us to sneak in patches such as Clean up theme_links() and make it a simpler theme function (just using this as one of countless examples, not picking on anyone here). This function is a complete travesty, there's no doubt. A total WTF to themers. People have been trying since 2006 to bring some sanity here. Someone stepped up and did it, people reviewed it and approved it, it's been marked RTBC, so really, why not just commit it?

Because, there are consequences every time we deviate from the overall release plan:

• Takes time and focus away from critical, release-blocking issues: Since none of us are being paid to work on Drupal core, we need to allocate our attention and focus in the most efficient way. For me, anyway, that means focusing on critical, release-blocking bugs first, everything else second. I don't have control over what everyone else does, but that's how I allocate my time as a core maintainer.
• Sends a signal to all other core contributors that we're still in "polish" phase: All of us have our own pet niggles with Drupal that we really wish were better than we were. Tweaking a theme function here. Adding a hook there. If the core maintainers send up the signal that these sorts of patches are still on the table, suddenly everyone wants to jump in and add their own pet project, too. Which means critical issues aren't being looked at, and core maintainers need to split their atention
• Creates morale issues and dissent: The flip side of the above. When people perceive favouritism or special treatment (contributor X's "polish phase" patches are getting committed during release phase while contributor Y's were bumped to Drupal 8), it builds resentment and mistrust. It also builds this feeling when 3/4 of the people are working hard on the "core" issues leading directly to release, and there are other people off in the sidelines scratching their own itches.
• Makes an already too-long release cycle even longer: Each one of these patches are not something that happens for free. Each patch that goes into core needs to be read, evaluated, reviewed, tested, tweaked, tested again, given final look-over by a core maintainer, and finally committed. This is all time not being spent on the "core" issues that get the release out the door.

  Additionally, every time code changes, it opens up the possibility for follow-up issues, or at the very least re-rolls in other patches to fix tests or whatnot. And lately, our ratio for # of follow-up issues for every issue closed is not great. Hugely expanding that by changing even more code is not the answer. We're in a code freeze for a reason.

• Eliminates incentive to join with community at appropriate times: If we don't ever end code thaw, and we don't ever end polish phase, what on earth is the incentive for helping out during those times when we as a community really need people to rally?

  If we are changing APIs and the theme system months after we declared an API/markup freeze, what's the incentive for porting modules and themes during code freeze? Much safer to wait until 7.0 actually ships, which inevitably leads to a Drupal 6.0 situation, where it was impossible to build a "real" site until 3-4 months after.

So that's my stance on it, anyway.

Will one little patch like this end the world? No, of course not. But it's death by a thousand cuts. As a core maintainer, it's my job to try and keep us in "funnel focus", to enforce the rules laid out by core maintainers before me, and to do so fairly and evenly, regardless of who it is or how much they've contributed to the project. And I try very hard to do so. I don't always get it right. But I try.

Hopefully this helps lend some clarity to my perspective on things, and helps clear up communication channels. It seems you're not the only one for whom these definitions have been a bit murky.

For me I think that:

Beta Blockers are all bug that make not viable the upgrade Drupal 6 to Drupal 7, like:
* Bug that fix the D7 upgrade path
* Bug that eat your data.
* Security bugs
* API changes (this is only for module developers)

* RC Blockers all bugs that don't let you run a drupal site.
* The beta blockers bugs (if we find a new one)
* All the critical bugs (bug that don't let you execute all the major functionalities in drupal)

Final Version blockers:
* The beta blockers bugs and the RC blockers (if we find a new one)
* All major bugs (important bugs)

Thanks for the clarification. I can agree on that.

@webchick wrote:

"A critical bug is something that breaks Drupal so horribly in a way that affects so many users that we can't possibly release without it being fixed."

* I am not sure why the quantity of users is a strong factor here. Something being broken horribly for a minority of users is also critical.

@sun, to get to the original question: You unilaterally fiddled with (dozens?) of issues. On some of them you made that choice that I presume the committers will make. On some you were just wrong. But you created a huge set of changes with no conversation. A simple conversation might have gotten us where we're going.

You might not like it (in fact you don't sometimes) but in the Drupal community, we're committed to conversation. Basically, you made mincemeat of the Drupal Code of Conduct by not allowing a conversation.

A more collaborative way of going about this would have been to go to each of these issues and put a note on it saying:
"IMO this issue will not qualify for D7 because ... and so unless there is strong disagreement I will move it to D8 in a day or two".

That would be respectful and communicative and collaborative.

In fact, I encourage you to go back to all those issues and do just that.

I know it's slow. I know that our process is inefficient. But where it's successful, it's largely because we have a happy community pulling behind it. Your actions undermined the happy community, and IMO are therefore destructive to getting to D7, not helpful. But just minor changes in the process, and some patience, would have gotten you there.

I don't see accessibility mentioned in the list of true criticals / still able to go in, but it seems that issues like disabling the overlay can be easily accomplished with a configuration adjustment for now and then fixed later in the 7.x release cycle. In other words, not having a clear, easy way to disable the overlay on a screen reader is one of those edge cases that effects an extremely small minority of users and a UX issue that can easily be worked around. I'm sure I missed the discussion, but are we privileging accessibility issues above others? (A link would be fine, no need for anyone to have to repeat themselves here. : )

Maybe the more general question is... can someone apply these rules to existing criticals, or must they all be "fixed" before launch? Another odd one when compared with this list is the admin/by-task issue (i.e. it didn't stop a D6 launch)... these things take a ton of effort but don't fit the criteria above (which is why I always figured those were odd issues to have as critical beta blockers, but it's not my territory to demote them).

*Edit* Actually, I shouldn't cherry pick issues - I have a feeling that could just start an unnecessary debate in this issue instead of continued resolution in those. Perhaps instead those issues there should be considered grandfathered in and finished off (since they seem to be ready for review?) and the objective list pointed to in the future?

subscribe

@webchick, thank you for a great writeup!

I have a question about the following:

Finally, comes release phase. Here's where we see alphas, betas, release candidates, and finally stable releases of Drupal core.
...
During release phase, we focus only on critical bugs, and other bugs that help lead directly to release. Patches that do "polish" or non-critical API changes are bumped to the next version for the next cycle's code thaw, to build up momentum for the next cycle.

At least based on traditional software release definitions, I tend to think of alpha as when the last set of features are still being written, and beta as when features are frozen (and therefore a good time to test them out and polish them up). Especially because people might start testing things heavily once a beta is released, so that is when a lot of polish-related issues can actually be discovered.

So I think there is a little disconnect between the idea that we are still in alpha and the idea that we are in a "release phase" where critical bugs should be the overwhelming focus and polish issues should not be.

In any case, I agree that critical bugs should be the main focus, but personally I don't want to focus on them 100% at the expense of everything else; we still have a lot of "major" bugs which individually do not block the release but which collectively are pretty bad and indicate a lack of polish. It seems worthwhile to still fix as many of those as possible before release; we all worked hard on this and do want the first release of Drupal 7 to be something really solid that we can be proud of, right? We don't want to delay Drupal 7 forever for that, but if, say, it took one extra month in order to (carefully) clean up some annoying but non-critical things and make the initial Drupal 7.0 experience a lot smoother, I would think that is worth it.

***

Also a question about this:

At the end of this phase [the polish phase], we enter a string freeze and UI freeze. Like API freeze, this means that we no longer change user interface text or other aspects of the UI unless it's to fix a critical, release-blocking issue.

This seems slightly contradictory to the message that has been going out with the alpha releases; for example, at the bottom of http://drupal.org/drupal-7.0-alpha7, it says this:

The interface strings of Drupal 7.0 are mostly frozen. The days of major changes to the UI strings are over, but we still are changing texts to fix bugs or to lend clarity in the interface. Around release candidate 1, a formal "string freeze" will be declared at which point it should be safe to start translating.

To me, that makes more sense. I've been under the impression that although we certainly don't want to make major UI changes at this point (except for critical release-blockers), it's still fine to do patches that add a checkbox here or reword a sentence there, assuming there is a good reason to do them, but even if it's not a strictly critical bug which they are fixing.

@webchick - Thank you for taking the time to add some clarity here. I understand the rules as laid out and respect the need for them. I can only imagine how badly you want D7 out the door at this point. I just hope that this razor focus doesn't mean that "the rules" are being applied in a manner that is too black and white.

I will say is that I'm disheartened that the input format machine names and other "exportables" issues look to be for D8. In the last year (ie. during code freeze) Features driven workflows have become a game changer for many devs. D7 is so close to resolving issues that regularly stand in the way in D6. See DevSeed's post today on the patches that are needed: http://developmentseed.org/blog/2010/sep/30/features-and-exportables-dru.... I would hate to see this become a permanently maintained patch-set. IMO distros/features are Drupal's golden opportunity and these relatively small changes have massively outsized benefits. IMO these particular "paper cuts" are worth an exception.

Thank you for hearing out what I'm seeing as the impact in this particular circumstance. You may come to a different conclusion about the cost vs. benefit and I respect that. All I can do is make the case.

@rszrama (#18): Agreed we don't want to discuss lots of individual issues here, but to me it actually seems like the current criticals list is pretty consistent with the "what is a critical bug" list in @webchick's post, and maybe looking at those specific examples is actually a good way to lend clarity to the definition?

For accessibility issues, maybe we can explain that by refining the idea that a bug cannot be critical if it only affects a small minority of users, to instead say this: A bug cannot be critical if it affects a small minority of users and those users have some kind of reasonable way to work around the problem. For example, if you can't install Drupal on some crazy server setup that very few other people use, that's not a critical bug because you can switch to a different server. But if you cannot use Drupal due to an accessibility issue, then obviously there is no reasonable step you can take to fix the problem; hence, that can be considered critical.

As for the admin/by-task issue, it's true the D6 version of that page is no picnic... but have you seen the current D7 version? It's a significant regression from D6, and big regressions are still fair game to be considered critical. Also, simply restoring that page to its D6 state isn't really an option because it would conflict with other parts of the new D7 admin UI; hence, the only viable solution is to change it completely.

Now that we have pretty pictures, lets can demote this (and move it to Handbook)

Agreed with David's #22 (on both of those specific issues).

On major/normal/minor bugs I think there's a disconnect in how people are looking at it. iirc Drupal 6 didn't even have a beta release - it went straight to RC, and didn't get into 'release mode' until after the second or third - this release cycle has been completely different to D6 for a tonne of reasons, the last stretch is no different.

The first alpha was nine or ten months ago, when that was released there were over 300 issues marked critical (about 60% of them misclassified). At this point only upgrade path issues and very serious security holes block a beta, that's been the case pretty much since alphas started, but with around 15 critical issues left, there are still beta blocking upgrade path issues left. We could have got to a beta with 30 or 50 critical bugs that weren't related to the upgrade path, but lack of testing until recently and people's priorities (at least for me who's been using Drupal 7 in my day job since February, the last thing I have to worry about is upgrading from D6, but I do find new issues in D7 several times a week) means those have been left to the very last minute compared to everything else.

So, right at this moment, the absolute top priority is getting to a /beta/ release - since at that point:

* People who want to try Drupal 7 for their site but don't want to risk relying on http://drupal.org/project/head2head will start doing so (Michelle asked just yesterday if she should wait for beta or not to start a new blog on D7, and decided to wait based on what #drupal-contribute said).
* Module maintainers who haven't started porting their modules to D7 will start, people who started months ago but stalled will pick it up again.

Both of these groups of people (and there's a lot of overlap), are a massive, massive pool of people who've either never tried Drupal 7 before, or may not have for months, and they are guaranteed to find new release blocking issues. There will be a similar wave of activity when the first RC comes out. The fact that there's been 10 months without a milestone change in terms of the overall release, is I think the main contributor to people getting pissed off with each other.

While all those new bugs come in, assuming no huge influx of criticals before the first beta, the list of critical RTBC issues isn't going to be that long, while new criticals will be added and filtered out for a good week or two following the beta, which will have to be discussed and patched etc.

At that point, I think it's likely that Dries and webchick will be able to spend more time looking at major and normal RTBC issues - since there'll be much fresher critical issues (instead of the months old ones that are driving everyone up the wall) that need to be worked through. Personally I think it would be a bad idea to do a 7.0 without all the major issues having had a sweep through by both regular core contributors and committers, just in case something is borderline critical, and at least to have an idea what needs to go in to 7.1 if it's not quite ready for 7.0. It would also be really nice to not release 7.0 with any RTBC normal bugs either, (just for polish/morale etc.). However things don't necessarily stay RTBC until they're committed, and once we get to Beta and RC, more issues are going to have to be moved to D8 (but once we get to those points IMO, moving in bulk pre-emptively just means more time arguing about it).

The main issue then is what plach discussed - issues which are major/normal and RTBC, still nice to get in to D7, not /only/ clean-up, but might get rejected post-beta because they make small API changes/additions etc. What's needed isn't necessarily an urgent commit, but just an indication of whether it's worth continuing to maintain the patch against D7, or to push it to D8. Generally people have been using the Needs committer feedback tag for that - but this doesn't look to be a well maintained tag at the moment.

Cross-posted.

[I]f you can't install Drupal on some crazy server setup that very few other people use, that's not a critical bug because you can switch to a different server. But if you cannot use Drupal due to an accessibility issue, then obviously there is no reasonable step you can take to fix the problem; hence, that can be considered critical.

@David Rothstein, that's a perfect description of the difference. Thanks for stating the case so well.

I spent about 4 hours writing the post above and still have a ton of work to do tonight, so this will have to be brief, sorry. :\ Going from the bottom up...

+1 to everything catch said about how crucial getting a beta release out the door is, and why. I also agree that once a beta comes out, focusing on the rest of the RTBC queue will get much, much easier for Dries and me. Hopefully that addresses David's concerns. And I'll add a bookmark to the "Needs committer feedback" tag; sorry, that one slipped off my radar.

+1 to David's suggestion to amend whatever I said above to "A bug cannot be critical if it affects a small minority of users and those users have some kind of reasonable way to work around the problem." I think that maintains the spirit of what is meant, without discriminating against minorities, which was certainly not my intent.

About specific issues mentioned here, I believe I've already chimed in on all of the ones discussed above. The ones that are already marked critical are staying critical. The ones that are bumped to D8 are staying bumped to D8. Dries is of course free to overrule any of these decisions, if he feels that's the right course of action, but I stand by them for the reasons outlined. But, let's please not derail this discussion of specific issues; we can discuss them in their respective places instead.

Re: David's "it's still fine to do patches that add a checkbox here or reword a sentence there, assuming there is a good reason to do them, but even if it's not a strictly critical bug which they are fixing." That's not the rule stick I've been applying. People are actively writing books about Drupal 7 (at least two have already gone to print), people are taking screenshots for the handbook so that docs are ready to go by the time D7.0 ships, people are starting on translations on localize.drupal.org, etc. And this is great, we want them to do that, because they'll find all kinds of problems that way that we need to resolve before we ship 7.0. I'm fine with fixing typos in UI text or places where instructions are just plain wrong, but to me UI/string freeze means just that. We don't change them unless we're fixing bugs. I think it is true that these bugs won't always be critical (a typo in UI text is a 'minor' bug in terms of priority level). But we don't re-word sentences just because they could be a little nicer at this point, IMO. That was for polish phase. And that sentence from the release notes is indicating that in RC we really, really lock things down, and only change strings in case of a flamingly critical issue, in order to allow translators something solid to work from in preparation for release.

Re: David's "At least based on traditional software release definitions, I tend to think of alpha as when the last set of features are still being written, and beta as when features are frozen (and therefore a good time to test them out and polish them up). Especially because people might start testing things heavily once a beta is released, so that is when a lot of polish-related issues can actually be discovered." I can't really explain this discrepancy; these release rules pre-date my involvement in core. I guess they can be at least partially attributed to the fact that we're not paying anyone to work on core, and so we need to provide different incentives/motivations for slogging through the bug fix phase. I think as we get closer to release and get more eyes on things, we'll see some obviously dumb things and will fix them up, especially because there hopefully won't be 18-month, 300+ reply long mammoth critical bugs hanging over our heads anymore. But the extent of the changes allowed will get smaller and smaller as we get closer and closer to 7.0; we'll never ship if we keep moving the goal posts.

And I think int's #14 sums up what I'd like to see happen too, although we'll have to see what reality actually brings. The more people who help, the more likely we are to meet it.

Just a note, on 'Needs committer feedback', I don't think anyone's maintaining that tag well at the moment, wasn't specifically aimed at webchick or Dries - however if we can use that productively I think it'd help those issues that people really care about, need feedback on architecture/applicability, but aren't general blockers.

Yeah, I agree that getting a beta out ASAP is extremely important, so focusing 100% (or close to 100%) on criticals until then makes a lot of sense. (Although hopefully the beta is only a few days away anyhow.)

And right, I mostly agree about the UI changes also - we shouldn't be changing the UI at all unless it's to fix something that actually resembles a bug :) I was just confused because it sounded like the idea was not to change a single bit of the UI except for critical bugs which didn't sound right, but as long as it's more open than that it makes sense to me.

About the 'Needs committer feedback', I feel this is somehow too generic. I'd wish something like 'deadline beta1', this way committers can skim through the related (RTBC?) queue periodically (or at least once) before the deadline comes. Having a generic tag that doesn't distinguish between deadlines is problematic because it does not convey the urgency an issue has.

On the beta blockers under consideration for review, I think that probably they include not only the remaining 3 upgrade path issues, but also the 4 critical D7 bugs that need some API change to be fixed, most of them in needs review or RTBC status, so that not only the pioneers but all D6 modules can begin to be ported to D7 when beta is out.

It looks like quite a lot of users are going to start building sites with Drupal 7 beta, without waiting more for the full release. Naturally, if they found serious bugs of that kind, it would be difficult to say to them "oh sorry, this fix needs a minor API change, and we have to wait a couple of years until Drupal 8; it should have been fixed before D7 beta". ;)

Drupal 7 has been a complex release cycle so far, which is inevitable given the great change that is coming with it. But we are at the doors now. Let it be a wonderful release.

This is a very useful thread. It will be great of D8 to have this process documented & understood by everyone. There was a point last year when I was certain that it was really our last opportunity to bring in some accessibility features we'd been working on over the summer. Fortunately, we were able to make many enhancements since then to core.

Most of the accessibility patches that have been submitted do not change the APIs or UIs. There are some, especially regarding color contrast/luminosity, that I agree will need to be addressed in D8. However, there are quite a few, especially since August which I've added to mark missing labels for fields. As we all know, there are a hell of a lot of fields in Core. It would be very interesting to know just how many there are. I don't know that we'll be able to even catch all of the missing fields in Drupal core, by the release of 7.0 let alone provide suitable patches for them all.

However, they don't change the UI or API for the most part, so I can't see why there would be any reason that they can't be brought into Drupal 7 when they are ready.

Part of this comes down to the process. Drupal 7 has never had a full, comprehensive accessibility audit. Like usability & security studies, these things take time and indeed resources to ensure that they are done well. There have been a core team of accessibility advocates who have been trying for the last two years to identify & address issues. Thankfully the community has been very supportive of this initiative. I can't begin to list all of the folks who have helped, but certainly @sun, @Dries, @webchick & @chx have all provided support. We still haven't done this or defined how it should be done #755790: Review core for accessibility before release but the work I did in August to add labels to field was a result of attempting to do something on this front.

So many of the label issues are super simple fixes, often involving only a line or two of code. Others are going to be much more involved. Never the less we have to do what we can to make Drupal Core meet WCAG 2.0 A compliant. This is a minimal starting point for accessibility and one that I am confident that we can achieve it. However, I don't think that Drupal 7 can or needs to reach that level of compliance for a release. I'm as eager as anyone to get this software out the door, but like with validation error, it will get fixed up in a maintenance release.

Finally, I do wonder if there needs to be some modificatio0n to the issue settings options. It would be nice to be able to identify those patches which are both RTBC & super trivial to review/incorporate rather than those that do need to be considered more. Hopefully for D8 we'll have had a review of the issue management process to see if there is a better way to manage the workflow, particularly for the core team. I find keeping up just with the accessibility issues quite time consuming, it would hard to even imagine the issues, code & complexity that Dries/Angie have been working through since work began on D7.

I have to disagree with @mgifford. By saying that WCAG 2.0 level A violations are not release blockers we are telling a minority of our users that their needs are less important than the needs of the community as a whole. Perhaps this is the value statement we wish to make, with which I would disagree, but which I would accept. We must, however, be clear that this is the message we are sending to affected users, who are by and large marginalized in every other part of life.

The reason things got ugly is that we normally have no problems shipping a beta because the update path is there and ready. In this case, this crucial beta blocker was our biggest issue indeed the last few months. So while we dont have a beta everything else got polished up and so the expectation is that the journey this time from beta to release won't be a long one. (Hopefully)

Once again, I'd really like us not to delve into specific issues on this thread. But on this...

"It would be nice to be able to identify those patches which are both RTBC & super trivial to review/incorporate rather than those that do need to be considered more."

I've been standardizing on the Quick fix tag for these types of issues. If they're actually no-brainers. This is similar to, but not the same as, the Novice tag which means "this is easy to fix/review," and signals to new contributors a place they can start. This is the tag to use when you find a bug and think to yourself "That's so easy to fix, it's not even worth filing an issue about." ;)

Sounds like we could also use a documentation page/pages for frequently-used tags. ;) The sub-pages under http://drupal.org/community-initiatives/drupal-core have some, but a lot are just weird conventions that various people have come up with ("Needs tests" etc.).

Oh, but on this...

"There was a point last year when I was certain that it was really our last opportunity to bring in some accessibility features we'd been working on over the summer. Fortunately, we were able to make many enhancements since then to core."

I think this is misleading. I believe we've been quite consistent that any new accessibility features (like the WCAG-compliant colour picking functionality) have been pushed to D8, just like any other feature. But anything that is proven to actively prevent someone from using Drupal, like the various overlay issues, have been escalated to release blockers and dealt with accordingly.

@Everett - As with the #D7UX pledge we've been asking module maintainers to make, I think we need to be clear that this is a priority of the Drupal community and that we will fix this as quickly as we can when we are informed of an accessibility problem. We know there are a bunch of problems with input fields not having associated labels or titles which breaks WCAG 2.0 A. But it could take another few months to find, fix, patch & review all of them. Which is why I'm pushing to fix the easy ones, identify the hard ones & ensure that there is an understanding that they are going to be incorporated into the 7.1, 7.2, or 7.3 releases along with other maintenance changes. I think this would be a clear & acceptable solution for everyone. Not as good as having dedicated resources to fix them all this next week, but I don't see that happening. I think more folks are going to benefit from having D7 released (say in October) with some remaining known issues that are being worked on, then waiting till sometime in 2011 when we've been able to go through and do a full assessment.

@webchick - It wasn't a matter of being misleading in any way. I certainly didn't want to suggest that. It's just it wasn't clear what changes could get in when. The work you've done here to document the process should really help for D8. It's still going to be something that folks who are relatively new to the process are going to struggle with. Sorry that there was a misunderstanding.

webchick's summary in #13 is spot on.

The most important part of the write-up, IMO, is the definition of a critical bug but also the impact of beta blockers on the release schedule.

I might tweak the process for the Drupal 8 process in order to help clarify things, and potentially, to align it better with release management best practices found in other projects. That is beyond the scope of this issue though. The Drupal 7 process will certainly be at the basis of the Drupal 8 process.

However, for the purpose of the Drupal 7 release, webchick's write-up is accurate.

I have to disagree with @mgifford. By saying that WCAG 2.0 level A violations are not release blockers we are telling a minority of our users that their needs are less important than the needs of the community as a whole.

@Everett -- accessibility is important but so are many other things in Drupal. One could argue that not fixing certain usability issues, is telling a minority of our users that their needs are less important. Similarly, one could argue that not fixing certain performance and scalability issues, is telling a minority of our users that their needs are less important. Last but not least, one could argue that not fixing certain translation issues, is telling a minority of our users that their needs are less important.

While accessibility is very important, accessibility issues shouldn't normally hold up a release. Accessibility problems can be treated as bugs, and can be fixed in bug fix releases such as Drupal 7.1, Drupal 7.2, etc. Needless to say, some accessibility issues can be critical, but most of them probably aren't.

I hope that clarifies my view on accessibility bugs.

@Dries

How do you propose that we prove that a WCAG 2.0 level A violation is critical? IMO, the purpose of level A is to identify those barriers that will make a site, or behavior, inaccessible to some group of persons. We do not have the resources to test Drupal with every configuration of user with a particular disability / assistive technology used. IMO, this is why we need to trust the experts at the W3C who identified certain success criteria of WCAG 2.0 as being level A.

Many in the accessibility field map A, AA, and AAA, to must, should, and may, respectively.

I think we've all gone through great length to let (non-critical) accessibility issues slip in late in the Drupal 7 code freeze. Accessibility improvements have been very high on my list and both webchick and myself have made many exceptions for it. I'm both proud and excited about all the accessibility improvements we've collectively made in Drupal 7.

Now, I never wrote that a WCAG 2.0 level A violation is not critical. Nowhere in this thread did I even reference an accessibility standard. Be careful not to put words in my mouth, Everett. It is not cool when you twist my words and take them on a silly Twitter tirade (http://twitter.com/ezufelt/statuses/26167769806). That is not how we work together in this community ... it's counter-productive.

Anyway, as I already wrote in #39, accessibility problems can certainly be critical. If a feature is completely inaccessible, than that makes for a critical bug. Reality is that many accessibility improvements are just that -- improvements. Visually impaired users can still use Drupal without them -- it is just harder to use. Such improvements should not hold back the Drupal 7.0 release as they can be addressed in subsequent bugfix releases (e.g. Drupal 7.1, Drupal 7.2, etc).

People's opinion on the WCAG 2.0 vary widely -- it is criticized as a standard. Many government websites don't even require WCAG 2.0 level A compliance. That said, the WCAG 2.0 is probably the best tool that we have. I think it is reasonable to say that WCAG 2.0 level A violations start their life as 'critical'. We can demote them on a case per case basis if we feel otherwise.

@Everett - Rome was not built in a day. At some point we sign off D7 and say "we did the best we could in the allotted time". This is something every developer, in every corner of Drupal has to do. This thread was sparked by that exact debate. We need to move on, accept what we have achieved as a great achievement and look forward to moving ahead with improvements in the next version.

I do not believe (afaik) that failing Level A has ever been considered "critical issue" (meaning they are not automatically critical, they may be, but not always). It was a goal (indeed we have many AA, AAA passes in D7). Perhaps in D8 we can make it so, as we really should at least pass the minimum requirements of Level A. This time however we have accept that we did our best. Certainly D7 is a vast improvement on any previous version of Drupal.

@Dries

1. I apologize that I misinterpreted your response to my comment, in which I mentioned WCAG 2.0 level A, as being a comment on WCAG 2.0 level A. I believe that I formed a reasonable inference, but am happy to be corrected.

2. I do not consider expressing my disappointment in one of your decisions, no matter how publicly, especially when I provide reference to your exact words, as being a 'tirade'. I do consider it as being free speech, something that, as far as I know, is 'how we work together in this community'.

3. Not to put words in your mouth, but accessibility is about more than the visually impaired. It is a complex field that takes into consideration physical, perceptual, and cognitive impairments. There are socioeconomic considerations, including, but not limited to, access to technology and access to training. It is sometimes easy to identify that a particular issue will make it impossible for a certain subset of users to perform a certain task. It is often not this easy. For example, can a sighted keyboard only user do X, can a Dragon Naturally Speaking voice command user do X, can a blind screen-reader user with two year old technology do X, can a blind screen-reader user with two year old technology and a cognitive impairment that affects short term memory do X? Because the permutations are so vast, my recommendation is that we rely upon the expert guidance of the W3C by considering all WCAG 2.0 level A violations as critical. I do, however, accept your decisions as final within our community, whether I agree with them or not.

@Everett - I don't suppose it makes a difference to you whether or not accessibility problems must be fixed at core or if there are ways to use the Drupal APIs via contrib to solve them? There's no reason http://drupal.org/project/accessible can't take accessibility further than Drupal 7.0 is able to and be bundled into a "WCAG 2.0 Drupal" distribution until such fixes can become a part of core... There's actually a fine history of problems being solved in contrib that we don't have core solutions for until the next release cycle, sometimes incidentally (most of the modules deprecated by D7) and sometimes intentionally (see what folks are trying to accomplish with profile2).

@Everett -- of course you're free to broadcast your disappointment to the world if you feel that is the right thing to do or if that provides some relief. It agitated me, and I apologize for that -- I should have a ticker skin, especially after all these years.

That said, I don't want to create a culture where all core Drupal developers broadcast their disappointments on Twitter. I simply don't think that fosters constructive collaboration. That is why I felt the need to comment on your Tweet. I know it was only one Tweet so I probably jumped on it too quick. I see building the right culture as a big part of my role though.

Now, back to accessibility and the Drupal 7 release. I understand you are disappointed in my decision. In fact, I'm disappointed in my own decision as well. ;) Like many of us, I want to deliver the best possible product and cutting accessibility corners is a hard decision to make. However, I do believe it is the right decision at this point in time.

So, do you agree or disagree with my decision? If you disagree, we can discuss it further -- I obviously value your input on this matter. If you agree with my decision (albeit being disappointed), I hope you can respect that decision and continue to kick ass fixing accessibility bugs. After all, we can still fix accessibility bugs before Drupal 7 ships.

@Dries

I could have waited to allow you to clarify your comment prior to expressing my disappointment with your decision, for which I apologize.

I am comfortable with an approach that recognizes all WCAG 2.0 level A issues as critical, until they are shown to be otherwise. This is predicated on the burden of proof being on those proving that a bug is not critical, rather than on those arguing that a bug should remain critical.

Examples of level A violations that are not critical would include:

#49428: Include node title in "Read more" link for better accessibility and SEO - The question here is whether the purpose and role of the 'Read more...' link is programmatically determinable. This is a somewhat subjective question. Since a. the link appears in a list directly after the node teaser, and b. the same functionality of accessing the entire node is provided by the linked node title above the teaser, this is not, IMO, critical. Would it be nice to provide more context for the link for those users who primarily rely on a AT generated list of links to access page content, yes; is it critical to do so in light of the linked node title, no.

#849926: links wrapped in .contextual-links-wrapper divs are not accessible at all via keyboard alone also problems with screen readers - The issue here is that a keyboard only user cannot set focus to, and therefore activate, the links. This is functionality that is provided for convenience, accessing the pages linked to by these links is possible through a different path. Would it be nice for keyboard only users to be able to use these links, yes; is it critical for users to be able to access these links, no.

In the case of #882694: Add missing form element titles for accessibility, which is still set to priority critical, the question is will missing accessible names (labels or title attributes) on form fields cause the forms to be unusable*, for some users. We are in fact here attempting to prove a negative 'no users will find the form unusable'. For the first two examples that I provided the functionality that is violating WCAG 2.0 level A is redundant, in this case, as far as I know, the functionality is not redundant, or at least not apparently redundant. Therefore, I would prefer we err on the side of caution, ensuring that, as much as it is reasonably within our ability, all users are able to use the forms, by providing accessible names for the form fields.

* I prefer that we take an approach that considers a UI that is so frustrating to use as to be unusable, as being unusable. Factors that may affect this determination would be if the user has to guess at the purpose of a link or of a form field.

Taking the above examples into consideration, the conditions that I believe an accessibility issue must satisfy in order to be considered critical are:

1. a WCAG 2.0 level A violation,
2. For which there is no apparent alternative method of performing the given behavior, and
3. Where deprioritizing the issue places the burden of proof on showing that the issue does not make the UI functionally unusable.

@webchick, many thanks for the great write-up (it should be moved to the docs, it's too good not to).

I may be wrong, but I get a feeling that more often than not the problem is not the API change, per se, but how the API change is made. If you look at our "neighbours" in the Java world, for example, when they change API, they do it in a backwards-compatible way. They mark the "old" API as "deprecated", but it is still fully functional. They introduce the new API, allow both APIs to run concurrently until the next major release, giving people using the API ("module developers" in our case) ample time to migrate.

I think this is the big missing thing in Drupal. Often changes are made in an "either/or" fashion and that is what is causing problems, not the need to change per se. I mean - the whole beauty of Drupal is its agility. If we can't change things - what's our value, really?

One more thing I would like to stress is that, we _have_ to remember: as Drupal grows, major releases will inevitably become more infrequent. It will not be possible to have the same turnaround for Drupal7 -> Drupal8 that was for, say, Drupal5 -> Drupal6. I think Drupal7 is a good example. I believe the community and core developers were much more prepared and organized for D7, than for D6, yet it is being delayed. I think it is incorrect to say that it is being delayed due to lack of effort. There's actually more effort than before, it's the scale that gets in the way. Similarly D6 will have to be supported longer than D5 had to.

Point is - as major version releases stretch in time, community will have to find new ways to timely introduce much-needed changes incrementally.

Just my two cents.

@irakli A negative side effect of this backwards compatibility is that there are two defined functions rather than one. From my limited knowledge of the internals between these 2 systems, PHP loads the entire code base into memory for each HTTP request, while JAVA can share these functions in memory. That is why many really big systems are programmed in JAVA, they have less overhead on heavy traffic volumes and this also means that they can bypass a lot of the caching issues that complicate things in PHP on large scale systems. To paraphrase, more code is a negative to performance.

@Alan D.,

good point, however: Drupal sites that care about performance use opcode caches (APC, eAccellerator etc.). opcode caches hold parsed PHP code in-memory and void the need for per-request loading/parsing. Also, as in anything it's a compromise: how many modules does a typical Drupal site have? How many lines of code is that? What portion of that would be "duplicated" functions if we adopted proper backwards compatibility? Very negligible. Also, to keep in mind: a lot of times, "old" interface can creatively call "new" interface which makes this a non-issue even without opcode caches and on minimal Drupal installs.

I'm marking this fixed. This is possibly the least appropriate place to be discussing backwards compatibility in Drupal core that there could possibly be.

Well hold up. #13 needs to go in the handbook with the minor adjustments discussed later in the thread. I'll get to it later this week.

What does and does not make into D7 (not 7.0, but D7) was the question of this discussion. That has everything to do with how releases are handled and how releases are handled is driven by decisions involving API changes and compatibility. That's why it was mentioned.

If this is "the least appropriate place there could be", would you be so kind to point - where is the appropriate place? Because it is an important topic.

I would also kindly ask to be respectful of each other and not be dismissive.

The appropriate place would a new issue, for Drupal 8, discussing whether to introduce backwards compatibility.

I'm dismissive because backwards compatibility has been discussed, to death, both in the issue queue and the development list for several years, and is well documented in http://drupal.org/node/65922

Being respectful would involve not derailing the issue into years old debates which are only tangentially connected so that it keeps bumping up in the trackers of busy core developer's issue queues when it's already been resolved.

Thank you. I will open a new issue then.

Just to clarify though: the backwards compatibility discussed at the link you kindly pointed me to, is not exactly the one I was talking about. I will try to explain in more detail what I am asking about, in the new issue.

As for the fact that something had been discussed "to death" and it can be annoying to see the same question pop-up: well, i very much understand that. However:
1. the person asking it again may not have been part of that discussion, so there's no reason to dismiss an honest question.
2. things change and processes do not work forever, much like the code. Processes sometimes need change as much as the code does.

Anyway, thank you for pointing out the appropriate place. I will try to make a case and show how current process, without any modification, may pose problems for Drupal's ability to quickly change (the very goal current process was designed to support). If anybody cares to listen, I hope I will get proactive feedback. If not, so be it. I don't have any illusion that I should be able to influence how things are done in Drupal. Far from it. I do however hope that I have proved my dedication and loyalty to this system, through my contributions, to be eligible to, at least, an opinion.

Thank you

Ok. Copy/pasted most of #13 into http://drupal.org/node/935558, minus the Drupal 7-specific stuff. I am not sure if that's the most opportune place to put it, but now that it exists it can always be moved around. :)

@webchick i think that's as good a place for it as possible - thx for updating it

This just has been thrown out of the window with #933846: Better distro support so I recommend rewriting it.

Dries said, "Write a patch and we'll see." That hardly qualifies as throwing something out the window. And even if the call is ultimately yes, this hardly qualifies as the first time (nor the last) that someone's suggested a core improvement way too late. Yet, the general guidelines encapsulated in that page still stand. There is no reason to not mark this issue fixed, nor to boil over bad feelings into yet another innocent issue.