Thursday, November 26. 2009A reflection: How we made Amarok 2.2.1
So, I'm writing this partly because of vanity (let's be honest here), partly because reflection helps managing past mistakes better in the future, and also because some of you (KDE community) have asked about our experiences with Git. With this out of the way, let's go in medias res:
With Amarok 2.2.1 we have tried a new approach in release management, which meant a rather radical departure for us: The whole release cycle of 2.2.1 was pretty exactly 6 weeks long. While six weeks can be a lot of time, or very little time, in our case it was very little time, as we had set a goal of achieving three things with this release: 1) Features 2) Bug Fixes 3) Doing it all without causing regressions. To give you an impression of what we have done in these 6 weeks, check this out: Amarok 2.2.1 ChangeLog As you can see, the list is pretty long, especially so if you consider the short time frame. All of this made us proud of this release, perhaps even more so than of the 2.2.0 release (which used an ordinary long release cycle). One thing that contributes to our happiness about it: This was pretty damn hard to do, but in the end we made it. Did it go completely smoothly? Hell no. A lot of things went wrong, but it was a good learning experience. We intend to continue working in this style (one release every six weeks) for the foreseeable future, while incorporating some of the things we have learned (the hard way) with 2.2.1. What went well:What went wrong:That's it for now. Thanks for reading, and maybe also take a quick look at our Amarok 2.2.2 ChangeLog (at the time of this writing, our cycle is just about 50% completed, so I think it's pretty impressive already). Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
This just depends on the Phonon version you are using, it is integrated on our side already.
So how exactly can I get an equalizer? I love Amarok, and with an EQ I would never use another music player. Thanks!
With KDE SC 4.4 (in beta 1 state at this point), you'll have the Equalizer automatically.
Regarding GIT: while is surely has nice features, it's a PITA for the occasional developer! It's just too complex. I did a patch here or there for amarok and a few times was about to throw this damn thing into the corner. You know, I just wanted to fix this bug and then found myself again reading endless git documentation because something broke again. Where you did a simple svn up and it updates and merges with local changes, you have to know exactly what to do with git, and beware not to forget something or do it in the wrong order, then you get a huge mess where nothing seems to go forward or backward... been there done that, it's annoying at best. I mean, by now I more or less get along with it, but I can't say I have understood how things work... And I haven't even bothered with remote branches and merge request... and actually I don't feel like it.
So from own experience I kinda doubt, that GIT is attracts more developers. It simply put up a hurdle which is quite a bit higher than SVN was. Remember for most its not a reason in it self, but just a tool.
You're overestimating the complexity of Git.
While it is true that Git does have a steep learning curve, it is perfectly possible (and good advice) to only use a small subset of its myriads of features. I don't think that anyone in the Amarok team (in the world?) knows every single Git feature. But that's not necessary either.
I'm not overestimating. This is my personal experience. I used Git in combination with amarok for more than a day. I read several tutorials still I often don't understand it. There were a lot of places where Git simply refused to do things. And even one case where things completely locked up. And then you have to search web and documentation to find the specific command to make things work. Take this simple example: you added some local changes, say a bit debug output to track down a problem. Now you want to update. With svn you do "svn up" and you're done. Git refuses to update. In the beginning I diffed out the changes, reverted changed files, updated and played back the changes. Where I just thought: Goddamn, just update and merge local changes! Eventually I found out about git stash. But even with stash I had cases where I suddenly couldn't play back a stash, because I did something in the wrong order. No, git is not only more complex and uses entirely different concepts, it's also pretty pedantic. And that can be frustrating. I don't say it doesn't have neat features. And when you use it every day you probably get a hang of it someday. But when you only use it every now and then things look different. A version control is a tool and as such should not get in the way. Git however gets in the way. I want to spend my little time with the problem, not with the version control system. I see great frustration when eventually KDE switches to git.
I've done a SVN to Git transition few years ago without any problems. There were no such problems, cause I was never updating with uncommitted changes. First, I finish some part of work and commit and only then I update.
http://techbase.kde.org/Getting_Started/Sources/Amarok_Git_Tutorial
this page tells you exactly the workflow to use, step by step. it's not that complicated if you follow it properly 
Well, of course I know this page. Still it's not really helpful, when git start to complain "can't do this!". And this happend to me more than once, even though I tried to stick to this list.
And as I said, my main interest was in fixing this bug, not in learning git because it's so cool.
Your points are clear and I think you are right with the conclusion git can be very frustrating.
What I think went wrong is that you just tried to do what you were expected to do in subversion, but then using git. You could have saved all the updating and merging issues by just using the distributed part of git. The point is, you never need to merge. Gitorious does that for you. Thats the whole point of the site. So, yes, merging is not easy. Solution, don't do it. There is no reason at all for you to pull and merge if you just push your patch to gitorious.
> What I think went wrong is that you just tried to do what you were expected to do in subversion, but then using git.
Well, as I knew beforehand that git is quite different conceptually, I forced myself to go through two, three tutorials. Still it didn't save me from annoying/frustrating experiences. > You could have saved all the updating and merging issues by just using the distributed part of git. > The point is, you never need to merge. Gitorious does that for you. Thats the whole point of the site. Err, huh?! I have difficulties following you here... where is the difference between merging on a server vs. merging locally? Git should be smart enough to do that, no? Why would using gitorious magically solve all the stupidness of git?I don't use gitorious as I didn't intend to do anything big. The little patch I thought I can as well send as diff somewhere. Leave alone things I do just for my own. Also I felt that this adds another level of complexity and overhead, I was not keen on. > So, yes, merging is not easy. Solution, don't do it. There is no reason at all for you to pull and merge if you just push your patch to gitorious. What if I just want to add some debug output to track down a bug? Why should I push these useless changes somewhere else? Oh, and apparently I just don't know of these different concepts of using git... you see, this is part of the problem, why I think git is not really suited for people outside the core circle.
I can understand your frustration, but you need to understand that Git is not anything near SVN. That workflow is invalid in Git.
This is what you should have done: 1. You should have committed your debug output in its own commit. Commits are cheap in Git. 2. You work on your other stuff and commit them in small steps. 3. When you are done and want to send in a patch, you do a squash on all commits you want to keep and you remove the debug code commit. 4. Send in the patch of the squash. In SVN, a commit is a large and dangerous operation. That's why people have many local changes and need to update. In Git, you are supposed to commit often and then rewrite history to make it clean and proper before sending stuff in. This gives extra backup and flexibility. So, how to update, then? Well, you just fetch from origin (== svn update without the merge) and then you rebase your commits upon the new tip (rewriting history to place your commits after the latest commit you fetched). A shortcut for this process is "git pull --rebase". The reason it doesn't allow you to do this when you have local changes is to protect you. Git does a lot to protect your data – even when you remove commits, they are kept for a while so you can undo. You can undo almost every operation in git. This is just one workflow. There's a lot of ways to do stuff like this. It all depends on the kind of person working with it. This is a workflow that is pretty similar to SVN since it works in linear history and assumes you want to move quickly on top of newer commits. IMHO, this is the best Git tip ever: "Git is nothing like SVN. Linus hates CVS/SVN with a passion and he would never make it similar. Forget everything you know about SCMs if you have only used SVN before starting with Git." If I were trying to revert commits in svn by running "svn revert trunk~3", or trying to edit files in-place with grep, I would have nothing to complain about when it doesn't work. You gotta learn the tool that you're using.
interesting article, thanks for amarok, and... will be any chance of have back the good big old toolbar?
by the way in Arch the ecualizer ran very well.
Needed or not, this is off-topic here. You can file wish reports on http://bugs.kde.org.
We (the users) DO and it gets closed as "will not fix", so we are going to kick and scream until you realise that your behaving like the pidgin devs.
Seriously when did it become cool to ignore your users and remove all customisability? p.s thanks for the good work amarok 2.x is finally as good as 1.4.x (and i don't mean that in a bad way as 1.4.x was great)
Clearly we need very good documentation when we switch to Git, then... I must admit I don't look forward to learning a new SCM tool
The documentation is quite good. Well, it maybe lacks something like "guide about everything for early beginners", but is you start from a GOOD manual (and there are) - you'll succeed with the basics. For other things - google and man git * is quite enough. At least it was for me.
git is a really really nice tool
fast, scriptable, flexible, powerful
I'm really excited to see the Amarok team benefiting from using git. What I'm wondering is how it has affected translation. Is this looking to be a positive change there as well? Or are there going to be problems?
Translations shouldn't be affected at all. They are still done by the same team as before in the same place (SVN).
|
Amarok LinksCalendar
QuicksearchCategoriesSyndicate This BlogBlog AdministrationWe Listen To... Powered by
|
||||||||||||||||||||||||||||||||||||||||||
