Git and Drupal Core workflow
This are just some random ideas about how we could organize drupal core development when/if it would be powered by git.
Every (core) dev can request a personal git repo for drupal development. Here he can push his stuff too, in a special layout.
The branches are named after issues the dev is assigned to. The base for them is the current HEAD (it's left to the dev pulling it in before starting his work!). Then the dev develops his patch. Whenever needed, he pulls the current HEAD in. When he's done with his patch, he uses a special tag name, and the magic starts:
The latest HEAD commit which was pulled into the issue specific branch is detected.
A patch is created against the detected HEAD.
The Issue the patch is for is updated with a link to the repo, the patch and the tag message. The status of the issue is set to code needs review.
The patch is tested by the testing bot, and issue status is updated accordingly.
The patch is reviewed, reroll requested etc.
The dev now just modifies his branch and then tags with another magical tag, and the issue is updated again... etc. When the code was comitted to HEAD, we could even auto-delete the branch of the developer (if it's in the same state as it was when the last patch was created). For retaining the patch development history, better annotating of HEAD etc, the comitters of HEAD use git pull to get the code, the patch is there to make it easier for other people to review code.
That's it for now, I'm interested what you'd think about this!
sounds interesting
I wouldn't have thought of auto-integrating the commit workflow that deeply into issue queues. It might take a bit of thought to make sure that only changes are pushed to the issue queue that the developer wants to have actively reviewed, but the idea might have its merits. But it's only cool if standard "non-magic" patches can still be done without further hoops. The part where the HEAD commit is auto-merged back into the issue repo sounds to me like it might break easily, there needs to be a lot of thought to make that happen.
missing anything?
I was thinking about that, and the benefits of this proposed new workflow are two:
This is a simple task using git.
I know automating tasks makes all simpler, but I really do not get the real benefit of these changes. Please do not misunderstand me, I'm really a pro git, but I think the DVCS natural way works exactly in the same way.
Also, IMHO one of the great DVCS strengths is own public repos, that make really easy to collaborating through patches. I mean, you can work pointing to 3 developers public repos for issue A, 2 others for issue B, etc. And, ATM, I do not see these integrated on issue queue workflow
Projects like git itself and linux use the dev mailing list for patches interchange, but here issues seems like the drupal place I'll propose.
If I miss anything, please correct me ;-)b
I think something like this
I think something like this would be just the logical continuation of what we already have for contrib/ - releases which are dependant by some VCS settings. For core, we have atm two different workflows:
a) big stuff, like DBTNG etc:
create an external svn repo, give the important contributors an account there, when done, create a huge patch - all commit history is lost.
b) the rest
A dev creates a patch at home however he likes. Doing stuff together is not really possible, at least in no paralell way, it has to be serialized by the issue tracker, and I don't think that there are many patches with more than one main dev.
With some sort of integration into d.o, we could
a) keep the commit history, giving better credit when there are multiple people, etc.
b) when not using developer specific repos, but maybe kind of per issue-repos (there would be lots of repos, though, not really handy I think) then contributing to a patch would be as simple as hitting a button on the issue tracker (aka "let me help here") and one would get commit access, so one can collaborate with the other devs trying to resolve the issue as fast possible. Sure, this doesn't replace irc meetings to get things coordinated and to not duplicate work.
it's more clear now
I see three alternatives that solve the problems(keep commit history and let work together):
Here there is some which branch do I have to rebase/merge problems, but doable.
Repositories are not really cheap, and because of the number of issues maybe this is not a really good idea. But it lets make it simple where to push, but there would be moderating work(some way of ban some not helping commiters, I'm really not sure is this should be necessary).
This is really cheap, but I'm not sure if we can restrict access per branch (I suppose we can do it from git hooks :D). This alternative the one that more convince myself.
what option do you prefer(maybe not listed)?
I'm unsure if we want either
I'm unsure if we want either 2 or 3:
For 2 speaks, that we can easily restrict access to the developers how signed up on the issue, it's clear where the stuff is developed, no long list of branches in the online-viewer.
Against 2:
We'd need to set up a repo for every Drupal 7 issue up where the developer requests this (so we can leave out discussion-only and won't fix etc issues).
For 3:
access based on branches is probably possible, same as 2 then.
Against 3:
I'm not sure how we handle that the developer doesn't get every damn branch in this huge issue-repo but just the branch he's working on. Also we'd need to keep this repo's master in sync with HEAD, this would allow the developers to just pull from the origin repo's master branch to chase HEAD for their patch.
Given this, if 3 is somehow possible without cloning all issues with which is dealt with atm i'd prefer 3, else probably 2.