Out of interest, which parts of the build process rely on svn? I couldn’t see anything stand out when I looked.
The case for moving Yii 1.X to github is simple: Just because Yii2.0 is coming out doesn’t mean the thousands of sites running Yii1.X are going to switch over night, it’s likely that minor changes and fixes to the 1.X branch will be required for at least the next 2 years. Moving to github means that the burden on the core team is lessened, as it will be much easier for people still relying on 1.X to collaborate and fix issues together. Also, if you’re moving to github anyway, why have 2 separate systems? The pain of switching now is worth the long term reward.
As Alex said, we will host yii2 on github. We are still not sure if we should move 1.x to github. One major thing is about auto-expansion of tokens such as $Id$. The translation team relies on this timestamp to make sure their translation is up to date. Git doesn’t support this.
Below are my responses to your arguments. Please let us know your thoughts. We are not experienced in github, and would like to learn more from you.
It encourages openness, work on features can be done on separate branches in public view and then merged in with the main branch, this makes code review a lot easier.
For 1.x, we will develop only very few new features.
Allows people outside of the core team to review commits, comment on designs etc in the same place as the code, making discussion a lot easier (you don’t have to go open a new issue on google code or create a forum thread to discuss something)
For Google code, you can review/comment on commits too. You don’t need to create new tickets for this.
Allows people outside of the core team to submit pull requests for features and fixes. I know google code allows this as well, but the process of creating and submitting patches is pretty horrible compared to the github workflow.
Agree on this. But again, for 1.x, we won’t develop many new features or massively touch many files (mainly for code stability reason). So submitting patches should be fine.
Many eyes are watching. Because it’s easier to see individual features being implemented, it’s much more likely that bugs and limitations will be found before they’re merged with live.
[b]
[/b]
This is similar to point 2. I don’t see google code is limiting on this aspect.
Move faster. It’s much easier for people on git to keep up with bleeding edge latest code, and therefore find and fix possible bugs much faster. It also means that the framework could eventually switch to a continuous release schedule, rather than having months between releases.
[b]
[/b]
Could you explain a bit more in details about this?
All the cool kids are doing it. A lot of other open source projects have already moved to github, so most developers are familiar with it already.
We’re using SVN subrepos in yiidoc project. Git submodules aren’t intuitive to work with so I’m afraid translation teams would be confused.
We’re using SVN id tags to version original translations. Git doesn’t have sequential ids so it can be a problem when finding out version differences. For Yii2 the plan is to create a kind of translation UI.
I agree that switching now can be a good move and certainly will help us. The problem is that right now we’re too busy with Yii2.
While git does support injecting the hash of the current commit into the file in a similar way to $id$, this is also something that could be accomplished via a task in the build process or by using git’s tags feature.
Very few new features perhaps, but there are large number of open bugs / issues for this version, there are likely to be more uncovered, why not encourage the community to collaborate and help solve these problems?
Right, it’s possible to do a lot of this stuff via Google Code, but where github excels is in encouraging this participation, github assumes that you want to contribute and reduces the barriers to doing so, see “fork and edit this file” etc.
Again, this is simply a matter of encouraging people to submit patches and reducing the overhead of doing so. With git, you’ve likely already cloned the repository, so when it comes to finding and fixing a bug, it’s just a matter of making your change, committing it and making a pull request on the main Yii repository. You’d probably have committed your change anyway, so this extra step of making a pull request requires very little effort, it’s a matter of a couple of clicks in github. How many people have found and fixed bugs in the existing site and NOT submitted patches because they don’t know how or it’s too much effort etc? I’d wager quite a few, we need to do our best to make this process easy if we want to get those contributions.
This isn’t a github vs google code issue but more a git vs svn issue. With svn you generally work on a feature for a few days or weeks and do a big commit, hoping that you can resolve any merge errors that crop up. This is because when you commit, your code is basically “live” as svn has poor support for branches. This means you’re on your own, designing things without feedback until you merge. In git you’re encouraged to commit much more frequently in a separate feature branch, and then make a pull request to the main branch when the feature is ready. This means your feature branch can be public, visible to scrutiny from your first commit without breaking the rest of the application, and you can collaborate with others in this feature branch.
Because of the use of feature branches, the code in the master branch can be considered “authoritative”. A feature only gets merged with the master branch when it works and has been tested thoroughly. So you can develop a feature, test it, merge it and get it in the master branch, and as soon as it’s there it’s ready for public consumption. You don’t need to wait for a certain number of other changes and bundle them as part of a new version, developers who want to stay up to date can just do a git pull and get the latest code.
Well, I’m not saying we should do it just because they are. What I’m saying is that since this topic was first brought up around a year ago, git has surged in popularity. It’s by far the fastest growing version control system. Github is familiar to developers, they’re already used to using it because of the large number of other projects using it. No one will be adversely affected by the move, it only brings benefits. The only effort is in the initial transfer to git and getting used to a new workflow, which is something that the core team have to do as part of Yii 2.0 anyway. Also perhaps it’s good to do this now so that when 2.0 code becomes available the core team will already be used to the new platform / workflow.
Ok, so what if me and some co-conspirators put together an exact, step by step guide on how to do the transition to git and github, is it worth our time? Git submodules are actually pretty simple when you get used to them, we could cover that as part of the guide.
There may be an easy workaround for the translation problem. As far as i know, the $Id$ does not have to be incremental. It only has to be unique. And it’s not necessary to have it in the repo - it’s sufficient if it’s available after some translator checked out a branch.
Thank you for offering help. There’s one more thing we should consider before we choose to migrate to github.
We should find a way to synchronize between google code and github. That is, the google code will remain as a read-only repository for people who rely on it.
It’s not practical to force people to switch to git for Yii 1.1. The synchronization doesn’t have to be in real time. It can be done once every day. Any thoughts?
Github aside, the solution to maintaining 1.x and current versions might be handled better by forming a sustaining development group like a few other open source projects (e.g., Joomla). Then the core development group can always focus on the next generation version with some mentoring support for the sustaining group.
Job done! Thank you all for the reminder and suggestions. All existing open issues are imported in github. They are a bit messy though because they don’t get any labels or milestones. We will solve this gradually.
