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