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

Yeah, I poked originally. See:

Other people commented and submitted further patches after that. After that, I just gave up. If you're looking for more volunteers, have a good think about this.

Just recently another bug has been marked as a duplicate of this one. I get the feeling if I just continue to ping the bug, or the list, people would tell me to pull my head in because it's not scratching their itch or whatever. I only brought it up in the context of someone else saying there are issues getting patches reviewed and applied.

Regarding IRC - I've never used it because it doesn't save history, so I have to keep an IRC client open 24/7 just to see people's responses - and the people I'm waiting on are invariably in a different timezone. If you have a viable product, submitting a bug to their bug tracking systems and pinging a couple of times should be sufficient - and I note what's been said above regarding there only being 1 full-time developer on the product. Redirecting people to IRC doesn't make less work for anyone - it makes more. Anyway, I did email the gtk-devel-list - from memory - though admittedly it was 13 years ago, as you mentioned.

Otherwise, you get exactly what you paid for.

Oh, I had that one coming. Thankyou.


On Mon, Dec 18, 2017 at 11:16 AM, Emmanuele Bassi <ebassi gmail com> wrote:
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
>> a
>> minor bug, this bug is a real show stopper on Mac, and this change is
>> purely
>> gtk internal. Of course it is not a clean solution, but there is no reason
>> to
>> simply apply this patch (at a bare minimum at least to the gtk3/stable
>> branch)
>> with a FIXME comment for now so that people on Mac can finally start using
>> gtk3
>> 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
> patches?

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]