Why KWin master was hard reset

Martin Flöser mgraesslin at kde.org
Sat Jun 10 18:27:51 UTC 2017


Hi all,

I want to shortly explain why I requested a hard reset of KWin master to 
undo the override changes.

First of all the changes went in without code review. This is not common 
in the case of KWin. I'm sure the changes were well intended and given 
that  it is uncommon to do a hard reset.

Aleix recently created a review request for exactly the same change. We 
decided against this change in that review. From code side such a large 
change carries a risk. For a large code base such as KWin the change 
means thousands of affected lines of code. Too much for a human to 
review, but such a change carries a risk. We are humans and might do 
mistakes so it must be reviewed.

KWin basically consists of two parts: a modern well tested part which 
already uses override and an older part which hardly sees any changes. 
This means our test suite would most likely not be able to detect 
regressions in this area. Also manual testing would be unlikely to find 
a regression. On the other hand override does not give us any advantage 
in this code base. It hardly moves.

Overall for me as the maintainer it means that the change introduced a 
risk while not really giving us an advantage. That's not obvious for 
someone not so deeply involved with the development of course. Due to 
that I see it as my obligation to revert the changes.

So why a hard reset instead of a revert? During the review of Aleix's 
change we recognized another issue: it breaks git blame. Over the years 
it has shown to be a very important tool even to go back to code 
unchanged for years. What showed itself as a problem are the huge code 
breaks. Changes which affect everything. Currently we have three such 
changes: the coding style change, the introduction of the compositor and 
the merge of KWin 3 branch. This is the primary reason why I asked for 
KWin to be split out into an own git repo with full history: I didn't 
want to have yet another history breakage point. If we would have kept 
history here with a revert we would have had to live with three more 
breakage points in git history: the introduction of Q_DECL_OVERRIDE, the 
fix-up to override and the revert. That is something I don't want. Due 
to that I did the uncommon request to hard reset KWin master.

Normally I would have done so immediately after the push, but I didn't 
have Internet access and reacted when I noticed what was pushed. Due to 
the limited Internet access I currently have I went for asking sysadmins 
first without a heads-up notice. Sorry for any inconveniences.

Cheers
Martin


More information about the Plasma-devel mailing list