You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Renan DelValle <re...@apache.org> on 2018/04/05 17:03:45 UTC
Feedback from a maintainer of a project using the go thrift bindings
Hi all,
I'm a PMC of Apache Aurora, which uses Thrift. As part of my job, I
maintain separate (from the apache project) thrift go bindings in order to
interact with Aurora.
Yesterday, I had team members unable to compile my project because,
suddenly, the Apache git repository for Thrift (git.apache.org/thrift.git)
went missing.
It took me far too long to find that there was a vote to move from this
location that was originally taking place in private@[1] (which Jake
Ferrell thankfully addressed).
No official announcements were made as far as I can tell.
This lack of communication isn't new as I'm continuously finding out (by
reading the commit log) about changes that cause breakage between code
generated by newer versions of Thrift and my codebase.
Taking a look at the thrift/CHANGES[2] for example, the changes for version
0.11.0 are not even listed. At the very least there should be release notes
warning users about breaking changes.
In the past two versions of thrift, three changes broke backwards
compatibility for go:
* In version 0.10.0, the way sets are represented was changed[3].
* In version 0.11.0, the way sets are represented was changed again[4] and
context generation was added[5].
These created a ton of work for project maintainers to move from one
version to another.
When a user brought up the addition of context as breaking change[6], I was
disappointed to see maintainers seemingly dismiss his concerns instead of
working to find a solution. For example, one solution is that this change
could have been set behind a flag, allowing the user the flexibility to
turn it off. (In fact, I created a JIRA issue to that end a while ago [7].)
I understand there is sometimes no way around making breaking changes
between versions, but the lack of communication, and the seeming lack of
concern for changing the generation in a way that breaks existing projects,
without publicly exploring alternatives, makes it difficult to advocate for
using Thrift for go based projects.
Now that the location of the git repository changed, code generation is
broken because all generated files try to import from
git.apache.org/thrift.git forcing users to upgrade or to use dependency
management capable of changing the source of this repository.
This change is incredibly impactful, even to users dependent on older
releases, so I'm curious about why this change was not communicated on the
user@ list? Further, why is it not listed anywhere on the website or
repository that this is happening? And finally, why were the side-effects
of this change not considered in the voting discussion[8]?
Unfortunately, the list of users affected by this latest change will only
continue to grow [9].
As a user who depends on the go Thrift library, the current situation is
unacceptable, and I'm offering my help to alleviate these issues if it's
required (and welcomed), but this should not go on any longer. Engagement
with the community is a must. Not doing so is bad for users, is bad for
adoption rates, and is unhealthy for the project.
My hope is that this feedback is taken as constructive criticism and is in
no way meant to attack the project. I'm a volunteer as well, and I greatly
appreciate the effort and time maintainers and contributors put into this
project.
-Renan
[1] http://mail-archives.apache.org/mod_mbox/thrift-dev/201804.mbox/%
3CCAHJqfcLgVZ0JKX2RGRvKkk5ksG9wfjigsscMbwjqmuXwvMPT1A%40mail.gmail.com%3E
[2] https://github.com/apache/thrift/blob/master/CHANGES
[3] https://github.com/apache/thrift/pull/976
[4] https://github.com/apache/thrift/pull/1156
[5] https://github.com/apache/thrift/pull/1459
[6] https://issues.apache.org/jira/browse/THRIFT-4261
[7] https://issues.apache.org/jira/browse/THRIFT-4453
[8] http://mail-archives.apache.org/mod_mbox/thrift-dev/201803.mbox/%
3CCY4PR2001MB1045B65EB761CD015624C5FAC8AA0%40CY4PR2001MB1045.namprd20.
prod.outlook.com%3E
[9] https://issues.apache.org/jira/browse/THRIFT-4542
Re: Feedback from a maintainer of a project using the go thrift bindings
Posted by Renan DelValle <re...@apache.org>.
Allen,
You've summarized what I wanted to say even better than I could (and
believe me I tried!).
I really appreciate you taking the time to read and being receptive of my
feedback.
Thanks for personally committing to taking it into account in the future.
Thrift is a great project and I would like to see it continue to thrive.
-Renan
On Thu, Apr 5, 2018 at 7:33 PM, Allen George <al...@gmail.com> wrote:
> Hi Renan - thanks for reaching out. Note that my comments are personal, and
> I'm in no way speaking for the project or its members.
>
> I think your comments can be summarized as follows:
>
> 1. Breaking changes are made between releases without enough communication
> 2. Changes are made without soliciting feedback from the community
> 3. It's hard to understand what has changed from release to release
> 4. In this specific instance, the repo change was not communicated to the
> user list
>
> On the git issue specifically: personally, unless I work day-to-day with a
> language I forget its idiosyncrasies. For example, while I work with Go off
> and on, and it totally slipped my mind that imports are tied to actual repo
> locations. So, what I thought of as an infrastructure-only change turned
> into a larger issue. Second, I can say that what's considered a breaking
> change can be a little murky, especially when dealing with code-generation.
> There is, as you know, a cost to adding switches and introducing additional
> code paths in the thrift compiler. And, sometimes, what seems like an
> innocuous change can be depended on by downstream users. This is of course
> tougher when you're dealing with many languages, each with their individual
> cadences.
>
> That said, I've taken your point about communication to heart, and, for the
> languages I work on, will make it a priority to:
>
> - keep a changelog
> - solicit feedback from the user list when changing type details etc. wrt.
> generated code.
>
> I appreciate your using Thrift, and sending this mail.
>
> Best,
> Allen
>
>
>
> ---
>
> Terminal Musings: http://www.allengeorge.com/
> Twitter: https://twitter.com/allenageorge/
> Raft in Java: https://github.com/allengeorge/libraft/
> Thrift Rust Bindings: https://thrift.apache.org
>
> On Thu, Apr 5, 2018 at 1:03 PM, Renan DelValle <re...@apache.org> wrote:
>
> > Hi all,
> >
> > I'm a PMC of Apache Aurora, which uses Thrift. As part of my job, I
> > maintain separate (from the apache project) thrift go bindings in order
> to
> > interact with Aurora.
> >
> > Yesterday, I had team members unable to compile my project because,
> > suddenly, the Apache git repository for Thrift (
> git.apache.org/thrift.git)
> > went missing.
> >
> > It took me far too long to find that there was a vote to move from this
> > location that was originally taking place in private@[1] (which Jake
> > Ferrell thankfully addressed).
> > No official announcements were made as far as I can tell.
> >
> > This lack of communication isn't new as I'm continuously finding out (by
> > reading the commit log) about changes that cause breakage between code
> > generated by newer versions of Thrift and my codebase.
> >
> > Taking a look at the thrift/CHANGES[2] for example, the changes for
> version
> > 0.11.0 are not even listed. At the very least there should be release
> notes
> > warning users about breaking changes.
> >
> > In the past two versions of thrift, three changes broke backwards
> > compatibility for go:
> >
> > * In version 0.10.0, the way sets are represented was changed[3].
> >
> > * In version 0.11.0, the way sets are represented was changed again[4]
> and
> > context generation was added[5].
> >
> > These created a ton of work for project maintainers to move from one
> > version to another.
> >
> > When a user brought up the addition of context as breaking change[6], I
> was
> > disappointed to see maintainers seemingly dismiss his concerns instead of
> > working to find a solution. For example, one solution is that this change
> > could have been set behind a flag, allowing the user the flexibility to
> > turn it off. (In fact, I created a JIRA issue to that end a while ago
> [7].)
> >
> > I understand there is sometimes no way around making breaking changes
> > between versions, but the lack of communication, and the seeming lack of
> > concern for changing the generation in a way that breaks existing
> projects,
> > without publicly exploring alternatives, makes it difficult to advocate
> for
> > using Thrift for go based projects.
> >
> > Now that the location of the git repository changed, code generation is
> > broken because all generated files try to import from
> > git.apache.org/thrift.git forcing users to upgrade or to use dependency
> > management capable of changing the source of this repository.
> >
> > This change is incredibly impactful, even to users dependent on older
> > releases, so I'm curious about why this change was not communicated on
> the
> > user@ list? Further, why is it not listed anywhere on the website or
> > repository that this is happening? And finally, why were the side-effects
> > of this change not considered in the voting discussion[8]?
> >
> > Unfortunately, the list of users affected by this latest change will only
> > continue to grow [9].
> >
> >
> > As a user who depends on the go Thrift library, the current situation is
> > unacceptable, and I'm offering my help to alleviate these issues if it's
> > required (and welcomed), but this should not go on any longer. Engagement
> > with the community is a must. Not doing so is bad for users, is bad for
> > adoption rates, and is unhealthy for the project.
> >
> > My hope is that this feedback is taken as constructive criticism and is
> in
> > no way meant to attack the project. I'm a volunteer as well, and I
> greatly
> > appreciate the effort and time maintainers and contributors put into this
> > project.
> >
> > -Renan
> >
> > [1] http://mail-archives.apache.org/mod_mbox/thrift-dev/201804.mbox/%
> > 3CCAHJqfcLgVZ0JKX2RGRvKkk5ksG9wfjigsscMbwjqmuXwvMPT1A%40mail.gmail.com
> %3E
> > [2] https://github.com/apache/thrift/blob/master/CHANGES
> > [3] https://github.com/apache/thrift/pull/976
> > [4] https://github.com/apache/thrift/pull/1156
> > [5] https://github.com/apache/thrift/pull/1459
> > [6] https://issues.apache.org/jira/browse/THRIFT-4261
> > [7] https://issues.apache.org/jira/browse/THRIFT-4453
> > [8] http://mail-archives.apache.org/mod_mbox/thrift-dev/201803.mbox/%
> > 3CCY4PR2001MB1045B65EB761CD015624C5FAC8AA0%40CY4PR2001MB1045.namprd20.
> > prod.outlook.com%3E
> > [9] https://issues.apache.org/jira/browse/THRIFT-4542
> >
>
Re: Feedback from a maintainer of a project using the go thrift bindings
Posted by Renan DelValle <re...@apache.org>.
Allen,
You've summarized what I wanted to say even better than I could (and
believe me I tried!).
I really appreciate you taking the time to read and being receptive of my
feedback.
Thanks for personally committing to taking it into account in the future.
Thrift is a great project and I would like to see it continue to thrive.
-Renan
On Thu, Apr 5, 2018 at 7:33 PM, Allen George <al...@gmail.com> wrote:
> Hi Renan - thanks for reaching out. Note that my comments are personal, and
> I'm in no way speaking for the project or its members.
>
> I think your comments can be summarized as follows:
>
> 1. Breaking changes are made between releases without enough communication
> 2. Changes are made without soliciting feedback from the community
> 3. It's hard to understand what has changed from release to release
> 4. In this specific instance, the repo change was not communicated to the
> user list
>
> On the git issue specifically: personally, unless I work day-to-day with a
> language I forget its idiosyncrasies. For example, while I work with Go off
> and on, and it totally slipped my mind that imports are tied to actual repo
> locations. So, what I thought of as an infrastructure-only change turned
> into a larger issue. Second, I can say that what's considered a breaking
> change can be a little murky, especially when dealing with code-generation.
> There is, as you know, a cost to adding switches and introducing additional
> code paths in the thrift compiler. And, sometimes, what seems like an
> innocuous change can be depended on by downstream users. This is of course
> tougher when you're dealing with many languages, each with their individual
> cadences.
>
> That said, I've taken your point about communication to heart, and, for the
> languages I work on, will make it a priority to:
>
> - keep a changelog
> - solicit feedback from the user list when changing type details etc. wrt.
> generated code.
>
> I appreciate your using Thrift, and sending this mail.
>
> Best,
> Allen
>
>
>
> ---
>
> Terminal Musings: http://www.allengeorge.com/
> Twitter: https://twitter.com/allenageorge/
> Raft in Java: https://github.com/allengeorge/libraft/
> Thrift Rust Bindings: https://thrift.apache.org
>
> On Thu, Apr 5, 2018 at 1:03 PM, Renan DelValle <re...@apache.org> wrote:
>
> > Hi all,
> >
> > I'm a PMC of Apache Aurora, which uses Thrift. As part of my job, I
> > maintain separate (from the apache project) thrift go bindings in order
> to
> > interact with Aurora.
> >
> > Yesterday, I had team members unable to compile my project because,
> > suddenly, the Apache git repository for Thrift (
> git.apache.org/thrift.git)
> > went missing.
> >
> > It took me far too long to find that there was a vote to move from this
> > location that was originally taking place in private@[1] (which Jake
> > Ferrell thankfully addressed).
> > No official announcements were made as far as I can tell.
> >
> > This lack of communication isn't new as I'm continuously finding out (by
> > reading the commit log) about changes that cause breakage between code
> > generated by newer versions of Thrift and my codebase.
> >
> > Taking a look at the thrift/CHANGES[2] for example, the changes for
> version
> > 0.11.0 are not even listed. At the very least there should be release
> notes
> > warning users about breaking changes.
> >
> > In the past two versions of thrift, three changes broke backwards
> > compatibility for go:
> >
> > * In version 0.10.0, the way sets are represented was changed[3].
> >
> > * In version 0.11.0, the way sets are represented was changed again[4]
> and
> > context generation was added[5].
> >
> > These created a ton of work for project maintainers to move from one
> > version to another.
> >
> > When a user brought up the addition of context as breaking change[6], I
> was
> > disappointed to see maintainers seemingly dismiss his concerns instead of
> > working to find a solution. For example, one solution is that this change
> > could have been set behind a flag, allowing the user the flexibility to
> > turn it off. (In fact, I created a JIRA issue to that end a while ago
> [7].)
> >
> > I understand there is sometimes no way around making breaking changes
> > between versions, but the lack of communication, and the seeming lack of
> > concern for changing the generation in a way that breaks existing
> projects,
> > without publicly exploring alternatives, makes it difficult to advocate
> for
> > using Thrift for go based projects.
> >
> > Now that the location of the git repository changed, code generation is
> > broken because all generated files try to import from
> > git.apache.org/thrift.git forcing users to upgrade or to use dependency
> > management capable of changing the source of this repository.
> >
> > This change is incredibly impactful, even to users dependent on older
> > releases, so I'm curious about why this change was not communicated on
> the
> > user@ list? Further, why is it not listed anywhere on the website or
> > repository that this is happening? And finally, why were the side-effects
> > of this change not considered in the voting discussion[8]?
> >
> > Unfortunately, the list of users affected by this latest change will only
> > continue to grow [9].
> >
> >
> > As a user who depends on the go Thrift library, the current situation is
> > unacceptable, and I'm offering my help to alleviate these issues if it's
> > required (and welcomed), but this should not go on any longer. Engagement
> > with the community is a must. Not doing so is bad for users, is bad for
> > adoption rates, and is unhealthy for the project.
> >
> > My hope is that this feedback is taken as constructive criticism and is
> in
> > no way meant to attack the project. I'm a volunteer as well, and I
> greatly
> > appreciate the effort and time maintainers and contributors put into this
> > project.
> >
> > -Renan
> >
> > [1] http://mail-archives.apache.org/mod_mbox/thrift-dev/201804.mbox/%
> > 3CCAHJqfcLgVZ0JKX2RGRvKkk5ksG9wfjigsscMbwjqmuXwvMPT1A%40mail.gmail.com
> %3E
> > [2] https://github.com/apache/thrift/blob/master/CHANGES
> > [3] https://github.com/apache/thrift/pull/976
> > [4] https://github.com/apache/thrift/pull/1156
> > [5] https://github.com/apache/thrift/pull/1459
> > [6] https://issues.apache.org/jira/browse/THRIFT-4261
> > [7] https://issues.apache.org/jira/browse/THRIFT-4453
> > [8] http://mail-archives.apache.org/mod_mbox/thrift-dev/201803.mbox/%
> > 3CCY4PR2001MB1045B65EB761CD015624C5FAC8AA0%40CY4PR2001MB1045.namprd20.
> > prod.outlook.com%3E
> > [9] https://issues.apache.org/jira/browse/THRIFT-4542
> >
>
Re: Feedback from a maintainer of a project using the go thrift bindings
Posted by Allen George <al...@gmail.com>.
Hi Renan - thanks for reaching out. Note that my comments are personal, and
I'm in no way speaking for the project or its members.
I think your comments can be summarized as follows:
1. Breaking changes are made between releases without enough communication
2. Changes are made without soliciting feedback from the community
3. It's hard to understand what has changed from release to release
4. In this specific instance, the repo change was not communicated to the
user list
On the git issue specifically: personally, unless I work day-to-day with a
language I forget its idiosyncrasies. For example, while I work with Go off
and on, and it totally slipped my mind that imports are tied to actual repo
locations. So, what I thought of as an infrastructure-only change turned
into a larger issue. Second, I can say that what's considered a breaking
change can be a little murky, especially when dealing with code-generation.
There is, as you know, a cost to adding switches and introducing additional
code paths in the thrift compiler. And, sometimes, what seems like an
innocuous change can be depended on by downstream users. This is of course
tougher when you're dealing with many languages, each with their individual
cadences.
That said, I've taken your point about communication to heart, and, for the
languages I work on, will make it a priority to:
- keep a changelog
- solicit feedback from the user list when changing type details etc. wrt.
generated code.
I appreciate your using Thrift, and sending this mail.
Best,
Allen
---
Terminal Musings: http://www.allengeorge.com/
Twitter: https://twitter.com/allenageorge/
Raft in Java: https://github.com/allengeorge/libraft/
Thrift Rust Bindings: https://thrift.apache.org
On Thu, Apr 5, 2018 at 1:03 PM, Renan DelValle <re...@apache.org> wrote:
> Hi all,
>
> I'm a PMC of Apache Aurora, which uses Thrift. As part of my job, I
> maintain separate (from the apache project) thrift go bindings in order to
> interact with Aurora.
>
> Yesterday, I had team members unable to compile my project because,
> suddenly, the Apache git repository for Thrift (git.apache.org/thrift.git)
> went missing.
>
> It took me far too long to find that there was a vote to move from this
> location that was originally taking place in private@[1] (which Jake
> Ferrell thankfully addressed).
> No official announcements were made as far as I can tell.
>
> This lack of communication isn't new as I'm continuously finding out (by
> reading the commit log) about changes that cause breakage between code
> generated by newer versions of Thrift and my codebase.
>
> Taking a look at the thrift/CHANGES[2] for example, the changes for version
> 0.11.0 are not even listed. At the very least there should be release notes
> warning users about breaking changes.
>
> In the past two versions of thrift, three changes broke backwards
> compatibility for go:
>
> * In version 0.10.0, the way sets are represented was changed[3].
>
> * In version 0.11.0, the way sets are represented was changed again[4] and
> context generation was added[5].
>
> These created a ton of work for project maintainers to move from one
> version to another.
>
> When a user brought up the addition of context as breaking change[6], I was
> disappointed to see maintainers seemingly dismiss his concerns instead of
> working to find a solution. For example, one solution is that this change
> could have been set behind a flag, allowing the user the flexibility to
> turn it off. (In fact, I created a JIRA issue to that end a while ago [7].)
>
> I understand there is sometimes no way around making breaking changes
> between versions, but the lack of communication, and the seeming lack of
> concern for changing the generation in a way that breaks existing projects,
> without publicly exploring alternatives, makes it difficult to advocate for
> using Thrift for go based projects.
>
> Now that the location of the git repository changed, code generation is
> broken because all generated files try to import from
> git.apache.org/thrift.git forcing users to upgrade or to use dependency
> management capable of changing the source of this repository.
>
> This change is incredibly impactful, even to users dependent on older
> releases, so I'm curious about why this change was not communicated on the
> user@ list? Further, why is it not listed anywhere on the website or
> repository that this is happening? And finally, why were the side-effects
> of this change not considered in the voting discussion[8]?
>
> Unfortunately, the list of users affected by this latest change will only
> continue to grow [9].
>
>
> As a user who depends on the go Thrift library, the current situation is
> unacceptable, and I'm offering my help to alleviate these issues if it's
> required (and welcomed), but this should not go on any longer. Engagement
> with the community is a must. Not doing so is bad for users, is bad for
> adoption rates, and is unhealthy for the project.
>
> My hope is that this feedback is taken as constructive criticism and is in
> no way meant to attack the project. I'm a volunteer as well, and I greatly
> appreciate the effort and time maintainers and contributors put into this
> project.
>
> -Renan
>
> [1] http://mail-archives.apache.org/mod_mbox/thrift-dev/201804.mbox/%
> 3CCAHJqfcLgVZ0JKX2RGRvKkk5ksG9wfjigsscMbwjqmuXwvMPT1A%40mail.gmail.com%3E
> [2] https://github.com/apache/thrift/blob/master/CHANGES
> [3] https://github.com/apache/thrift/pull/976
> [4] https://github.com/apache/thrift/pull/1156
> [5] https://github.com/apache/thrift/pull/1459
> [6] https://issues.apache.org/jira/browse/THRIFT-4261
> [7] https://issues.apache.org/jira/browse/THRIFT-4453
> [8] http://mail-archives.apache.org/mod_mbox/thrift-dev/201803.mbox/%
> 3CCY4PR2001MB1045B65EB761CD015624C5FAC8AA0%40CY4PR2001MB1045.namprd20.
> prod.outlook.com%3E
> [9] https://issues.apache.org/jira/browse/THRIFT-4542
>
Re: Feedback from a maintainer of a project using the go thrift bindings
Posted by Allen George <al...@gmail.com>.
Hi Renan - thanks for reaching out. Note that my comments are personal, and
I'm in no way speaking for the project or its members.
I think your comments can be summarized as follows:
1. Breaking changes are made between releases without enough communication
2. Changes are made without soliciting feedback from the community
3. It's hard to understand what has changed from release to release
4. In this specific instance, the repo change was not communicated to the
user list
On the git issue specifically: personally, unless I work day-to-day with a
language I forget its idiosyncrasies. For example, while I work with Go off
and on, and it totally slipped my mind that imports are tied to actual repo
locations. So, what I thought of as an infrastructure-only change turned
into a larger issue. Second, I can say that what's considered a breaking
change can be a little murky, especially when dealing with code-generation.
There is, as you know, a cost to adding switches and introducing additional
code paths in the thrift compiler. And, sometimes, what seems like an
innocuous change can be depended on by downstream users. This is of course
tougher when you're dealing with many languages, each with their individual
cadences.
That said, I've taken your point about communication to heart, and, for the
languages I work on, will make it a priority to:
- keep a changelog
- solicit feedback from the user list when changing type details etc. wrt.
generated code.
I appreciate your using Thrift, and sending this mail.
Best,
Allen
---
Terminal Musings: http://www.allengeorge.com/
Twitter: https://twitter.com/allenageorge/
Raft in Java: https://github.com/allengeorge/libraft/
Thrift Rust Bindings: https://thrift.apache.org
On Thu, Apr 5, 2018 at 1:03 PM, Renan DelValle <re...@apache.org> wrote:
> Hi all,
>
> I'm a PMC of Apache Aurora, which uses Thrift. As part of my job, I
> maintain separate (from the apache project) thrift go bindings in order to
> interact with Aurora.
>
> Yesterday, I had team members unable to compile my project because,
> suddenly, the Apache git repository for Thrift (git.apache.org/thrift.git)
> went missing.
>
> It took me far too long to find that there was a vote to move from this
> location that was originally taking place in private@[1] (which Jake
> Ferrell thankfully addressed).
> No official announcements were made as far as I can tell.
>
> This lack of communication isn't new as I'm continuously finding out (by
> reading the commit log) about changes that cause breakage between code
> generated by newer versions of Thrift and my codebase.
>
> Taking a look at the thrift/CHANGES[2] for example, the changes for version
> 0.11.0 are not even listed. At the very least there should be release notes
> warning users about breaking changes.
>
> In the past two versions of thrift, three changes broke backwards
> compatibility for go:
>
> * In version 0.10.0, the way sets are represented was changed[3].
>
> * In version 0.11.0, the way sets are represented was changed again[4] and
> context generation was added[5].
>
> These created a ton of work for project maintainers to move from one
> version to another.
>
> When a user brought up the addition of context as breaking change[6], I was
> disappointed to see maintainers seemingly dismiss his concerns instead of
> working to find a solution. For example, one solution is that this change
> could have been set behind a flag, allowing the user the flexibility to
> turn it off. (In fact, I created a JIRA issue to that end a while ago [7].)
>
> I understand there is sometimes no way around making breaking changes
> between versions, but the lack of communication, and the seeming lack of
> concern for changing the generation in a way that breaks existing projects,
> without publicly exploring alternatives, makes it difficult to advocate for
> using Thrift for go based projects.
>
> Now that the location of the git repository changed, code generation is
> broken because all generated files try to import from
> git.apache.org/thrift.git forcing users to upgrade or to use dependency
> management capable of changing the source of this repository.
>
> This change is incredibly impactful, even to users dependent on older
> releases, so I'm curious about why this change was not communicated on the
> user@ list? Further, why is it not listed anywhere on the website or
> repository that this is happening? And finally, why were the side-effects
> of this change not considered in the voting discussion[8]?
>
> Unfortunately, the list of users affected by this latest change will only
> continue to grow [9].
>
>
> As a user who depends on the go Thrift library, the current situation is
> unacceptable, and I'm offering my help to alleviate these issues if it's
> required (and welcomed), but this should not go on any longer. Engagement
> with the community is a must. Not doing so is bad for users, is bad for
> adoption rates, and is unhealthy for the project.
>
> My hope is that this feedback is taken as constructive criticism and is in
> no way meant to attack the project. I'm a volunteer as well, and I greatly
> appreciate the effort and time maintainers and contributors put into this
> project.
>
> -Renan
>
> [1] http://mail-archives.apache.org/mod_mbox/thrift-dev/201804.mbox/%
> 3CCAHJqfcLgVZ0JKX2RGRvKkk5ksG9wfjigsscMbwjqmuXwvMPT1A%40mail.gmail.com%3E
> [2] https://github.com/apache/thrift/blob/master/CHANGES
> [3] https://github.com/apache/thrift/pull/976
> [4] https://github.com/apache/thrift/pull/1156
> [5] https://github.com/apache/thrift/pull/1459
> [6] https://issues.apache.org/jira/browse/THRIFT-4261
> [7] https://issues.apache.org/jira/browse/THRIFT-4453
> [8] http://mail-archives.apache.org/mod_mbox/thrift-dev/201803.mbox/%
> 3CCY4PR2001MB1045B65EB761CD015624C5FAC8AA0%40CY4PR2001MB1045.namprd20.
> prod.outlook.com%3E
> [9] https://issues.apache.org/jira/browse/THRIFT-4542
>