Welcome
Welcome to the brainstorming group for the 2014 Drupal.org roadmap! This group is to help the Drupal.org Software Working Group gather community input into the 2014 budget and plans for Drupal.org improvements. Please read the announcement for more background/details.
Latest ideas Most popular Recent Comments
To participate:
- Review the list of submitted proposals and "vote up" and/or comment on ones that speak to you.
- If you don't see your idea reflected, propose your own ideas using the idea template.
- While we want to hear about everything that's on your mind, we're especially interested in small, but impactful ideas.
- Proposals are wiki pages, so feel free to provide additional details in other peoples' proposals; think of them as "issue summaries" for ideas, so keep them neutral.
Voting/feedback will considered until 00:00 GMT on September 6, 2013, in order to give us ample time to make a proposal (which the results here will be a part of) for the Drupal Association Board Retreat prior to DrupalCon Prague. Thanks for participating!
Subscribe with RSS 
Recent comments
Those interested in this
Those interested in this subject, who are attending DrupalCon LA, may want to attend this session.
https://events.drupal.org/losangeles2015/sessions/issue-workspaces-bette...
"In the past few years there were numerous conversations in the community about the need to improve issue queues and Git workflow on Drupal.org. Suggestions ranged from implementing pull requests to migrating to a different self-hosted solution, such as GitLab, or 3rd-party site, such as GitHub. Meanwhile, new technical solutions have emerged for some of the challenges we are facing. One of them is issue workspaces."
git workspaces
I would recommend attending https://events.drupal.org/losangeles2015/sessions/issue-workspaces-bette... which should have an update for how the DA staff plans to tackle this.
I'll be there. If there's a
I'll be there. If there's a BoF I'll attend.
Drupalcon BoF
Would anyone in this thread be interested in attending a DrupalCon BoF session?
I would love to get something more concrete started as well as enlist a group of people able to bring something like this to fruition.
Good point, GitLab would motivate me
Integrating with GitLab would motivate me much, much more than Github. Github is way too proprietary and I feel it goes against what Drupal stands for.
Here is a GitLab podcast from November 4th that I am listening to right now and it is very promising!
http://pcasts.in/Ni32
Gitlab podcast Nov 4th
I am listening to this now and recommend having a listen. Gitlab has over 300 contributers so far and works very hard on growing their community.
http://pcasts.in/Ni32
I am against disabling the
I am against disabling the forum. A better option would be to improve it (with contrib modules or by adding features into core). Also we could improve SEO at least for the next threads. A voting system is absolutely necessary.
DrupalCI project is moving
DrupalCI project is moving along slowly and will eventually let us run composer install during test runs. Just wanted to leave a breadcrumb for anyone who lands here from the future.
My bad. I was misreading
My bad. I was misreading Gitlab as Github. I agree that integrating a complete system within Drupal.org would be a good move, particularly as it's almost impossible to do development for Drupal.org unless you are in the inner-circle.
Gitlab is self hosted just
Gitlab is self hosted just like the cgit or whatever drupal is currently using. They have a hosted version too but you can run your own local copy.
Using a standard or existing solution follows with d8's motto of using what's already available rather than having to build and maintain it all yourself.
Gitlab is a perfect example of a tool we could use. It's supported, feature rich and open to customization as required.
As has been repeated many
As has been repeated many times in this thread, moving Drupal GIT to a 3rd party service is a bad idea, and it's very doubtful you will ever get a consensus agreeing to do so. Time will be much better spent focusing on improving the Drupal infrastructure to implement the positive functions from Github into Drupal's infrastructure, rather than talking about moving to Github which will almost definitely never happen.
gitlab guys
I spoke to the gitlab guys in the beginning of this year and they are open to help us in any way they can, but I guess we can already solve most thing with what is already available
Seems like an easy problem to
Seems like an easy problem to fix. Sort of like user deletion option in Drupal, "Remove user, but keep all content." WE could simply tie user accounts to d.o and when an account is deleted, simply change the namespace of their fork to anonymous or some random hash to avoid name conflicts.
I asked the same thing to
I asked the same thing to webchick when she was here for DrupalCamp Ottawa. The problem with that is if the owner of the fork disappears all the work in the repo could be lost, stuff like that. Instead of having it all in the current repo where the module maintainer can keep track.
But yeah it would be nice to use.
A Forking Model
Could we not make all repos public (Drupal requires all modules posted to it to be open-source anyway) and simply follow a forking model? I imagine it would look something like this: A forks the module and creates a topic branch (this could probably be automated), does some work, then submits a pull request (akin to a patch now) and the PR is posted and linked in the issue. Now B can review the PR. If it needs work, B can fork the module repo themselves, add A as another remote and then merge the branch of A into a topic branch in B's repo. Finally, B submits a new PR and closes A's.
This is superior to the patch model in that commit histories can better be fully maintained, while taking advantage of proper commit message standards. Plus, PRs can quickly be updated to apply to the latest module code by rebasing them onto the latest work. Currently, patches quickly become stale and in a large fast moving module, patches need to be rerolled many times.
This also falls nicely in line with Dries' Amsterdam proposal because we can come up with a really clean and concise means of attribution if we have all the space that a full commit message offers over the one liners that are standard today.
Well I know we can tie it to
Well I know we can tie it to drupal for some of the workflow required. We built a tool for people to package and release private modules against both github and Gitlab.
http://dropfort.com
Not done yet but core functionality works.
The issue queue API we haven't played with yet but it's on the roadmap.
I know you can set the protected branch stuff through the API and create branches. The initial repo config you can't get through the api but I'm sure that's a feature can get made. Also making commits through the api doesn't work yet. But they recently added a lot of nice api calls fire dealing with tags and labels for issues.
Works pretty well actually.
I should have been more
Sorry, my bad, I should have been more clear, I'm really all for this and have already given GitLab a try. Now I'm just wondering what steps we could take that would move this more toward taking a decision. Be it demoing that we can tie GitLab into a Drupal site, or actually working with the GitLab guys to discuss some of the features we need etc.
Gitlab.com is free and you
Gitlab.com is free and you can try out all the features.
Proof of Concept
Is there a way that we could demo this or take some concrete action in this direction?
Gitlab also has the concept
Gitlab also has the concept of protected branches. Where only the repo master or owner can commit to them. But keep the release branches locked.
Maybe use issues branches, let people push/pull to them and when the code is good the project owner just has to merge it in.
Just a thought.
Here's a breakdown of the permissions.
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/permissions/perm...