Tuesday, August 18, 2015

Using git the proper way for correct release changelogs

If you look at kdenlive's changelog for KDE Applications 15.08 and for KDE Applications 15.04.3 you'll see that "Fix autosave not working when opening project file from command line or click in file browser" shows up in both.

On the other hand if you have a look at gwenview, in 15.04.3 it shows "Make saving thumbnails work again" while it's not part of 15.08.

Does that mean that this bug got lost?

No, gwenview is actually the correct thing, we should not mention a bug again for 15.08 if it was released in 15.04.3, since well it's been released already :D

So why does kdenlive, marble and others show commits in the two places?

Because their developers are not doing the proper git-thing of commiting to the oldest supported branch and then merging up to master, so for git it's two different commits instead of the same (in case of the kdenlive commit in question it'd be https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=cc55a9cea5c2f029744f8aba79a362fd302ec0bb and https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=28b3cc7b5141fcc2fed84433b9fe9851c35b7e08).

Commiting the fix to the oldest supported branch and then merging up has lots of other benefits (like making sure you never forget a fix in master), but maybe this is the one that finally convinces more devs to switch to it, nicer changelogs ;)


Dennis Nienhüser said...

Maybe merging branches is the way *you like*, but that does not make it *the proper* way. The proper way is documented properly in techbase: https://techbase.kde.org/Development/Tutorials/Git/Recipes
Push to master, cherry-pick to stable.

Pushing to master first means that you test it there first. And other people. And if it works fine, you can easily backport the fix using a nice cherry-pick command that (using cherry-pick -x) also references the original commit. We test some commits for days or weeks in master before backporting to be really sure they're safe. How would that work with your approach?

Pushing to stable means you push a fix only tested by you. Merging that branch to master afterwards moves over any other commits as well. And it fscks up the history of that branch. All that just happened to Marble's master because apparently someone followed your recommendation. And I'm really angry about it. Stop propagating this.

Albert Astals Cid said...

That document is then wrong.

I'm just using git the way it's supposed to be used.

You go and ask git to give the diff between v15.04.3 and v15.08.0, if you've done the commits my way, you get the proper answer, if you've done the commits your way, you get the wrong answer.

I'm not going to stop recommending this since it's the way that you are supposed to use git, sorry if you don't like it.

Dennis Nienhüser said...

There are several different git workflows in use. None of them is a "supposed way".

For KDE in particular there is no conclusion about a specific git workflow, so each project has to pick one that suits its developers best. Having an agreed upon workflow would probably be an improvement for newcomers and the release team, but it needs a discussion, consensus and time to implement first.

I assume you are meaning well. Maybe you are trying to (re-) start the discussion about a common workflow. But here's how I perceive it: You're standing on a soap box, angrily shouting commands and publically blaming projects still active when they don't fit your personal working style. A working style you haven't communicated with them (at least Marble) before, or that just does not fit them. You're just picking on them and ultimately doing harm. Doing harm by badmouthinig KDE projects. Doing harm by demotivating KDE developers, at least me personally. Repeatedly over years, to be honest. That is what I don't like.

Albert Astals Cid said...

Ok, i apologize if you felt demotivated by my blog.

What i was trying to explain is why the 15.08 changelog for some projects looks wrong (i.e. it seems there is lots of bugs fixed but those bugs where already fixed in the 15.04 series).

It is because the workflow those projects use doesn't play well with git log.

Of course it seems that while trying to explain that i fucked up and ended being a bit too negative, sorry again, i never intented to do any badmouthinig of anyone.

Dennis Nienhüser said...

Ok, I see. Let's move on.