[Meta] CTools 7.x-1.4 release

Adding some cleanup and summarizing what I believe should be a meta issue for releasing CTools 1.4

Also closing out issues regarding maintainership and release as duplicate, related to this:
#2171083: Release Version 7-x1.4?
#1943808: Co-maintainer request

Earl, hopefully I can become a maintainer of Ctools similar to panels? I'm hoping to get a release of both out the end of the month -- pending the issues being resolved in the summary and in panels (almost there, last ones are waiting for a ctools release)

Heh, mainly because I thought we had enough issues already. But I'll take a look through these today and add them where applicable / appropriate.

I don't know why the issues marked RTBC aren't being reviewed, but can definitely acknowledge that maintenance of modules can be very difficult. There is very little incentive beyond "scratching your itch" provided on Drupal.org and maintenance work takes a lot of time. That being said, CTools have 635k installs and is the 2nd most popular contributed module.

There should be incentives to ensure that people who are contributing to it are recognized. There should be some motivation to go through the issue queue and see that reports that people have made are acknowledged, repeatable, fixable and eventually closed.

I've blogged about the use of Flattr & Gittip. The latter brought up some great discussions about initiatives like Top Shelf Modules and DrupalFund.us.

Adoption of any of those platforms seems to be pretty slow though. Gittip has the greatest acceptance on d.o because there is at least a form on each users Profile page to add it in, and yet, there has been marginal increase in the adoption or donation rates https://www.gittip.com/for/drupal/

I tried to highlight how Gittip could be incorporated into d.o's issue queue in order to provide incentives to individual contributors. From feedback there, I decided to look at how Corporate logos could be incorporated into the issue queues (even for anonymous users).

None of these solutions is without it's problems. Some of these solutions will work better to support some projects than others. I think there are probably hundreds of other ways to help shape participation in the Drupal community such that end users, developers, designers and Drupal shops are able to find easier ways to contribute back.

There's a place to discuss Drupal.org improvements in GDO but there isn't a lot of active participation there.

Ultimately, what kinds of UI changes would help make this module better maintained? For folks who are active contributors, what would help you? Is finding time for maintenance seen as a problem?

Patches that are RTBC have to be reviewed by a committer.

I can't speak for @japerry since he's new to CTools, but I can guarantee that it is not a d.o issue that is keeping the other committers from working through that backlog.

CTools is very complicated because it is not a module with a specific purpose, it is just the library that runs dozens of modules, and one change to fix one bug for Panels could completely break Views.

So please, I ask that you keep those discussions to their existing spaces.

I want the discussion about them to happen elsewhere. I don't want to distract from movement on this issue.

But with 600k+ sites using this module there should be resources available to see that this is a priority the maintainers. With so many sites using this module it is even more important to see that the RTBC patches aren't introducing new problems. It takes a lot to motivate anyone to go through 852 open issues and yet I do think that it needs to continue to see modules like this improve and meet the needs of the community.

It is complicated and it takes a lot of time for a team to go through and understand what the implications might be for these changes. And that might be easier if there were more resources.

Getting the RTBC issues tested is why I opened up the sandbox... Now that I'm a maintainer, and because this module is so widely used (and not tested enough) I would like people to test the combined patches on another branch with them together.

I've already found one patch that causes issues with panels, and I'm testing the rest against regression tests we already have. But it could certainly use a bit more testing by other ctools users.

Because many patches have been committed already, it can be sometimes hard debugging what issue caused a regression. When an issue comes up for me, I work backwards until I find a commit that no longer has the issue.

I'm thinking that once patches are looking good in the sandbox, I can move them all over in bulk to ctools. In the future, hopefully RTBC issues won't sit as long, so we won't have to repeat this issue again.

Thanks for taking this initiative @japerry.

Sorry if this isn't the appropriate place to post this, but can this issue be looked at #2147191: CTools (7.13)? breaks support for vertical tabs that come from Contrib modules
It was a problem that was working properly in 7.1.2 but broken by 7.1.3. Being able to use vertical tabs from contrib modules seems like quite a useful feature, so it would be good if it could be fixed.

Again, sorry if this isn't the appropriate place to post this. I appreciate that issues posted above are problem more important to fix, as they actually have patches for them.

Yes, this is an okay place to ask the question.

Preferably you can, or find someone who can write the patch for it first. My job right now is to review already created patches, and if I get those done I can take a look at it (but that might be a long shot).

is there a documented testing/qa framework that can be used by us to help you reconcile the various patches to make sure that they don't break functionality? I know that might be a tall order but you put in hard work and I wonder if there are additional ways for the community to help

This sandbox have all this RBTC ready?

FYI #813754: Ability to set variant machine name in Panels UI doesn't use UUID, it provides a form field allowing the machine name to be customized but still uses the old default.

For folks who want to help see particular issues move from RTBC to committed, there's great news: You can help by providing a constructive review according to the guidelines for reviewing patches. Having multiple or more thorough reviews increases the chances that the issue you care about will be committed sooner.

So, if there's an issue or issues you care about and you haven't reviewed, I encourage you to do so :).

It turns out that we can't put a sandbox Git repo in a make file on Drupal.org and have it build the distro:

https://drupal.org/node/1432190#sandbox

In order for the Panopoly project to do proper testing of these changes, you'll need to:

1. Commit everything your going to commit for the Feb 5th release to the main Git repo.
2. Declare that you're done committing things so we can start testing! Each time a new patch is committed our testing is invalidated and there really isn't time to re-test stuff, so this is important.

Then we'll include the latest Git in our Panopoly 1.x-dev build and notify our community to get testing! Unfortunately, with only 6 days, that doesn't give us much time. :-/

Please let me know what you think!

@dsnopek: You'll just have to manually test it.

@DamienMcKenna: Well, yes, I can test manually. :-) But I'm trying to organize some mass testing by the Panopoly community! If I can't do that with the Panopoly -dev build, I guess I can make a manual build and just post it in Dropbox or something too... Then just merge upstream after the 5th...

@dsnopek can't we automate a build?

@barraponto: Not via Drupal.org! I'd have to build it on my local computer and then upload to Dropbox (or other such service) to distribute it to the Panopoly community. It also means that it won't going through our continuous integration stuff along with other changes we may commit in the meantime - but since we're talking about a release in 6 days, that's not really a big deal. :-)

Anyway, I'm going to wait for @japerry's feedback before doing that. We chatted on IRC yesterday and he seemed open to committing the CTools patches upstream rather than keeping them in his sandbox.

Edit: Sorry! Wrong issue.

Ok! Tomorrow morning, after the 1.x-dev version of Panopoly rebuilds, I'm going to make a call out to the community to do testing on Panopoly with the new versions of CTools and Panels.

I was hoping to start today, but it turns out there were some issues installing Panopoly with the new CTools which needed to get fixed first: #2186405: Revert: Installing 'ctools' (1.4) before 'uuid' during Panopoly install causes fatal error

I'm not super happy about the solution, but it will do for now so we can get started testing functionality. :-)

Fixed the issue in #30 by using only ctools for our internal functions. They no longer conflict.

Panopoly testing was announced:

https://groups.drupal.org/node/403098

Four days is super short notice for a volunteer community, but I hope we'll get few testers. :-)

I suggest to include patches from these issues:
#2119357: Undefined index in ctools_argument_entity_id_context()
#2186167: Undefined index notices in context-admin.inc
#2063977: Broken form data generated by _ctools_context_selector()
#2183587: Add ctools_entity_exists access rule plugin

I don't suppose anyone would be willing to take a look at #1820882: Make node revisions use the node_view display? It's one step towards proper support in the Panels suite for revisions, this one being important as it makes CTools use the same display mechanism to display node revisions as the main node uses, rather than it defaulting back to node.tpl.php.

Due to the new issues people would like to see, we're going to delay this by another week. This should allow for some better testing and a few more patches to make it in.

Since after release I don't anticipate another release for a while, its important to get everything in that we can thats RTBC.

I'm reviewing #33 and #34. Amitai also has a patch he'd like in there.

Can we remove the following text from the project page? It's sad.
EDIT: This is about Panels project page, sorry.

The Drupal 5 version of Panels is more or less unmaintained. If a volunteer wishes to come forward to work on bug fixes and finalizing a Panels 2 release for D5, commit access can be granted to a trustworthy co-maintainer.

Fixed!

Thank you everyone for the help on getting these issues out the door. While not everything managed to make it into 1.4, we tried hard to get everything that had wide adoption in.

I hope to re-visit ctools (and panels) on a more frequent basis, and hopefully releases 3-4 times a year.