Saturday, February 27, 2010

Kate Partly Moving to Gitorious

We are about to move the applications Kate and KWrite as well as the libraries KTextEditor and Kate Part to gitorious. Christoph is working on the migration right now in order to keep the development history. Things look good so far, so the migration is soon finished.
We have discussed a bit about the migration to gitorious on the Kate Developer Meeting and Christoph came up with this mainly because building only KTextEditor, Kate Part, KWrite and Kate is much faster and easier compared to building the KDE modules kdesupport, kdelibs, kdepimlibs, kdebase, kdesdk.
I myself remember the time where I started KDE development, and it took more than two weeks to have a first successful build of KDE. You have to learn so many things at once, like revision control, lots of so far unknown software, and what not. Talking to other developers verifies this. In other words: Getting into KDE development is not easy and straight forward.
Moving to gitorious removes this barrier for Kate development: You just checkout the Kate repository and that's all you need. It would be nice if you join Kate development and contribute patches :)
What does that mean for Kate in KDE? Nothing changes. We will merge the changes in Gitorious back to the main KDE development line and vice versa.

11 comments:

Blackpaw said...

We have discussed a bit about the migration to gitorious on the Kate Developer Meeting and Christoph came up with this mainly because building only KTextEditor, Kate Part, KWrite and Kate is much faster and easier compared to building the KDE modules kdesupport, kdelibs, kdepimlibs, kdebase, kdesdk.


How is this made possible with git but not with subversion?

I build kdevplatform & kdevelop by themselves (using the KDE 4.4 SDK from kubuntu) and they just live in subversion

Alex Wauck said...

I think more of KDE needs to do this. I once tried to compile kmix with PulseAudio support, but it turned out that I needed to compile all of kdemultimedia in order to do so instead of reusing my existing kdemultimedia libraries. I don't think there were any API compatibility issues, just the build system issue. I long for the day I can click a few buttons and have the source code for a KDE application come up in KDevelop. At the risk of sounding like Jono Bacon, what has happened with Kate is a great way of encouraging opportunistic programmers to contribute to the project, and I applaud that.

dhaumann said...

@Blackpaw: It's also possible with SVN, of course. But working with branches and merging is not so easy as with git. Besides, KDE will probably more and more use git. Kate is not the first project. Besides, this gives us Kate developers some playground to learn git.

PS: KDevelop works on a git migration as well, afaik :)

Aaron J. Seigo said...

this is, imho, a very bad idea, and here is why:

we now have two places for the source code and that means that contributors will need to figure out where to work and people merging changes will need to manage two possible places can be made from.

it splinters the KDE community as we go from having a nice large, canonical place for our work to many uncoordinated and even duplicated pieces.

worst of all, there is no guarantee that we will move to gitorious.org. i do think we will move to git, and i do think that we will have a gitorious installation but it many not be on gitorious.org.

instead of each project rushing off to make such changes on their own, it would make a *lot* more sense to coordinate this.

then there's the issue of documentation on techbase.

you want to make it easier to get involved, and that is terrific. however, done as it is in this way i'm not sure it will actually do this.

right now with various projects jettisoning off to gitorious.org on their own, it's a bit of a riot and chaos and it is really completely unnecessary.

i also think this addresses the problem in the "wrong" (not quite the right word :) place: by rearranging and duplicating the repositories rather than improving the build system in general.

in any case, please consider a path that can enable us to work _together_ on this transition rather than continue the unhealthy fragmentation that is currently going on.

Aaron J. Seigo said...

@Alex Wauck: all you needed to do was cd into the kmix directory and build from there. there was no need to build everything in kdemultimedia.

evidently we need to make such things more obvious / evident, particularly as people are less and less familiar with building from sources these days.

chani said...

uhm... er... any reason you guys didn't come talk to the scm people?

it'd be nice if you could, y'know, help out with the real KDE git migration, so that we can *all* be on git together, instead of just having this weird dual setup for your own project.

please?

kde-scm-interest mailing list, or #kde-git (next meeting is wednesday 19:30UTC)

Tabesin said...

Gitorious is Affero GPL, so KDE could run their own installation.

It is dead easy to move git code from one repository to the other because there is no central repository. Lock-in is zero.

blauzahl said...

Is your team really going to be that disciplined?

I have no clue what percentage of BugSquad is using git right now. I didn't think KDE was moving until everything was actually ready. We haven't discussed KDE-in-git on irc or the mailing list.

You have 291 bugs open right now.

Cullmann said...

As Dominik said, we will sync back changes. Look at the history of kate part and application over the last years, quiet low profile changes. Now the time is come, for some serious evolution. It did just feel natural to do this in git instead of some weired SVN branch. Given that many of the Kate contributors anyway use git locally, this doesn't do any harm. If you look at how many bugfixes occur in kdelibs/kate, it is no problem to collect them and port to git, and the massive destruction of the part will happen in a branch of the gitorious repository.

About the lacking coordination: #kde-git told me how to use svn2git, where to write the rules and how the repostory should be created in a way the kde sysadmins can admin it, the kde-developers can commit and review requests don't spam around all people, I would not talk about "no-coordination".

For the lower entry burden: You now clone the gitorious repo, type cmake + make, you have working part + app. That is not reachable without any magic with the setup it is atm in SVN, as you at least need kdelibs/kdesdk for that. Yeah, you can checkout subdirs, have some scripts, all nice, but the current way is plain easy.

I am quiet amazed, which ripples that all spreads, but lets be positive, any press is better than no press :/

Speaking about communication or coordination: Amazing that I need to read up about such feedback here, only one person contacted me until now via mail about all this, see zero mails on kwrite-devel@kde.org about any questions. Dear Aaron, blog comments are not the only way to give feedback ;)

Blackpaw said...

What was wrong with just checking out the kate tree from svn and building that? How is it different from clone a git repo

Thomas said...

Oh, this is really not a very nice result...

Fighting the problem that Kate code is spread over different modules by duplicating the code and actually doing it in a different scm sounds like an overkill solution as well as one that pulling in a shit load of new political and technical problems. I wish you reconsidered this.

Many items have been brought up here already and most of them I agree with. One thing has not been said very clearly that I think needs emphasis. You take pieces of code from 3 kde modules and clone it. In a different scm!! Saying you will commit back. That means confusion, merge errors and loss of history in the long run.

* Confusion. Kate is part of KDEBase, people know this and like this as it comes with the SC. Moving it means people have an even harder time figuring out where to commit. This is the opposite of what you want.

* Merge errors. If you decide to not decide on a canonical source or upstream of the project people will make fixes in either projects copy and you'll have merge commits. Its not an 'if' its a 'when'.

* Loss of history; Git doesn't map to svn. You can have merge commits in git that have no equivalent in svn. You can't commit under the name of a person that you merged from but has no svn account. So 'who' committed is lost.

I don't think the kate people thought this through, they incite pain for themselves and for a *LOT* of others by doing this. Please reconsider.

ThomasZ