+1 Sounds good. World add a step though, asking in mailing list if someone
feels like fixing it if I cannot do myself (eg my Smalltalk is a bit rusty). If
still nothing happens, disable. And announce it.
If there is no maintainer for sth then maybe we should consider removing that
language target altogether.
Current policy ... nothing written, nothing explicitly agreed upon. But its a
pain point, thats for sure. Your work is much appreciated.
Have fun,
JensG
Sent from mobile device. You know what that means...
________________________________
From: Mario Emmenlauer <ma...@emmenlauer.de>
Sent: Thursday, September 2, 2021 10:17:02 AM
To: Thrift-Dev <dev@thrift.apache.org>
Subject: Disable failing bindings early?
Hi all,
Since a while there are a number of failing Travis builds. As
far as I can see, they are due to issues with certain bindings
that do not compile any more, or broken installers of some
dependencies.
The problem that I see with the current situation is that the
failing builds "hide" other problems. For the better part of the
year, half of the Travis builds failed. But merge requests where
still merged. I tried my best to only merge when the failing
builds where unrelated. But of course that is more guesswork than
knowing.
So is there a good policy how to deal with failing compilation?
My recommendation would be to disable failing bindings, if:
- nobody is working towards a fix on that binding, and
- latest a _few_weeks_ have passed
so that the rest of the project can move forward.
I can see one advantage and one disadvantage of this policy:
Pro: The rest of the project can move forward, unperturbed and
in high quality (with all builds and tests working).
Con: The failing bindings may not receive updates or testing
any more, so it will become harder to resurrect them after a
while.
What do others think? Or is there a policy already?
All the best,
Mario Emmenlauer
