@sdboyer brought up today that we don't necessarily have a plan as to what to do with the current CVS applications when the Git switch gets pulled.

The following is what @sdboyer threw out in IRC.

  1. move all issues out of cvs applications and into project applications
  2. tag all such issues "former cvs applications" for clarity
  3. unpublish cvs applications.

Heres a little more involved version of what I think.

  1. Update documentation about application process. Archive old documentation. Need to combine current docs with new set of docs.
  2. Add comment to all current CVS Applications describing change and linking to relevant documents. This can probably happen soon, actually.
  3. Offer choice of just using sandbox or continuing Project Release application. This could really reduce number of applications as some people just want to put their code somewhere.
  4. Move all issues out of CVS Applications and into new Project Application issue queue.
  5. Tag all such issues "former cvs applications" for clarity and searchability.

We could be a little more deliberate about the change and have everyone explicitly start a sandbox to continue their application. This may be important since we will need this people to agree to new terms and upload a ssh key.

  1. Update docs ...
  2. Add comment to all current CVS Applications about the change.
  3. Have all current CVS Applications put their project in a sandbox, and have them move their issue into the Project Application queue. This would really ensure that only people that want to continue their application will get moved over.
  4. Mark the one that have been migrated.
  5. Continue as usual.

So, what do you think. We basically have a week to decide and execute this.

Comments

brianV’s picture

We have 450 open CVS applications, so whatever we decide to do, it will take someone several days worth of effort to update them all with the proper comments... although I guess it could be done programatically.

I personally like the idea of having current applicants put their code into the sandbox prior to continuing (if they wish to get full project access). That will make things simpler, I think, for full project application reviewers to review the code, as it will be in the sandbox in a similar fashion to every other non-migrated full project review. Plus, this gives the applicants a chance to get up to speed with git in the sandbox, before we set them loose in the more public-facing full project repositories.

apaderno’s picture

Between the CVS applications, there are also applications that are marked as needs work, and that didn't get any reply back from the OP; those should be probably be closed as won't fix.

rfay’s picture

There is actually no change in the process except the name of the thing changes. So we don't actually have to do anything differently (except to change the content type).

If someone with privs has time, it's reasonable to take this opportunity to clean up.

Of course, we should try to fix all RTBC or near RTBC applications and get them out of the way this week.

zzolo’s picture

Hi @rfay. I would argue that there is actually some key differences in the processes that need to be addressed. Yes, the content of the applications will remain the same, but the details in process are different. Please see new workflow for difference.

1) The current CVS applications are done by attached modules zipped up. But the new process is simply pointing to a Drupal Git repo.
2) The new process for Full Project access assumes that someone has already started a sandbox with Git (therefore agreeing to new terms and uploading ssh key).
3) And most importantly, in my mind, is communicating to these people about this huge change in what is going on and expectations.

Definitely agree if the process includes going through all current CVS apps, then might as well clean up some.

zzolo’s picture

Thinking about this some.

We HAVE to have these people put their project in a sandbox. This means agreeing to new terms and uploading ssh key. This could be a crazy new process for these people.

I would suggest that we start telling people now about this change coming up and pointing them to documents to the new Git system (which are awesome, btw). This has lots of benefits for everyone:

  • people learn the new system
  • the queue gets managed
  • we will actually be able to administer these requests
  • applications get migrated by users themselves
  • this is also a great opportunity to let them know how we think this will actually make the application process more efficient

In this plan, we simply need to write up a comment with instructions to put on all current CVS applications.

vertikal.dk’s picture

I'm one of the new CVS applicants caught in the void between CVS and Git, and I personally think that it would be appropriate to have the applicants start anew in a Git sandbox and apply for a promotion to a "real" project under Git.

Sure enough, the process of setting up Git locally as well as on the Drupal site isn't trivial, but since all future projects are going to be done with Git, we applicants have to go through the process anyway.

I have been waiting for things to happen with my project for 1½ month, and I would welcome the move and hopefully some progress in the application handling.

A general message with some short instructions under each issue and closing the issue would be one way of going about it. Some projects are pretty far in development and close to being accepted as projects, and the people who handle the individual projects can probably estimate whether they are mature enough to become full projects under Git.

If anybody handling this need some feedback on instructions and process for this transition from someone who has never worked with CVS nor Git, but a lot with Drupal, feel free to contact me, and I will do my best to help shape it so that newcomers to Git and contributing to Drupal have a chance of understanding it.

Martin

bfroehle’s picture

@zzolo: Rather than posting a long and detailed comment on each current CVS Application, I think the comment could be shorter and link to a documentation page. This gives the flexibility of refining the instructions if there are ambiguities.

I agree that new maintainer issues should be moved to the Project Applications queue, tagged with 'former cvs applications' (or even add that as a component?), and marked as 'needs work'.

In general, the message should be:

  • The Git Migration has occurred and the corresponding project application process has changed.
  • This change requires action on your part. You will need to:
    1. Configure yourself for Git access (check the box, upload ssh keys, etc).
    2. Create a sandbox project for your proposed module and upload the code to the git repository.
    3. (Verify that your code was uploaded properly.)
    4. Post a link in this issue to your sandbox project, change the status to 'needs review', remove the 'former cvs applications' tag (or re-categorize as project application)

Some text to the effect of "we hope this will allow for a faster and easier project review" woud be welcome news to those who have been languishing in the queue for weeks.

Is the process for co-maintainer applications changing?

Lastly, I second the suggestions of @rfay and @kaimlaluno to fix current RTBC issues and mark those stuck in 'needs work' as 'closed (won't fix)'.

webchick’s picture

Issue tags: +git phase 2, +git sprint 10

Tagging.

fleetcommand’s picture

It's interesting, since I'm also one of the CVS appliciants, and I was wondering what was going to happen with the CVS applications after the Great Git Migration happens, so I found this issue :)

For some longer pending appliciants it may be a little strange, I still support the second recommended method so everyone would put their code into a sandbox then apply for having a full project permission. This needs a little work from their (our) part, but everything is much more clearer that way. And, one day everyone would have to set up Git anyway... :)

zzolo’s picture

My apologies. I meant to do this this week and things just have been extremely busy. On Sunday, I am going to move forward with the plan of updating all the current CVS applications with following information (filled out a bit and with many links) (mostly taken from @bfroehle comment). And will clean up issues as I go.

  • Overall explanation of the change.
  • What it means specifically for CVS applications, ie Sandboxes, full projects, possible benefits for application process.
  • Instructions on how to get started with Drupal Git (mostly links).
  • How to move your application to new queue (if desired).

I don't have time at the moment to write out completely what my comment will be, but if you feel you want to review it before I start this process, please let me know.

(Please note that documentation will need to be moved around and updated. This can live in this issue or in another.)

Also, great work to the whole Git team. I haven't actually tested anything out yet, but I know how hard everyone has worked on this and am really excited for the change.

zzolo’s picture

So, I have created a new hand book page to describe the change for CVS applicants: http://drupal.org/node/1075406

Now to go through all the apps....

zzolo’s picture

This is the comment that I am adding to all current CVS applications, and marking their status as decribed in comment:

Hi. Please read all the following and the links provided as this is very important information about your CVS Application:

Drupal.org has moved from CVS to Git! This is a very significant change for the Drupal community and for your application. Please read the following documentation on how this affects and benefits you and the application process:
Migrating from CVS Applications to (Git) Full Project Applications

  • The status of this application will be put to "postponed" and by following the instructions in the above link, you will be able to reopen it.
  • Or if your application has been "needs work" for more than 5 weeks, your application will be marked as "closed (won't fix)". You can still reopen it, by reading the instructions above.
zzolo’s picture

http://drupal.org/project/issues/cvsapplications?categories=All
All of the open tickets have been updated. Many thanks to @arienk and @kiamlaluno for the help.

Next steps:

  • Update documentation, specifically the CVS Application docs.
  • Determine how long we will let the CVS Applications queue live. Maybe like 5 weeks?
  • Update all CVS Applications issues with a note that says it will be closed.
  • Given X weeks, close the CVS Applications queue.
mlncn’s picture

People who already have RTBC applications should be told they can refer (link) to their old application for expedited processing. Let's get through the backlog as quickly as possible.

zzolo’s picture

Hi @mlncn. Theres been a little issue with the RTBC ones. I think they should just be approved. I am still figuring out if I have access to approve people still, and if so, how to do it.

chx’s picture

Just for posterity, what actually happened in here, #1 said we have 450 open, #11 said now go over all apps and then #13 three hours later is says all open tickets have been updated, did @ArianeK @kiamlaluno and @zzolo go over 450 issues in three hours?? If yes, then you guys need some serious community recognition.

apaderno’s picture

@zzolo: i think that to allow users to create a full project, you need to be able to edit the user profile. If that is the case, you need to be a site maintainer.

zzolo’s picture

Hey @chx. Yep, thats pretty much what happened. Couldn't have done it so well and quickly without help.

@kiamlaluno. Well, that seems like more access than I need or want, but would be fully capable of the responsibility if its the only way. (also, talking with @webchick about this now)

zzolo’s picture

Referring to be access, @webchick has given me temporary access but this needs to be addressed in the future: #1076332: "Git adminstrator" role does not have enough permissions to do their job

mlncn’s picture

zzolo+++++++++++++++++++

zzolo’s picture

Hey anyone know or have the ability to find issues that were RTBC within the past few days. I am not sure how to find the ones that were (accidentally) put to "postponed"?

apaderno’s picture

I checked again all the issues, and found 2-3 issues that were RTBC and marked by me as postponed; I granted to the users whom applied the permission to create full projects.
I also found some applications as co-maintainers, and reported what the users need to do in that case. I found a user who applied twice, and closed one of the applications as duplicate of the other one.

l@va’s picture

Still waiting for approval on my (formerly CVS) application. Do you feel the project is not yet ready (despite having been marked as RTBC for the past month), or were you having trouble finding it?

CVS Application: #994286: lavagolemking [lava]
Git Application: #1074792: MyTube
Sandbox: http://drupal.org/node/1074792

apaderno’s picture

@l@va: Your CVS application has been closed as duplicate as you already created a new application under the new queue.

rfay’s picture

@kiam, @zzolo It looks to me like l@va's should be approved automatically, as it was one of the ones that was RTBC before the switch, right?

apaderno’s picture

Dave Reid reported a possible security issue; let the issue be resolved.

l@va’s picture

I addressed the issue, and am waiting for a response.

eliza411’s picture

Status: Active » Fixed

It looks to me like the plan is in place, so I'm marking this closed. If I'm mistaken and this issue is still valuable, please re-open.

Status: Fixed » Closed (fixed)
Issue tags: -git phase 2, -git sprint 10

Automatically closed -- issue fixed for 2 weeks with no activity.