Re: First deprecate APIs and then remove them in the next major version

On 17 December 2017 at 23:14, Daniel Kasak <d j kasak dk gmail com> wrote:

Just one example, gtk3 (yes 3, not even 4) is currently completely
unusable on
Mac, so I sent a patch to fix this:

I know my patch is suboptimal, but to make this clear: it does not address
minor bug, this bug is a real show stopper on Mac, and this change is
gtk internal. Of course it is not a clean solution, but there is no reason
simply apply this patch (at a bare minimum at least to the gtk3/stable
with a FIXME comment for now so that people on Mac can finally start using
at all.

I really have to agree. One of my bugs I raised in 2004 - which involves
data loss - is still open. I submitted a patch ( which was difficult at the
time - I only dabble in C when I absolutely have to ) which received very
little feedback, and the bug has rotted since.

Yes, everyone has their own pet bug where they submitted a patch and
waited for feedback, as if GTK doesn't have ~3000 issues open at any
given time, and a constant stream of bugmail.

It would be *great* if we could review all incoming patches; sadly, we
either do that, or we spend time actually developing the toolkit.

Plus, if you have a patch lying in bugzilla for *13* years and you
never bothered to actually poke people about it, then I don't think
it'll ever get bumped up in terms of priority on the list of things to

"Send a patch" only goes so far. If patches don't get reviewed, or don't get
sufficient feedback, and never get accepted, what's the point in sending

Your role doesn't terminate at sending a patch.

It's your bug, your patch, and your responsibility for bringing it up
to the people *volunteering* to work on GTK. If you have a patch that
is languishing in Bugzilla, join the #gtk+ IRC channel on, or send an email to gtk-devel-list.

Otherwise, you get exactly what you paid for.


[@] ebassi []

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]