Wednesday, July 8. 2009More Info on Gitorious.orgToday at the Akademy General Meeting, it was mentioned that Gitorious.org is being seriously looked at as a hosting solution for our Git repositories (as opposed to running an instance of Gitorious ourselves). Since I have been a major part of pushing in that direction, I feel that it would be prudent to make sure that those interested are aware of the relevant discussion and the current status. So, for those interested, read on. Please note that this is not a post about why KDE is migrating to Git, why this is a good idea/bad idea/neutral idea, etc. This is purely discussing the hosting aspect of Git. First, I would encourage you to read this kde-scm-interest mail, which I sent to the list on July 2nd. It goes into a good amount of depth as to why Gitorious.org could be beneficial for us, and the rest of this post will assume that you have read that email and the others in the thread, as it will simply update the information therein. On Monday a large group of interested people, including KDE sysadmins and the guys from Shortcut AS, went to lunch to discuss the technical issues. The output from that discussion is as follows:
We have two projects that are chomping at the bit to get onto Git ASAP: Amarok and TagLib. Amarok will be converted first and will serve as the initial guinea pigs to iron out any issues. Barring any major issues being found, TagLib will be converted in short order. I hope this gives everyone a better idea of KDE's Git-hosting plans. If you haven't checked out Gitorious.org, I encourage you to do so; it's made huge leaps and bounds in the past six months and has become quite a great tool. Please direct any questions or feedback to the kde-scm-interest mailing list at: kde-scm-interest at kay dee eee dot ooo arr gee, not to the comments section on this blog. Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Using git (even more) is a good idea, being hosted in a capable site, even better.
Still, I see two misconceptions about git: First, you write as if you need to decide on /one/ main server. You don't need to, you could spread the hosting across multiple services. Second, about multiple commiters and rights. In git, the infrastructure is the social hierarchy, not some ACL. IMHO it is wisely chosen, against the 'everybody commits in the trunk' method.
Splitting trunk from one huge repository to more smaller ones (if that happens) would be a great thing. I havn't found much information on how this is planned though.
Yes, this is the plan. Thiago Maciera has done work on it...I don't have all the technical details but this is what we will be doing.
Regarding your first point, I think you missed this:
"Or to put it in a more general fashion, KDE can reduce hosting costs (which will likely be covered by sponsors) by working with Shortcut. It is not a question that this could be done, but rather what the right method would be for doing so." Regarding your second point, that is the plan -- to keep it as it is in Subversion, where approved developers are added to a kde-developers group that is the owner of the projects/repositories. This will make it easier for non-continuous developers to contribute though since they can clone the repo and send merge requests. The current system works well and there isn't much reason to change it.
What ever you guys decide, I'm sure you've done your homework, and the decision is the best for the community.
From a freelancing standpoint of only working on patches to be reviewed (and i like this way of working), I highly appreciate the switch to a distributed system with easy local branching.
Thanks! Yes, we are doing our homework, and we think this will be great for the community.
I love the idea. It makes KDE appear so much more open and I think Shortcut are doing a great service to FOSS. So they should be supported.
Clear win win. PS. I am not going to subscribe to a ML to answer this post
Agreed -- that's one reason I wrote the proposal pushing for the Gitorious.org hosting -- I feel it makes KDE development feel less of a "walled garden" and very open.
Gitorious is great software that is constantly improving. GitHub is trendy and seems to get all the press, but it's not open-source; in addition, having used both, it feels much less like you're working on a team effort, as it focuses much more on individual users. It's really not as community-friendly, despite calling itself "Social Coding" -- Gitorious.org is doing far more on that front, IMHO.
BTW -- For many mailing lists, you don't need to subscribe to send a comment...you just won't get replies unless people remember to CC you
Sounds interesting, I think that this will be a positive move for KDE. I would love to know more about the plans, and will be keeping an eye out. I hope that KDE is split into smaller repositories too.
One of the previous points is also true, with git the choice of where to host the main repository is less important. It is very easy to push it to another location. That said, I like what I have seen of gitorious and think that would be a great place to host the KDE repositories.
I or someone else will post more as we can. And yes, KDE will indeed be split into smaller repositories. Note that the transition will not come all at once, but various projects will probably migrate over as the developers and Thiago can coordinate (just as Amarok and TagLib will be doing first).
And yes -- if something really doesn't work out with Gitorious.org, everyone has a clone (plus KDE would be keeping clones of all of its repos on its own servers). It might be a pain to move everything, but it can be done.
Couldn't git submodules be used? So that, say, kdebase is split into small repositories, but then combined using git submodules.
Maybe. Some meta-repositories might be useful for build scripts. On the whole they're not really needed however.
Submodules also have their demons...Thiago knows more about it than I do, but they're not really a parallel of SVN externals.
1. How good does git work on windows or mac and where is the git-tortoise?
2. How to protect the history from drunken developers aka "I always need to be able to undo what I did yesterday evening"? 3. SVN does not care about files not added/committed. Git does and does NOT allow to checkout another branch if such files are still around. How to get right of them without "rm -rf * && reclone" (no, "reset --hard" and "stash" only handle added/committed files)?
1. Here: http://code.google.com/p/tortoisegit/
2. Enable denyNonFastforwards config option on the server 3. If they are files that are autogenerated, you should add them to a .gitignore file in that directory. e.g. my toplevel directory has a .gitignore containing *.o etc |
Amarok LinksCalendar
QuicksearchCategoriesSyndicate This BlogBlog Administration |
||||||||||||||||||||||||||||||||||||||||||

