Document issues left before 6.x official release

Excellent question. Ultimately, projects should be OGs, and there should be a wiki page off the project project for this, but that's another story. ;) In the absence of that, we could perhaps use a new issue tag for this. Seems reasonable. "6.x-1.0 blocker"?

I don't have time right now to go through the issue queue and identify all the issues. Certainly, we can't release project_issue without project itself, so moving this over to the "master" issue queue. The most obvious blocker in my mind is this:

#76726: Refactor project module to use Views [meta issue]

The project browsing pages on d.o use the project_solr integration module and rely on ApacheSolr. I certainly don't want to make that a requirement for every site using project*. There are some default views to implement these pages just using views, but they're still broken. No way we can release without that.

I just did a very quick pass through the issue queues for project and project_issue, and here are the rough (unordered) lists I came up with:

Blockers:
#76726: Refactor project module to use Views [meta issue]
#390856: Do a proper page/code split of project
#405478: Do a proper page/code split of project_issue
#358563: Breadcrumb broken for node/N/release view
#432394: Views version filter needs a check in case no version available
#396056: Viewing issues of a project without activating Project releases gives php error
#397616: non-admin users can't add comments to issues if previewing is required
#376377: Issue + organic group incompatibility
#366542: Replace hook_help() hacks with a cleaner solution for the dynamic headers on issue views
#357925: Provide default project browsing views that don't depend on project_release

Wishlist:
#234463: Remove 'access * project *' permissions
#129664: Add setting to disable auto URL aliases for project nodes
#265586: Use advanced help module for project* in D6?

There are probably others I'm not thinking of and/or didn't see on my quick skim, but that's a start...

@fuzzy_texan: Look for the "Tags" fieldset on the issue comment form under the File attachments fieldset. That's where you put in the tags. I believe that all d.o users who can post comments can also tag issues.

@fuzzy_texan: Thanks! A few things:

A) I just renamed those tags to remove the "Project*" qualifier. The issues already know what project they belong to, so there's no need to use unique tags. In fact, I'd like to reuse "6.x-1.0 blocker" for some other projects I maintain which aren't related to project* at all. Lots of maintainers could probably make use of tags like these, in fact.

B) Here's are the new search links, which restrict to project and project_issue:
http://drupal.org/project/issues/search?projects=Project%2C+Project+issu...
http://drupal.org/project/issues/search?projects=Project%2C+Project+issu...

C) You missed these two blockers:
#397616: non-admin users can't add comments to issues if previewing is required
#405478: Do a proper page/code split of project_issue
both are now tagged.

D) I just updated the project and project_issue nodes to point to these lists.

I don't yet want to mark this fixed, since it'd be nice to get hunmonk + aclight's opinions on this, and also, it'd be nice to do a more thorough look through the issue queues and see if anything else needs to be tagged...

I took a look at the queue and have the following comments for the project module queue.

1. For #234463: Remove 'access * project *' permissions, we're probably going to want to do that either now or for project 6.x-2.x, since that will probably require reconfiguration on behalf of site administrators. I don't think it's something that we should sneak in with a minor project update in the 1.x branch after the initial release of the branch. However, it's not an issue I care that much about, so unless someone is willing to drive it home keeping it off of the blockers list is fine with me.

2. I added #441968: Preview Changes loses taxonomy terms associated with a node to the blockers list. It's a relatively new issue but looks problematic.

3. I added #367631: Improve themability of project release download tables to the blocker list, since dww's point in comment 1 of that issue will be true of the 6.x branch if we roll a release before this gets in. But it's relatively minor in the grand scheme of things, so feel free to remove the blocker tag if necessary.

4. Added #364496: project_legacy_paths menu items break all kinds of things since I think it would be a bad idea to include a broken sub-module in the official release.

5. I don't know what's going on with #367068: Project download regressions. Is that important to finish before a release?

6. Added #31994: Add a link to CVS RSS feeds from project node page to wishlist, since it should be very simple and already has a patch.

7. I didn't attach any tags to the following issues, but they might be ones we want to fix before a release (or may already be fixed and just need a status update):

• #170873: D6 reminder: use drupal.sh for CLI scripts
• #358867: Remove dead code killed by views
• #290151: D6: Use Drupal.behaviors in JS

I'll try to take a look at the project_issue queue after breakfast.

As for the project issue module:

1. I think it would be nice to have #367922: Term changes in issue not being properly displayed in emails working before a release, but I think that's going to take a fair amount of work for relatively little gain, so I didn't actually assign either tag to it.

2. #371606: Make issue view breadcrumbs configurable should probably either be a blocker or on the wishlist. Since dww said he'd get on it ASAP, I've added it as a blocker.

3. I added #377596: Adding issue tags without a comment or change in other metadata does not work, though it's possible that this is a comment_alter_taxonomy problem, not a project_issue problem.

4. Added the following to list of blockers.

• #371421: Sending emails for issues that are auto-closed
• #353248: Standardize terminology on either 'status' or 'state', not both.

5. Added the following to wishlist.

• #140989: Renaming components is unsafe
• #159536: Allow translation of status names
• #365060: Port custom html-to-text to D6 drupal_html_to_text()

I was pretty liberal with applying one of these tags, so it's possible that we want to focus efforts on just a subset of these issues, so feel free to remove tags where appropriate.

@aclight: yay, thanks! I did a few followups, but mostly I completely agree with your assessments.

Let's just get hunmonk to weigh in on this, then we can mark it fixed.

the currently tagged lists look great. knock those out, then one more pass through the queue for anything we might have missed and release!