|
Hi, I'm not a regular poster to this list and am not subscribed. I'm
posting here now at the suggestion of Philip Chimento, who read a
blog post I wrote recently [1] about the GTK+ lifecycle plans that
have recently been discussed/announced. This blog post of mine
received, for whatever reason, a lot more attention on anything
than my blog normally does (just shy of 20,000 views in a day,
when my average views per day of the whole blog is around 10) -
which puts me in a position such that I feel I should address the
concerns in a more head-on (and level-headed) fashion. I'll freely
admit the tone in the blog posting is that of an indignant rant,
though I hope no-one is personally offended by it since that
certainly wasn't my intention. I'm concerned at the outset that this will be dismissed by people
who are, after all, much more involved in GTK+ than I've ever
been, so I ask that you read this with an open mind and with the
understanding that I'm writing this out of genuine concern that's
developed from the experience of dealing with API breakages in
various packages over a long time-frame. My concern is that the new plan lays a foundation for breaking the API on a more regular basis, and formalises the notion that this is ok if it allows innovation in the design and development of GTK. While I am all for innovation, I am disturbed that casual API breakage in its name is being legitimised, especially because I do not believe that is necessary. From the proposal [2], statements such as:
If new features conflict with existing ones, API might be removed, rather than being deprecated.... are of particular concern. Further, I don't believe that this is consistent with the very next point in the same document:
there will be an effort to limit breakage as much as possible."As much as possible" is a very strong statement. If this was really the aim, there would be hardly any legitimate reason to break API at all, making the whole plan unnecessary. I'd suggest that the latter point is somewhat disingenuous (even if unintentionally so); putting it bluntly, only one of those two points can be correct, and from the tone of the document, I'm assuming that it's the first one and the second is a case of overly-strong wording. But on the other hand, removing API instead of deprecating is most definitely a breaking change that can often be *easily* avoided, let alone "as much as possible". Please do not assume I am basing my entire concern on that point
alone. The general feeling from the proposal and the GTK
development blog post that I initially responded to is that API
stability is very much being pushed to a low priority compared to
the need to push development ahead. I understand that API breakage
does sometimes need to occur, but I think this attitude is not a
good one. In particular I think the implied notion that API
stability and good development progress cannot coexist is
incorrect. I understand how open-source development often works in ways that don't suit more traditional rigourous approaches, but I would recommend establishing a set of guidelines for API development, and at a minimum have each commit/check-in that introduces new API be reviewed against those guidelines by a developer not otherwise involved. Since I can't claim to know how GTK development proceeds there's the possibility that something like this (or better) already happens - in which case, perhaps my concerns can be dismissed; if so, please consider publishing details and updating the Best Practices document. Thanks for reading, Davin.
[1]
https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations
|