Short-term roadmap for 6.x-1.3 release

Posted by pwolanin on March 20, 2011 at 2:28am

4 followers

Issue Summary

Given the moving state of issues, this is a meta issue to narrow down the (few) fixes needed before I think we should roll the 6.x-1.3 release. Obviously, general testing and poking at that branch code would be great too.

Here are the issues I see that seem like they ought to be settled before the next release. These are generally rather small in terms of line of code and most just need to be ported or tested:

#899590: CCK facet definitions needs to expand its role and have a 'facets' param.
#840358: Error searching Taxonomies
#864146: When moving fq to q.alt, we should parenthesize each fq
#896324: module_invoke() called too late
#891962: Solr_Base_Query->parse_filters() causes filters to disappear when using or search on taxonomy id's
#955524: Pager does not respect params from modify_query hook
#882638: Clean the text inside indexed tags
#933066: Triggers Node Access Rebuild even if no module implements node_grants
#885950: parse_filters() causes any manually added filters to be lost
#903802: BLOCK_CACHE_PER_PAGE conflicts with theme_apachesolr_facet_list

and maybe:
#871440: Solr taxonomy page displays search form and blocks when the user has no access to the seach
#1084332: Drush command to get PHP client can't run

Comments

#1

Posted by DamienMcKenna on March 20, 2011 at 8:32pm

Subscribe.

#2

Posted by jpmckinney on March 21, 2011 at 8:05am

For 6.x-2.x I would like people to review my patches at:

#509982: Is our use of menu_alter incompatible with fallback to core search?
#614644: Forms attached to Apachesolr search results won't work
#783366: Synchronize apachesolr_search_browse with apachesolr_search_execute
#920880: facet_block_callback not propagated

apachesolr_commentsearch related:

#675262: [apachesolr_commentsearch] HTML entities erroneously generated for author names
#1031612: [apachesolr_commentsearch] Incompatibility with apachesolr_nodeaccess (haven't reviewed this myself)

apachesolr_date related:

#920880: facet_block_callback not propagated

#3

Posted by DamienMcKenna on March 21, 2011 at 12:16am

@jpmckinney: I believe the intent is to abandon v6.x-2.x, so I'm not sure if those will get any attention? Do those problems exist in v6.x-1.x?

#4

Posted by jpmckinney on March 21, 2011 at 1:50am

The intent is to make one more release of 6.x-2.x, and then freeze it. Almost any bug in 6.x-2.x exists in 7.x, and many exist in 6.x-1.x too. It would be imprudent to ignore an issue just because it's tagged 6.x-2.x. I've been going through the 2.x queue and either retagging issues 1.x or 7.x or closing them. The two issues I've linked to in #2, however, are 6.x-2.x only. Given the massive number of issues I've closed, I'd appreciate it anyone could review those two.

#5

Posted by jpmckinney on March 21, 2011 at 5:57am

Indeed, it is important to note that 6.x-2.x was the base of 7.x-1.x and (I think) will be the base of 6.x-3.x. Its experimental features may be abandoned, but as a branch it is the basis of all current work.

#6

Posted by pwolanin on March 21, 2011 at 12:32pm

Yes, James point is #5 I wanted to makes also. Fixes is 6.x-2.x are likely to benefit 6.x-3.x or 7.x-1.x.

#7

Posted by DamienMcKenna on March 21, 2011 at 1:07pm

We're getting awfully meta here and going on a serious tangent, but if the 6.x-2.x is not being abandoned as it currently stands, shouldn't we instead:

Demote 6.x-1.x,
Stabilize & finish 6.x-2.x,
Stabilize & finish 7.x-1.x,
Branch 6.x-2.x to make 6.x-3.x and backport the schema changes?

The confusing part is the separation between 6.x-2.x and 7.x-1.x when the latter is supposed to be schema-incompatible with the former. Maybe it'd help if there were issues similar to this for 6.x-2.x and 7.x-1.x it'd help clarify and we wouldn't be adding 6.x-2.x issues to a 6.x-1.x roadmap?

#8

Posted by pwolanin on March 21, 2011 at 1:51pm

6.x-2.x will be abandoned after the next release, but it will substantially be the starting point for 6.x-3.x. In other words, 6.x-3.x will essentially be the continuation of 6.x-2.x in terms of code history, but we are going to break so many APIs and change the schema that renaming it will help prevent confusion by end users. Hence, if we don't fix these bugs in 6.x-2.x now, we will likely be fixing them in 6.x-3.x later.

6.x-2.x was essentially Robert's testbed for new features, and he does not have time to maintain it, so I would like to make it clear to end users that it's EOL.

#9

Posted by jpmckinney on March 21, 2011 at 4:15pm

Yes, agreed. I posted 2.x issues here, because I'm nearly done closing all the 1.x issues, and I don't particularly like the proliferation of roadmap issues.

#10

Posted by jpmckinney on March 21, 2011 at 4:23pm

Btw, how long does Drupal cache project pages? There are only 208 issues now (58 fixed), not 277 (and 71 bugs, 26 fixed).

#11

Posted by pwolanin on March 21, 2011 at 4:29pm

There's an open bug - it's caching for a week+ by mistake. #1077880: Block cache of issue counts on project pages is not invalidated when it should be

Side note - we should decide on a coherent naming system for schema/solrconfig files.

I suggest this for the next set of releases:

6.x-1.3: drupal-1.3

6.x-2.0-beta4: drupal-2.0-beta4

7.x-1.0-beta4, 6.x-3.x-dev: drupal-3.0-beta4

essentially 7.x we can declare is the 3rd branch in terms of config. I'd suggest we then have the 7.x-1.x and 6.x-3.x config names follow the name of the last 7.x release where the config was changed.