Task Description:

Check that all of the listed modules below have .install files, that they have a hook_uninstall. and that the hook_uninstall deletes all tables and variables (using variable_del). It should delete any tables that are created in hook_install. And it should delete any variables that are created. Variables are usually created through the call to variable_set, but they can also be created through the settings forms (look for the function that defines system_settings_form).

You don't need a local sandbox, but having one would be best. It's always best to run the code before submitting a patch. But since this is a fairly repetitive task, and in most cases you'll be creating a new .install file, the local sandbox isn't a "hard" requirement.

A sample hook_uninstall, taken from phpass, is:

function phpass_uninstall() {
  db_query("DROP TABLE {user_phpass}");
  variable_del('user_hash_method');
  variable_del('user_hash_strength');
  variable_del('user_hash_portable');
}

Before you start on any one module, you should check the modules issue queue to make sure that a patch hasn't been submitted. Please add a comment to this issue when you complete a module. I'll also try to check them off in the module description, as the issues are marked RTBC or Fixed.

This is two GHOP tasks.

Task 1:

  1. CiviCRM Active User
  2. CiviCRM Count Block
  3. CiviCRM Theme
  4. Coder
  5. Short Form

Coder is the only big module in Task 1. You'll need to look at _coder_settings_form(). Three of the modules are related to CiviCRM. You don't absolutely need CiviCRM to complete this task, but learning about CiviCRM would be a good thing.

Task 2:

  1. Reindex
  2. Retease
  3. Views Date Range Filter
  4. Views Fast Search
  5. Views Filter Block
  6. Views Tagadelic

Reindex is a 6.x module, so the patch should be against 6.x. All the other modules, except Retease, are related to the Views module. You don't need to install Views to complete this task, but once again, learning about Views would be a good thing.

Deliverables:

  • create a Drupal issue against each module and submit a patch file for 5.x. If there is already a .install file, then be sure to submit the patch against the latest version on the DRUPAL-5 or DRUPAL-5--2 branches. You'll need to know how to create a patch file that adds a new file. The deliverable is not complete until the issue is reviewed and the status is set to either RTBC or Fixed (i.e., committed).
  • If a module is up-to-date and doesn't need a patch file, add a comment to this issue, saying that you checked the module and that it doesn't need to be patched.

Resources:

Primary Contact: Doug Green

Comments

aclight’s picture

aclight commented
Component: GHOP Task » Task idea
Status: Active » Needs review

Though the task description you've provided is well written, I hesitate to make this a task for two reasons:

1.) It really feels like busy work to me. We've tried to avoid these type of tasks unless by doing them the student has the potential to learn about something useful in the process. For this task, the student would learn how to write uninstall hooks, but that's about it.

2.) Monitoring this task from the GHOP admin perspective will be difficult, since each of these modules has its own issue queue. I think that at most this would be two official tasks (either all of your modules or half of them in one task, half in another). So that's at least 10 different issues to keep track of. I trust that you will do this for us, but if for some reason you are slow to review or otherwise occupied that means one of us needs to wade through all of these issues to see if the student has done the work or not.

As for your task description itself, I would make three small changes:
A.) In the first paragraph, try to de-emphasize that these are *your* modules. I'm sure you didn't intend it this way, but the first time I read that sentence it felt a little like "pick up my dry cleaning". Clearly you're including your modules because you can easily commit the students' changes and mentor the student, but given the "busy work" nature of this task, I would rephrase it a little.

B.) In the deliverables section, we typically specify that a task is complete when a patch has been submitted to the issue and has been marked as RTBC or fixed by a reviewer.

C.) Deliverables says "create a Drupal issue against each module for the latest...". I think you're missing a word at the end of that sentence.

As for whether this should be made into an official task or not, I'd like a second opinion. Just to summarize, here is my pros/cons list. If you feel I've left anything out either way please let me know.

Pros:
1. Relatively simple *coding* task.
2. Module maintainer is on board with task.
3. hook_uninstall implementations in every module is a good goal to work towards.

Cons:
1. Feels like busy work to me.
2. Will be difficult to keep track of progress because there will be so many separate issues in each individual module's issue queue.

douggreen’s picture

douggreen commented

Angie asked for tasks, so here is one.

This is a relatively easy task, but IMO, it's harder than some of the code style documentation changes I've seen GHOP students doing (i.e., make all comments into sentences, now that's busy work!). I thought it would be valuable work for a High School student. They'll need to look at the code for quite a few modules and figure out what tables and more importantly, what variables it uses. They'll also learn about creating patches, creating patches with new files, creating Drupal issues, and about what 20 Drupal modules do.

As for keeping track of them, I look at my issue queue every morning. I don't think that will be a problem.

As for breaking it up into two tasks, I don't think that there will be patches for every one of these modules. Frankly I haven't looked. If the task seems to be taking too long, then I can sign off on it before everything is completed. What is the expected time frame for a task?

Some of these modules are pretty important, I'm overwhelmed trying to maintain them all, and I'd appreciate the help.

aclight’s picture

aclight commented
Status: Needs review » Needs work

We allow students 1 week to finish a task, but it does not necessarily need to take an entire week. The GHOP program will be ending soon, as well, so students are looking for short tasks that they can complete quickly.

I spoke with one of the GHOP students in IRC, and I think he had some good suggestions:

1. Split this into 3 tasks based on the group of the module. eg. CiviCRM, Views, and Other. Or something like that.

2. For each module, have the student report on the tables created and the variables that are created. Even if the module already implements hook_uninstall(), the student will go through the module to make sure that currently all tables and variables are removed when uninstalling. If the module does not implement hook_uninstall(), then obviously a patch adding this feature would be necessary.

So, if you could make the changes I suggest in my original comment, and just give us the skeleton for the task, as well as the three groupings of modules (if you like the idea of grouping them into 3 tasks). If you think this is too easy, one of the tasks was to port codefilter to D6, which ended up being a 2 line patch.

I think grouping into similar modules and making the task a bit smaller makes it seem much less like busy work. And I think it gives you a better chance of getting at least some of these modules fixed up.

douggreen’s picture

douggreen commented
Status: Needs work » Needs review

I've broken the modules up into two tasks. I went through all of the modules, and removed the ones that only needed reviewing. I reviewed them myself and have already committed the necessary changes. I broke the remaining modules into two tasks, trying to balance the work between them. Task 1 has 3 modules related to CiviCRM and Task 2 had 4 modules related to Views. As I think the CiviCRM modules are pretty simple, I added Coder to the first task. And to balance out the difficulties, I added one 6.x module to the second task.

I also made your suggested changes from comment #1.

aclight’s picture

aclight commented
Status: Needs review » Reviewed & tested by the community

I think this looks much better.

I noticed a few typos:

1.) "Before you start on any one module, you should check the modules issue queue to make sure that a patch hasn't been submitted." This isn't necessary any more, right?

2.) "The deliverable is not complete until the issue [is reviewed and the status is set?] to either RTBC or Fixed (i.e., committed)."

In case you don't know, the Google task tracker won't do anything with HTML, so you probably don't want to include any code, etc. tags in the official description when you submit it through Google.

Since these are minor typos, we don't need to review this again. You can go ahead and create these tasks according to our instructions at http://groups.drupal.org/node/7360#tasks starting with either the 3rd or 4th bullet in that list. If you aren't a member of the GHOP group on google, you'll be able to submit the tasks but won't be able to change the tags or set the status to open. I'll take care of that for you once it's posted. If you'd like to join the google group so you can do this yourself, send me your gmail account and I'll add you to the group (IRC as aclight, or my contact tab on d.o).

Thanks for creating these tasks. I think these should be reasonable enough that students will be able to get them done fairly quickly.

Once you post these tasks to the official google tracker, you can mark this issue as closed.

douggreen’s picture

douggreen commented
Status: Reviewed & tested by the community » Closed (fixed)

See Issue 154, #211174, and #211175.

aclight’s picture

aclight commented

Sorry for not being clearer, but these two official tasks have to be separate--you can't put two tasks in one task.

I've created new tasks as you had intended, I believe. See http://code.google.com/p/google-highly-open-participation-drupal/issues/... and http://code.google.com/p/google-highly-open-participation-drupal/issues/...

The drupal.org issues you created to keep track of these two google tasks are fine. I fixed the titles of both of those and provided links to the official task in each case.

Sorry for the mix up