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 would be reassured perhaps if the plan discussed what software development methods were in place that would help to reduce the amount of API breakage needed. What is the procedure for API design in GTK - if there indeed is one? Are APIs reviewed before they are implemented? Are they made available for public review? Are there any guidelines? The Best Practices document [3] doesn't even mention API design; why not? Are the APIs even designed at all? I am left with the worrying impression (hopefully not correct) that the API simply emerges from the code. This would certainly explain why API breakage might be needed on a regular basis, but that's a symptom of an imperfect design practice; if it is being found that the resulting APIs are not extensible or flexible enough for ongoing development and future requirements, then I strongly suggest that the better solution is to improve the API design methodology, rather than simply to legitimise casual API breakage. 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 [2] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
