Posted by gdd on February 26, 2009 at 10:31pm
The services maintainers will be holding a code sprint on Saturday, March 7 at Drupalcon, as part of the greater code sprint scheduled for that day. I am hoping to take an axe to the issue queue and clean things up there, and I know there will be some discussion of future plans for authentication and oAuth as well. If you will be at Drupalcon and are interested in Services, please come feel free to come by and lend a hand, or hands, on your keyboard :) I'm sure there will be plenty to do. I don't know how the space will be setup, but we'll probably just set a sign out on our table and get to work.
Hope to see some of you there.
Categories: drupalcon sprint services drupalcon2009
Comments
Git for the sprint?
Hi everybody,
I've set up a public github mirror of the services module for my work on oauth and resource-based services support. Would it be possible to do the sprint using git?
Cheers
/Hugo
...forgot links
http://github.com/hugowetterberg/services
Current DRUPAL-6--1:
http://github.com/hugowetterberg/services/tree/DRUPAL-6--1
OAuth (pluggable authentication) support:
http://github.com/hugowetterberg/services/tree/oauth
Resource based services-support:
http://github.com/hugowetterberg/services/tree/oauth-rest
I agree - and also - would
I agree - and also - would it be possible to set up an IRC-channel for those that's not participating in Drupalcon DC so that we can join in on the sprint anyway?
IRC and git
I see no reason why we can't set up on irc channel for the services sprint. We will share the channel as soon as we can agree a name but I'll through out #drupalcon-services.
Using GIT sounds fine in principle but we may need a quick walk through of commands etc as I'm not sure how many people on the sprint have git experience (I know I don't ;)).
ourfernie
ourfernie
examiner.com
We are definitely there...
It seems like every single project we do these days requires Services, so we will definitely push at least two of our devs to help out with this...
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Right on
drupalcon-services sounds good to me. If people want to use git that's fine, but my whole dev environment is set up and running around CVS and I want to be able to crank crank crank without learning something new. But I won't stop you from doing what works for you! :)
Sharing code
Is the plan to patch and then review locally/via the services issue queue and then submit to the services project? Or do we plan to set up a repository of some form to share between devs and then commit once we have a patches we comfortable with? Maybe one to discuss before saturday so as we can share here before the big day ;)
ourfernie
ourfernie
examiner.com
Unsure
I'm not sure. I love the idea of using the issue queue for everything, because it maximizes transparency and provides an open log of every change and the reasons behind it. It does seem a little silly given that pretty much everyone actively involved in Services will be present, but it also pushes everyone towards patches that are single-purpose and well-defined. Also, it looks like we will have at least 7 people, so if someone gets tired of hacking out patches, they could move into the queue and review, and vice versa. I know that for myself, reviewing and cleaning up the existing queue will be a high priority so I'll probably be in there a lot anyways.
So I guess I'd like to use the issue queue, even though it will slow things down a little.
Any other comments?
My workflow
After cloning the common repo:
$ git clone url://to.common/repo/services
$ cd services
My workflow per patch could be something like this:
Create branch for the ticket, starting off at the DRUPAL-6--1 branch:
$ git checkout -b fix_to_something origin/DRUPAL-6--1
Do something in file.a.php...
Add the change:
$ git add file.a.php
Commit:
$ git commit -m "Made change X in file.a.php"
Do some changes in several files...
Add the changes:
$ git add .
Commit:
$ git commit -m "Made change Y"
Push my branch to the common repo:
$ git push origin fix_to_something
The pushing can be done as often as you like, and it's the point when you publish your work to other people, commits are always local.
Create a diff that CVS groks:
$ git diff -p --no-prefix origin/DRUPAL-6--1 fix_to_something > ~/sprintpatches/0001-fix_to_something.diff
...and create a issue for it
Github does a pretty neat job visualizing the work being done on branches across several users' repos. http://github.com/pieter/gitx/network
I'm in as well.
I'm in as well.
Room 142
Services guys are sprinting in Room 142! Come on bye and/or join #drupalcon-services on freenode.