+1. Thanks for all the work, Mario! On Thu, Sep 2, 2021 at 8:06 AM Jens Geyer <jensge...@hotmail.com> wrote:
> +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 >
