CVS account process needs revamping

I go back and forth on whether CVS apps ought to have their own project issue queue instead of a component. I'm still undecided.

I don't really like the mailing list being the center of the applications at all. The way to link the issue with the app would be for the app to either automatically generate an issue and copy the applicant by email about the issue node or maybe for there to be a cvs applications project that had the "you must be a good user" disclaimer stuff as part of the help text for submitting issues.

Dear "Someone": Please make a CVS application process that incorporates or uses the issue queue and make it easy to use. Thanks!

I totally agree that we should move to an issue based system.

However, this needs to be implemented. Volunteers?

I thought we already decided on "Someone" doing it :)

I am ok with such a change, but I think we should wait for ajk's opinion too.

I've been in favor of a queue for any new project node being created. This can be with actual project nodes or a new issue queue. Users contributing for the first time indicate that they will need approved CVS access. This also solves our problem with people that had a valid first project but then start creating duplicate modules. It will force people to actually think about their modules and themes before committing and will also allow us to review for GPL violations or security holes before publishing the project as well.

I would volunteer to be a part of any kind of project review process.

Heine posted an RFP for review of new projects in the forums at http://drupal.org/node/484034 - fwiw I agree with this and would be interested in helping code review new projects. The hope is that public review of these before they get releases could take some of the firefighting weight off the security team - since there's no problem with having security holes in an unreleased project discussed publically - which means more people can be involved, and it'd cut out the overhead of sending out SAs for things which get caught at that stage rather than later - it's only likely to cut out obvious XSS and SQL injection issues with new modules, but there's plenty of those.

If it'd also ease some of the weight of the CVS applications process then this seems like it'd help in two places where people are very overstretched.

Speaking as one of those waiting for a cvs account currently, it would seem to me that the biggest problem is that reviews of new modules are quite a bottleneck with only one or two people taking part in them?

Although I can see advantages in having some early reviews through the issue system, I can still see that once it gets to the cvs application stage there will still be a bottleneck of needing a formal review?

Would it be possible to recruit more experienced devs to the review process? If there were 10 devs who commited to 1 review a week then surely that would ease the backlog somewhat?

Matt

Oops, accidentally changed Michelle's priority :( bumping back to critical... appologies...

Matt

Ah, ok, that's fair enough then :)

Matt

Sorry for the late arrival to this issue, I've been on vacation (as you all noticed!). I've been discussing this with Gerhard on IRC and I'll post more on this and our ideas later today when I have time for a longer reply. Just adding this note to subscribe to the issue.

Thanks for everyones patience :)

Having read this issue now and discussed with Gerhard on IRC the logical solution, as previous said, is to use
an issue queue. To that end I propose:-

1. Create a project with an issue tracker to handle cvs applications (already done [1])
2. Modify drupalorg.module so that new applications auto-magically create an issue in that queue when a new applicant applies
3. The current standard email reply to the applicant should instruct them to upload their new proposed module to that newly created issue.

Once the issue exists the workflow will be much the same as it is now in that I'll review, etc, etc. However, with an issue queue in place and a decent workflow (rather than the ML) we'll be able to start growing the CVS applications "team" in much the same way other areas of Drupal are managed on more of a community effort as opposed to the rather cliquey and cumbersome ML method. Over time I'd hope more people would be attracted to the applications process than exist right now (which is somewhat bottlenecked to say the least).

Additionally, the issue queue method will allow people to look at previous review comments as a sort of FAQ. Right now, unless you go digging in the ML archives all these reviews I do are rarely seen by anyone other than the applicant. There's often a lot of useful feedback that others would benefit from.

If people think this is a good idea then I'm happy to work on the mods for drupalorg.module to make this happen.

With regards to the current mailing list (cvs-applications). It current serves two functions.

1. Notify when new applicants apply
2. Used as the focus for the "Problems with CVS accounts" contact form.

It's my opinion that the issue queue will replace the former and realistically the latter is a request for support. Support really should be sough from the normal channels (forums, dev ML, etc) rather than the overworked CVS team. So I would recommend that the CVS apps ML should be retired completely.

[1] http://drupal.org/project/issues/cvsapplications

Sounds great to me, too. However, this isn't a bug, per se. ;) The less we have to rely on crazy code in cvs.module for CVS applications, the better. That'll make it easier to ditch cvs.module entirely in favor of version control API. Thanks for working on this, AjK. If I wasn't so slammed, I'd offer to help. That said, if you run into trouble and need something, let me know and I'll see what I can do.

Cheers,
-Derek

dww, thanks for the comments. I'm not sure at this time what the situation is with moving towards the version control API is.

Since this is highly d.o specific requirement, I initially worked on a patch to drupalorg.module that hooks into all the various parts of the process to implement what's needed. Not sure if this is the way to go but this patch works on my hastily built test server.

The patch is pretty basic and a starting point. If we choose to do it this way then the patch would need a review (Gerhard?) and then a test on scratch.d.o

Anyway, here it is to start the ball rolling at least.

Note, in addition to the patch some of the CVS admin email strings need altering to use %cvs-project-issue to provide links in the outgoing emails back to the project issue created automatically. This is just a config change to cvslog module settings.

For the record, Gerhard reviewed it and apart from the obvious typo (doh) has commited it to d6.drupal.org (the scratch site). I tested it there and it did what it says on the tin. However, d6.drupal.org is prevented from sending emails so that bit not tested. The emails on my test rig were fine.

Gerhard was ok to commit and apply for drupal.org but I said to wait until we get further feedback on this issue.

No time to review the patch now, but sounds like it's on the right track. One quick thought: it'd be nice to encode the config changes into a drupalorg_update_N() schema update, if that's not too much of a PITA.

Here's the latest patch. This addresses:-

• Fixes silly typo spotted by Gerhard.
• Fixes the access control to the overridden menu item.
• Makes more use of variable_get() for the initial project issue values so they can be altered more easily by settings.php
• Addresses dww's request to encode the configuration changes into an drupalorg_update_N() function.

For Gerhard's benefit, the NID on http://d6.drupal.org for define DRUPALORG_CVS_APP_PROJECT_NID is 367050 rather than 525912

And here's the new text for http://drupal.org/node/59

Appreciate this being checked by the documentation team.

Ok, this is now committed to CVS.
tagging

code is deployed on d.o and the update is run.

yay!

Great, then this doesn't need d.o deployment anymore... ;) Thanks folks. Hope it all works out nicely.