thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen George <allen.geo...@gmail.com>
Subject Re: Feedback from a maintainer of a project using the go thrift bindings
Date Fri, 06 Apr 2018 02:33:47 GMT
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 <renan@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message