github/collective experiment - status report

Git is not hard to learn

What surprised me the most is that there were no bigger complains about people using git. I've talked with a lot of developers over IRC and asking them about their experience with git. Its also true that most developers who joined were already familiar with git, but they are quite some git newbies, who just joined from curiosity about git and Github.

So next time someone coming from SVN world tries to convince you that git is hard to use, please point them to this snippet of .bash_profile:

alias svn-up="git pull"
alias svn-st="git status"
alias svn-ci="git commit -av && git push"

Nobody is forcing you use git-rebase, git-stash, git-send-email and other cool features git gives you possibility to use. You can still use git as you did SVN.

Github permissions are just not ready for us

As much as I was enthusiastic about Github, there are quite some limitation that does not meet our needs. Especially there is a big lack of different permission. Github only implements some basic permissions and leaves everything else for you to setup by hand or via their API.

Right now we have a strange bug that after you fork repository to Github/collective you actually lose the right to administer it. So in case you want to change title or description you just can't do that... well you write me and I do it for you. This is definitely something I wouldn't like to do on daily basis. This is because of current setup of permissions. I won't explain here how I setup permissions, I can just say I tried a lot of scenarios and lots of hours went into testing how Github actually works.

The only option that Github also promotes is that you create external script and manager groups/users/permission via their API. This would actually solve problems, but I'm not volunteering to do it. I believe Github should be that flexible that it should allow us to connect our LDAP and fed it with users.

I didn't really say nothing nice about Github. Even with all the above mentioned problems I still believe it is the best tool to use right now. So I would guess we are using it wrong.

Where to go in the future

And yes we are using it wrong. Github is already one freaking big collective. Just as Ploners we are not that interested in other projects. What svn/collective is giving us is one common place to put our code related to Plone for other people to reuse it. Meaning, if you don't put something in svn/collective your code does not exists in Plone world.

Now I would like current collective to evolve a little bit. In sense that I want other to see my commits of my Plone related projects in collective-cvs list. I'm not proposing to extend only to Github, but also to other (D)VCS providers. Actually you could put in also your company public svn repositories. Now this is a thing I'm willing to commit to and work on it.

In sense, just like we have planet.plone.org we could also have collective-planet.plone.org.

And what with happen with github/collective?

Now we definitely should not keep it in a state that its now. We created Github/collective also with intention to give projects, that overcome only personal usage and are becoming important part of others as well, a home. I would even go further. Projects that want to be included into Github/collective will have to commit to some design pattern, have testing, documentation and will be generally adopted by Plone community. Now with this base its easy to setup Jenkins and run tests on daily basis.

Plone moving to DCVS?

Now this is a topic I get asked a lot. No Plone is not moving to Github. Now that said I hope we could start some discussion to move from SVN to some DCVS. I said start talking more about it, not actually doing it.

One of the reason is that its impossible to mirror SVN->DCVS_ way, but its possible the other way around. It would be also nice to provide mirroring infrastructure to mirror code to services like Github, Bitbucket.

I was also asked how would DCVS impact us from legal point of view. Since we only accept contribution from developers who signed Agreement. I think best would be to give you a practical example in cronological order:

• Plone switches to git
• Plone is also mirroring repositories to Github/Bitbucket
• Adam sends Pull request over Github.
• Plone developers watching this mirror advices him via freaking nice Github comments to sign an Agreement and pull changes by himself.
• Since Bitbucket doesn't support Pull request Eva sends an email on plone-devel list saying that she have some interesting features.
• Plone developers again advise to first sign an Agreement and then pull in her changes by herself.
• Adam and Eva lived happily ever after in their paradises

We wont benefit all from this. People who like that SVN way of working will continue to work that way (see aliases above). But instead of forcing some way of contribution (even if its the most liberal one) we are opening to more developers by letting developers use their way of working.

Fire away ... :P