On Mon, Sep 12, 2016 at 8:14 AM Davin McCall <dav...@davmac.org> wrote:
> 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 > JFTR, this is the mail stuck in the moderation queue that I was referring to, so it's several months old, and was written before the announcement after GUADEC [1]. I won't have time to reply to this and Peter's new messages just now; but Davin, I'm curious to know if the plan from [1] addressed some of your concerns. In lieu of a better reply, one thing that I'm reading from the above is that it might be good to do a GTK blog post on what our best practices are for API design. We do have them; the API doesn't just emerge from the code; but it would be a really great idea to illuminate what goes on. For what it's worth, the current desires to break API I would say mostly stem from needing to get rid of API that was designed in a different era, and is holding things back by making too many assumptions about the underlying tech stack. [1] https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ Regards, Philip C.
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
