Putting this here so hopefully people will read it. ;)

People seem to have taken the notes at http://drupal.org/drupal-7.0-beta3 to mean that they should promote any and all serious bugs to critical, or any and all issues they want me or Dries to look at to critical. This is probably due to my writing instructions up in the middle of the night in the midst of a code sprint.

Clarifications:

  1. Drupal 7 was by definition release-ready as of Saturday, November 13. If your pet "borderline" issue didn't get in by now, it's officially too late. Do not escalate it to critical. Move it to Drupal 8.
  2. Each and every critical takes time away from reviewers, patch authors, and core committers. We have an extremely limited time to shake out the final bugs and get string freeze in order. We need to make the most of it.
  3. By adding your patch to the critical queue, you are declaring that it is worth taking time and focus away from every other critical issue in the queue. Make sure that you actually mean that when you adjust the status.
  4. If it can be fixed after RC1, or even at 7.2, it's not critical. Even if it's a really, really bad bug.
  5. Critical is not a substitute for "webchick please look at this" or "this could really use some reviews." Use IRC for that.

There are probably some other guidelines that need to be put here, but that's a start.

Comments

Anonymous’s picture

Anonymous (not verified) commented

i like this issue. the first two comments from #973486: [meta] Scrub the issue queue of all open, non-critical, API changing, D7 issues are also worth keeping in mind here.

that issue seems to overlap a lot with this one, perhaps they could be merged?

catch’s picture

catch
he/him
Primary language English
commented

Copying effulgentsia's comments and my followup to here to so we can merge them properly:

No API changes after RC1, unless absolutely necessary to fix a critical issue. Therefore, when RC1 is released, there should be 0 open issues for D7 with the "API change" tag. In other words, this list needs to be empty.

So, between now and RC1, let's work on scrubbing that list. Ways of getting an issue off the list:

Get the issue fixed or closed.
If the issue can be fixed without an API change, suggest how to do that, and remove the "API change" tag. Please don't do this unless you're really confident about your approach. Ideally, submit a patch as part of this.
If the issue requires an API change, and needs to be resolved for Drupal 7, escalate it to "critical". If you do this, please comment as to why the issue is important enough to delay D7 release.
If the issue requires an API change, and does not need to be resolved for Drupal 7, bump the version to "8.x-dev". If you do this, please comment as to why it's okay for the issue to be left unresolved in Drupal 7.

- if it's a small api addition or otherwise backwards compatible change, you can always add the 'Needs backport to D7' tag so it can be revisited for a Drupal 7 point release once it's in Drupal 8.

Note that if we keep the 'fix in development branch first, then backport' policy in place during the Drupal 8 cycle, we'll need to bump pretty much every active Drupal 7 issue to Drupal 8 in bulk as soon as D8 actually opens up.

catch’s picture

catch
he/him
Primary language English
commented

And webchick's followup -

Just so it's crystal clear, RC1 is coming out on Nov. 30 with or without that list being at 0, barring any critical security/data loss bug to stave it off for a day or two. But this seems like a very good thing to prioritize between now and then.

that list is here

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Me, myself, and I went through the current major queue on the weekend, reviewing and double-checking classification of issues, which reduced the major queue by 2 pages.

I don't think it makes sense to actively bump issues against D8 at this point in time. Instead, it makes more sense to verify that there is a "dedicated and unique list" of issues everyone is able to work on.

For me, that translates into the following:

- Priority: critical or major
- Issue tags: API change, API addition, string freeze

That should provide us a list of serious issues that should and can only be fixed prior to RC/release. Anything that's not in that list can be fixed post-release or "later" in general. And speaking of generalization, the usual rules of do-ocracy apply to that major list.

Since active work on those major issues will lead to even more RTBCs, it would vastly help if we could transition the current list of RTBCs into fixed.

My work on the weekend only affected current major issues, but I didn't double-check whether any normal issues should actually be major:
Normal issues tagged with API change/addition or string freeze

The effective list:
Critical/major issues tagged with API change/addition or string freeze

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

I'm going to do my best with the RTBC queue, but I've been assigned as lead architect to a new major project at work, and Drupal 7 workshops are starting, and I'm getting the Using Drupal book ported to D7, and the Git migration is hitting critical mass, and Google Code-In is starting, and... :\ (now you see why I was trying to get D7 done by BADCamp. ;))

No other release of Drupal has shipped with a 0 count RTBC queue, and realistically Drupal 7 won't either. But I'll make sure to prioritize things in the queues you've created. Thanks.

EvanDonovan’s picture

EvanDonovan commented

@sun: Thanks for the list. I only wish that my skills were greater so I could help with writing patches and the technical review.

@webchick: I think we all understand that you are busy, and will be grateful for as much as can make it in. Thanks for allowing this last 2 weeks for API changes - looking forward to rc1.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Hm. I apparently need to clarify again.

The rule on API changes hasn't changed. This is not a 2-week period free-for-all get in your stuff that didn't make it in. The only API changes that will be allowed are those that represent serious regressions in functionality that we can't possibly fix any other way. And if they don't make it in before Nov. 30, then we will have to live with documenting these limitations as part of Drupal 7, unless they are back-portable from Drupal 8 (certain optional API additions, for example).

Please prioritize accordingly.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Active » Closed (works as designed)

No longer need this. Apart from #605318: Add some garbage collection to the update manager, RC1 is done.

Thanks so much for all the awesome work, folks. :)