You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Mario Emmenlauer <ma...@emmenlauer.de> on 2021/09/02 08:17:02 UTC

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

Re: Disable failing bindings early?

Posted by Mario Emmenlauer <ma...@emmenlauer.de>.
Thanks for the thumbs up! Then I will proceed as discussed :-)


On 02.09.21 17:49, Yuxuan Wang wrote:
> +1. Thanks for all the work, Mario!
> 
> On Thu, Sep 2, 2021 at 8:06 AM Jens Geyer <je...@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 <de...@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
>>
> 



Viele Grüße,

    Mario Emmenlauer


--
Mario Emmenlauer                                  Tel: +49-176-23463809
Balanstr. 43                              mailto: mario * emmenlauer.de
81669 Muenchen                                 http://www.emmenlauer.de

Re: Disable failing bindings early?

Posted by Yuxuan Wang <yu...@reddit.com.INVALID>.
+1. Thanks for all the work, Mario!

On Thu, Sep 2, 2021 at 8:06 AM Jens Geyer <je...@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 <de...@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
>

Re: Disable failing bindings early?

Posted by Jens Geyer <je...@hotmail.com>.
+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 <de...@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