Re: [VOTE] Apache Thrift 0.20.0-rc1 release candidate

[Duru Can Celasun]

+1

On Thu, 14 Mar 2024, at 20:21, Yuxuan Wang wrote:
> +1
>
> On Tue, Mar 12, 2024 at 3:13 PM Jens Geyer  wrote:
>
>> All,
>>
>> I propose that we accept the following release candidate as the official
>> Apache Thrift 0.20.0 release:
>>
>>
>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.tar.gz___.YzJ1OnJlZGRpdDpjOmc6MWUzM2Y1MmZiNmQ0NjZmNDhhYzc2ODMyYWUwZTdlNjQ6NjphYWZiOjZkZmI1ZGQ4NzVkM2Q4MWM2MThmNTc4NDBlNTczZGI2OWQyZTI0ZDdkZDVjZDk0NTg3NmVkN2E1ZDk5MmNmMGE6cDpU
>>
>> The release candidate was created from the release/0.20.0 branch and can
>> be cloned using:
>>
>> git clone -b release/0.20.0
>> https://protect.checkpoint.com/v2/___https://github.com/apache/thrift.git___.YzJ1OnJlZGRpdDpjOmc6MWUzM2Y1MmZiNmQ0NjZmNDhhYzc2ODMyYWUwZTdlNjQ6NjphZWZhOmM3NDAwYjU5NTQxZjRjZTc4YjIzMjA1Mjg1NjllM2VkZWFkMWFkOGMwNDgzODhmMTNhYzlmMjMzNTQxN2MyMDQ6cDpU
>>
>> The release candidates GPG signature can be found at:
>>
>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.tar.gz.asc___.YzJ1OnJlZGRpdDpjOmc6MWUzM2Y1MmZiNmQ0NjZmNDhhYzc2ODMyYWUwZTdlNjQ6NjozMWVlOjlhMzA2ZTYwY2IwMzFiYmNlM2MwNjBjMGViOGVmYmM1YzcyNjExNDg1NjlmMDJiMTNlYjA3ZDA3YmQzMWFhMTk6cDpU
>>
>> The release candidates checksums are:
>> md5: aadebde599e1f5235acd3c730721b873
>> sha1: 08330d85fa037440d5b0873aa18edd654194483c
>> sha256: b5d8311a779470e1502c027f428a1db542f5c051c8e1280ccd2163fa935ff2d6
>>
>> A prebuilt statically-linked Windows compiler is available at:
>>
>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.exe___.YzJ1OnJlZGRpdDpjOmc6MWUzM2Y1MmZiNmQ0NjZmNDhhYzc2ODMyYWUwZTdlNjQ6NjoyNWViOjI1MDU1ZjNkMmIzNTExYjVmMjFkNTFhZGU5NzhkMmE1NGRmNTMyNTFkMzlkMzg4YmQ4ODA5ZWQwYTE2YWVlNmI6cDpU
>>
>> Prebuilt statically-linked Windows compiler GPG signature:
>>
>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.exe.asc___.YzJ1OnJlZGRpdDpjOmc6MWUzM2Y1MmZiNmQ0NjZmNDhhYzc2ODMyYWUwZTdlNjQ6NjoxODZmOjNmMjg3NzMyYjg4NmM5Y2RjN2U3ZjMwOTFiYTM1YjUyNTljZmNkZjlmN2ViMWEyNzhmMjUwMTIxZDEyNWMzMDA6cDpU
>>
>> Prebuilt statically-linked Windows compiler checksums are:
>>
>> md5: e867efb609da1f89a77a078c79d435b9
>> sha1: 1268712650a525a70125e96ddeb47035b1dfdbb7
>> sha256: 7e554be788b6f1fddb05d2be2a3cd2dc853075218c937adb9e9b834959c9c060
>>
>> The CHANGES list for this release is available at:
>>
>> https://protect.checkpoint.com/v2/___https://github.com/apache/thrift/blob/0.20.0/CHANGES.md___.YzJ1OnJlZGRpdDpjOmc6MWUzM2Y1MmZiNmQ0NjZmNDhhYzc2ODMyYWUwZTdlNjQ6NjoxYjRmOmE2OTZhYjJjZDBhZGMyNzk0YmY1MGM1Njg4MWY4ZDAwMjIyOWMzNmY4NzQ4ODYxZWViZjVmNjE4NGFkOWM1MDQ6cDpU
>>
>> Please download, verify sig/sum, install and test the libraries and
>> languages of your choice.
>>
>>
>> I start this voting thread with my own +1 vote.
>>
>>
>> This vote will close in 145 hours on 2024-02-19 00:00 UTC
>>
>> https://protect.checkpoint.com/v2/___https://www.timeanddate.com/countdown/generic?iso=20240319T=1440___.YzJ1OnJlZGRpdDpjOmc6MWUzM2Y1MmZiNmQ0NjZmNDhhYzc2ODMyYWUwZTdlNjQ6NjowMjZkOjFlOTI1ZTNiMmQzMGFkNzY2OWQ5YzAwNTI4NzAxZTE2NTY2NTVlODVlZGQyM2U0Nzg3ODNmOWE5Yzc4YTliNmI6cDpU
>>
>> [ ] +1 Release this as Apache Thrift 0.20.0
>> [ ] +0
>> [ ] -1 Do not release this as Apache Thrift 0.20.0 because...
>>
>> Have fun,
>> JensG
>>
>>
>>
>>

[jira] [Commented] (THRIFT-3037) Can not build Go code when using typedef in IDL

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790269#comment-17790269
 ] 

Duru Can Celasun commented on THRIFT-3037:
--

You should be able to do it yourself. From the right sidebar: People -> 
Assignee -> Assign to me.

It doesn't really matter anyway.

> Can not build Go code when using typedef in IDL
> ---
>
> Key: THRIFT-3037
> URL: https://issues.apache.org/jira/browse/THRIFT-3037
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.9.2
>Reporter: Joe Bruner
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
> // Base.thrift
> namespace go a.X.c
> struct Foo {
> 1: required string s
> }
> {code}
> and the dependent file
> {code}
> // Child.thrift
> namespace go a.Y.c
> include "Base.thrift"
> typedef Base.Foo Foo // < This is what causes the problem
> struct Bar {
> 1:Foo f  // <-- Will error
> // 1:Base.Foo f   Need to comment out typedef and use this instead
> }
> {code}
> Compiling the thrift as is works, but when you go to install the a.Y.c 
> package will produce:
> {code}
> /scratch/go/src/a/Y/c/ttypes.go:78: cannot use c.Foo literal (type *c.Foo) as 
> type *Foo in assignment
> /scratch/go/src/a/Y/c/ttypes.go:79: p.F.Read undefined (type *Foo has no 
> field or method Read)
> /scratch/go/src/a/Y/c/ttypes.go:105: p.F.Write undefined (type *Foo has no 
> field or method Write)
> {code}
> If I comment out the typedef and swap the lines in Bar then everything works 
> fine. This appears to only happen in Go.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (THRIFT-3037) Can not build Go code when using typedef in IDL

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun reassigned THRIFT-3037:


Assignee: (was: Duru Can Celasun)

> Can not build Go code when using typedef in IDL
> ---
>
> Key: THRIFT-3037
> URL: https://issues.apache.org/jira/browse/THRIFT-3037
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.9.2
>Reporter: Joe Bruner
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {code}
> // Base.thrift
> namespace go a.X.c
> struct Foo {
> 1: required string s
> }
> {code}
> and the dependent file
> {code}
> // Child.thrift
> namespace go a.Y.c
> include "Base.thrift"
> typedef Base.Foo Foo // < This is what causes the problem
> struct Bar {
> 1:Foo f  // <-- Will error
> // 1:Base.Foo f   Need to comment out typedef and use this instead
> }
> {code}
> Compiling the thrift as is works, but when you go to install the a.Y.c 
> package will produce:
> {code}
> /scratch/go/src/a/Y/c/ttypes.go:78: cannot use c.Foo literal (type *c.Foo) as 
> type *Foo in assignment
> /scratch/go/src/a/Y/c/ttypes.go:79: p.F.Read undefined (type *Foo has no 
> field or method Read)
> /scratch/go/src/a/Y/c/ttypes.go:105: p.F.Write undefined (type *Foo has no 
> field or method Write)
> {code}
> If I comment out the typedef and swap the lines in Bar then everything works 
> fine. This appears to only happen in Go.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5745) go: Implement slog.LogValuer for exceptions and/or structs

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787407#comment-17787407
 ] 

Duru Can Celasun commented on THRIFT-5745:
--

The Stringer implementation has been a long time source of pain for us as well, 
so I think this is a good idea. I wouldn't make it optional. And yes, let's add 
it to structs as well.

> go: Implement slog.LogValuer for exceptions and/or structs
> --
>
> Key: THRIFT-5745
> URL: https://issues.apache.org/jira/browse/THRIFT-5745
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Compiler
>Reporter: Yuxuan Wang
>Priority: Major
>
> To follow up on THRIFT-5744, implement 
> [slog.LogValuer|https://pkg.go.dev/log/slog#LogValuer] on compiler generated 
> exceptions, and maybe also structs.
> The current problem is that when logging an exception, the Stringer 
> implementation will be used, but that usually gives you quite unhelpful 
> string, especially when optional fields are used.
> For example we have [this exception 
> defined|https://github.com/reddit/baseplate.py/blob/8c446337dab6a1692900decf9cd01f3f4e39d764/baseplate/thrift/baseplate.thrift#L197]:
> {code:java}
> exception Error {
> 1: optional i32 code
> 2: optional string message
> 3: optional map details
> 4: optional bool retryable
> }
> {code}
> When you create an instance of it:
> {code:go}
> return {
>   Code: thrift.Int32Ptr(404),
>   Message: thrift.Pointer("no such id"),
> }
> {code}
> And then log that error, instead of getting something useful with the code 
> (404) and message ("no such id") in it, you get something like this instead 
> because this is how we implemented fmt.Stringer from the compiler:
> {code:go}
> Error({Code:0xc000426648 Message:0xc00041ca10 Details:map[] Retryable:})
> {code}
> The compiler generates implementation for json.Marshaler for all exceptions, 
> which will be much more helpful. The marshaled json for such error would be:
> {code:json}
> {"code":400,"message":"no such id"}
> {code}
> They are also much more expensive, so probably not suitable to replace the 
> current Stringer implementation, but when logging them, it's probably worth 
> it to implement slog.LogValuer so we can log something more useful, probably 
> like this:
> {code:go}
> func (p *Error) LogValue() slog.Value{
>   var sb strings.Builder
>   sb.WriteString("baseplate.Error")
>   bytes, err := json.Marshal(p)
>   if err != nil {
> // should not happen
> return slog.StringValue(fmt.Sprintf("baseplate.Error.LogValue: failed to 
> marshal json: %v", err))
>   }
>   sb.Write(bytes)
>   return slog.StringValue(sb.String())
> }
> {code}
> Which will make the error logged show as:
> {code:json}
> baseplate.Error{"code":400,"message":"no such id"}
> {code}
> Some open questions:
> # Is this also useful for structs?
> # Do we want to make this optional (e.g. only generate LogValue function when 
> a compiler flag is passed in)?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5744) Proposal: Switch all go logging in the library to slog

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787349#comment-17787349
 ] 

Duru Can Celasun commented on THRIFT-5744:
--

I haven't had a chance to use slog at scale (we use zap) but it's clearly an 
improvement over status quo for thrift. Let's go for it.

> Proposal: Switch all go logging in the library to slog
> --
>
> Key: THRIFT-5744
> URL: https://issues.apache.org/jira/browse/THRIFT-5744
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
>
> In the go library, we used to use the stdlib [log|https://pkg.go.dev/log] 
> library to do logging. Then in THRIFT-4985 we added a simple wrapper 
> interface, Logger, to replace all the logging usage in the library code.
> This Proposal is that we switch all internal logging to stdlib 
> [slog|https://pkg.go.dev/log/slog] (after go 1.22 release so our minimal 
> supported go version is at least 1.21 and has slog in stdlib), and 
> deprecate/remove the Logger wrapper interface.
> In the current go library code, there are 2 places logging is used:
> # TDebugProtocol: with this proposal we should switch them to 
> slog.DebugContext
> # TSimpleServer: we log errors from processRequests, so with this proposel we 
> should switch them to slog.ErrorContext, and also add a SetBaseContext api to 
> TSimpleServer so a base context can be set to be used in that logging
> The original, stdlib log approach, didn't work out well because the API of it 
> is too limited (no log level, no context, no structured logging/kv pair 
> ability, etc.), resulting in a lot of third-party logging library 
> implementations cannot be adapted to the stdlib log api (even when some of 
> them, for example zap, provided a way to replace the default log logger to be 
> zap backend, because of the limitation of the api a lot of the features like 
> log level and kv pairs are still unusable with log api), resulting in mixed 
> logging in applications.
> The Logger wrapper interface resolved the mixed logging issue, but its API is 
> still very limited (it's a common denominator approach), so it still have 
> issues like lack of fine grain control of the logging, and performance (see 
> THRIFT-5539, because the lack of log level we cannot skip the Sprintf used by 
> TDebugProtocol when we don't need the logging, resulting in us forking out 
> TDuplicateToProtocol).
> The new slog stdlib is go team's answer to the fragmentation of logging 
> library issue in the go ecosystem, and it does have a really good chance to 
> really unite all the logging libraries once and for all:
> * The context in logging calls provides the ability to: 1) attach context kv 
> pairs automatically (trace id, etc.); 2) control minimal log level (you can 
> provide a ctx before calling thrift code that could do potential logging to 
> raise/lower minimal log level as needed); 3) or even do additional log 
> suppressing logic based on the context
> * Even if some developers still prefer zap/zerolog/etc. for their performance 
> (zap still claims to be faster than slog, for example), there are wrapper 
> libraries to set the default slog handler to a zap/zerolog/etc. 
> implementation so they still have uniformed logging, and the new API from 
> slog means that they can still preserve the majority of the features from 
> those third party logging libraries.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Apache Thrift 0.19.0-rc1 release candidate

[Duru Can Celasun]

+1

On Wed, 30 Aug 2023, at 17:39, Yuxuan Wang wrote:
> +1
>
> On Sun, Aug 27, 2023 at 7:22 AM Jens Geyer  wrote:
>
>> All,
>>
>> I propose that we accept the following release candidate as the official
>> Apache Thrift 0.19.0 release:
>>
>>
>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc1/thrift-0.19.0.tar.gz___.YzJ1OnJlZGRpdDpjOmc6ZTI2NzUwNGNjZjAwNTRkZjk5ZTIzNWZiODE3YmRmNGE6NjplMjQwOmU0NTEwZjkyODJhNGM4YTI5OGE4NjI1ZGNiZjU0NTc3YTZkZmE2MWQ3ODc2NGVlNzM3N2ZmMzcwZTMxOWE2YzY6cDpU
>>
>> The release candidate was created from the release/0.19.0 branch and can
>> be cloned using:
>>
>> git clone -b release/0.19.0
>> https://protect.checkpoint.com/v2/___https://github.com/apache/thrift.git___.YzJ1OnJlZGRpdDpjOmc6ZTI2NzUwNGNjZjAwNTRkZjk5ZTIzNWZiODE3YmRmNGE6NjozMGFjOjQwMmQ0Njg2MWU5MTZkMTE0NTk3M2RiOTFjNmJjMDg2MTgzZTg3OWViYTgwMjk0MzA1YjE5MTQ4YzMwNTY5MTY6cDpU
>>
>> The release candidates GPG signature can be found at:
>>
>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc1/thrift-0.19.0.tar.gz.asc___.YzJ1OnJlZGRpdDpjOmc6ZTI2NzUwNGNjZjAwNTRkZjk5ZTIzNWZiODE3YmRmNGE6NjpiY2YzOjJjYmJlMGRmOTMyMjQ2MjIyZTk0MDBhOTNmMWQ1NWI1NDRhZGVmZmNlZGE2ZGUxMWIyMTkwZDZmMWIyMDQ1NTQ6cDpU
>>
>> The release candidates checksums are:
>> md5: f2074232cd80c83f30c030cb69ef68a8
>> sha1: 8b3f52e7645e3374669d523bcaa433ed8962aa75
>> sha256: d49c896c2724a78701e05cfccf6cf70b5db312d82a17efe951b441d300ccf275
>>
>>
>> A prebuilt statically-linked Windows compiler is available at:
>>
>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc1/thrift-0.19.0.exe___.YzJ1OnJlZGRpdDpjOmc6ZTI2NzUwNGNjZjAwNTRkZjk5ZTIzNWZiODE3YmRmNGE6NjplMmE4OjcyNDM3NzdkZjVlOGQxOTVlMzgwMTViZGRkMjI0MzU5MTQ1NGQ5MjJjZjFkNDhhZjYwMTU2ODA0OGRiYTgxNzI6cDpU
>>
>> Prebuilt statically-linked Windows compiler GPG signature:
>>
>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc1/thrift-0.19.0.exe.asc___.YzJ1OnJlZGRpdDpjOmc6ZTI2NzUwNGNjZjAwNTRkZjk5ZTIzNWZiODE3YmRmNGE6NjpkOTZiOmUyNDZlNmQ4MDAyYjhhYTBiNmNhZDBmZTdhYmM2MDE2ZmI4MDE5MmNhMDdhODA1MTQ1MzlkNzdkYTVmZWVmZDY6cDpU
>>
>> Prebuilt statically-linked Windows compiler checksums are:
>> md5: 73870121ae5fa18510f4605af03188fc
>> sha1: c14214f8f28150428b83735b7a44bb8deeb3d0e8
>> sha256: ae87e34c459447c723ef705faa5cde40edfb699f1bb9452cebb94c7bfef7f5ab
>>
>>
>> The CHANGES list for this release is available at:
>>
>> https://protect.checkpoint.com/v2/___https://github.com/apache/thrift/blob/0.19.0/CHANGES.md___.YzJ1OnJlZGRpdDpjOmc6ZTI2NzUwNGNjZjAwNTRkZjk5ZTIzNWZiODE3YmRmNGE6NjpjZTFlOjY4ZjIxY2M0NTc4YmQ5ZDVlN2QwZjY5ZjIwMjU3OTUyZDQ0YzM3ZWI2YmY3ZmExNWE0YjhjMDQ2OGYxYTc4NzU6cDpU
>>
>>
>> Please download, verify sig/sum, install and test the libraries and
>> languages of your choice.
>>
>> This vote will close in 129 hours on 2023-09-02 00:00 UTC
>>
>> https://protect.checkpoint.com/v2/___https://www.timeanddate.com/countdown/generic?iso=20230902T=1440___.YzJ1OnJlZGRpdDpjOmc6ZTI2NzUwNGNjZjAwNTRkZjk5ZTIzNWZiODE3YmRmNGE6Njo3NzJiOjM4ZGY5MTM2ZDdjNWJjMTgyNTY1MzM0YThiOTRjZmQwYmNjZjY0ZGFlMzI5YTgxNDU4NWQ0NjFhNWE4ZDhkYmM6cDpU
>>
>> [ ] +1 Release this as Apache Thrift 0.19.0
>> [ ] +0
>> [ ] -1 Do not release this as Apache Thrift 0.19.0 because...
>>
>>
>> Have fun,
>> JensG
>>

Re: [VOTE] Apache Thrift 0.19.0-rc0 release candidate

[Duru Can Celasun]

+1

We've been using this RC in production for about a week with no issues.

On Mon, 7 Aug 2023, at 18:19, Yuxuan Wang wrote:
> +1.
>
> We tested the go compiler/lib but didn't finish the python test in time but
> don't want to hold this forever.
>
> Also there's a new RC for go1.21 so I don't want that to hold this release
> forever as well.
>
> Sorry for the late vote.
>
> On Tue, Jul 18, 2023 at 4:14 PM Yuxuan Wang  wrote:
>
>> Thanks for the work, Jens!
>>
>> We already tested the RC version on a go service in our environment. We
>> also have another team to try to test the RC version on a python service,
>> but that's more challenging (especially for an unreleased version that
>> there's no pre-built python packages) so it might take a few more days.
>>
>> Another thing that's not really a release blocker but I would prefer to
>> wait for a little bit is https://github.com/apache/thrift/pull/2821,
>> which depends on the release of Go 1.21. There was go 1.21-rc2 from June 21
>> and -rc3 from July 14, so I would expect the actual release will happen
>> very soon, and it would be great to wait a bit and align our releases
>> (since we both have similar release cadence of twice a year).
>>
>> On Sat, Jul 15, 2023 at 3:20 AM Jens Geyer  wrote:
>>
>>> All,
>>>
>>> I propose that we accept the following release candidate as the official
>>> Apache Thrift 0.19.0 release:
>>>
>>>
>>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc0/thrift-0.19.0.tar.gz___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6NjoyZTU4OmQ0Yzk5YTQzZTViOTk2Njc5YjA3NzcwZTA2ZmNhZjFjZjM0ODdjMmM3MWJhYWI0ZjA1ZjI0ZjAwZWJhNTBkNzE6cDpU
>>>
>>> The release candidate was created from the release/0.19.0 branch and can
>>> be cloned using:
>>>
>>> git clone -b release/0.19.0
>>> https://protect.checkpoint.com/v2/___https://github.com/apache/thrift.git___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6NjowZDM0OjI3YmY2NzVjZjhjNjhjMTVjNTllYjQ4NzNlYmU4MDM4NzkxOTBjZDMxZTFkMDUwNTc1YjM5MmIzYzJjMDQzMDI6cDpU
>>>
>>> The release candidates GPG signature can be found at:
>>>
>>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc0/thrift-0.19.0.tar.gz.asc___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6NjplZGMzOmI0YWM4OGI1MGU0MTFkNTJkZjlkMGVlYzk5ZmNlNGRiN2RmODMyZmIwNzcxMWI2YjFhMzIwMjcwOWI1ZjcwNjY6cDpU
>>>
>>> The release candidates checksums are:
>>> md5: d1f7f19a23e1830f83052c050156cebc
>>> sha1: f06f3a281bb41eed789d0e88d8a1b35405c664a8
>>> sha256: c5a6ac0aca3bf1fd8a2f6afffc24bdf247cd8188480222c89f14a7900f7d6a51
>>>
>>>
>>> A prebuilt statically-linked Windows compiler is available at:
>>>
>>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc0/thrift-0.19.0.exe___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6Njo5NDIzOjUxNTRlM2IxMDlmY2VjOWY5OWM4NjVjNzQzNmM2NTE1NTJmNzdmMmRlMGMyOTNlOGEzOTQ1MTk2MjJhZDFlMWI6cDpU
>>>
>>> Prebuilt statically-linked Windows compiler GPG signature:
>>>
>>> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc0/thrift-0.19.0.exe.asc___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6Njo5YWQ3OjFhNjNmZGZjNmJiM2YxODY2ODAxNmY4NGFjYWYzYjdkNmNjMWNjNTA5OWJhYzVmZjdhZWExYTI1ZDQ4ZDExMzA6cDpU
>>>
>>> Prebuilt statically-linked Windows compiler checksums are:
>>> md5: cf4a7d003893c4503fc7105aef0259ca
>>> sha1: d0e67bb8c89ee557614fd9e1e0f3086ff67164c9
>>> sha256: 1f1ce1658df1226a35dc6a6318da6d534328e24f3c99da4dee847eb57654401d
>>>
>>>
>>> The CHANGES list for this release is available at:
>>>
>>> https://protect.checkpoint.com/v2/___https://github.com/apache/thrift/blob/0.19.0/CHANGES.md___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6NjoyZjVkOjkxMDkwNjY1YjU4MDQ1NWRjNmFhM2ZiM2Q1MGY1NzhlOGFhZDU3MDEwY2Q1ODAwMzNlYzMwZjIwYmI3ZTRmOWI6cDpU
>>>
>>>
>>> Please download, verify sig/sum, install and test the libraries and
>>> languages of your choice.
>>>
>>> This vote will close in 109 hours on 2023-07-20 00:00 UTC
>>>
>>> https://protect.checkpoint.com/v2/___https://www.timeanddate.com/countdown/generic?iso=20230720T=1440___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6NjpkOGMzOjNiOTY1ZTZkNjcwNzVlOGU0OTc2N2EyOTcxNzYwNDI0ZDUwN2E5M2M2ODEwMzFmZTM2NWNiNGZmNjMwNjY5NDg6cDpU
>>>
>>> [ ] +1 Release this as Apache Thrift 0.19.0
>>> [ ] +0
>>> [ ] -1 Do not release this as Apache Thrift 0.19.0 because...
>>>
>>>
>>> Have fun,
>>> JensG
>>>
>>

Re: [VOTE] Apache Thrift 0.18.1-rc0 release candidate

[Duru Can Celasun]

+1

On Thu, 23 Feb 2023, at 21:31, Jens Geyer wrote:
> @all,
>
> I propose that we accept the following release candidate as the official 
> Apache Thrift 0.18.1 release:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.tar.gz
>
> The release candidate was created from the release/0.18.1 branch and can 
> be cloned using:
>
> git clone -b release/0.18.1 https://github.com/apache/thrift.git
>
> The release candidates GPG signature can be found at:
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.tar.gz.asc
>
> The release candidates checksums are:
> md5: 44f788bf18f85851847d49fa14786a96
> sha1: eac2a46a2d09df7f7cc25c687b066f0803d4e770
> sha256: 04c6f10e5d788ca78e13ee2ef0d2152c7b070c0af55483d6b942e29cff296726
>
>
> A prebuilt statically-linked Windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.exe
>
> Prebuilt statically-linked Windows compiler GPG signature:
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.exe.asc
>
> Prebuilt statically-linked Windows compiler checksums are:
> md5: ac14f6c20558f1264ea57723f5183e18
> sha1: dca5abbc27031c3a91b6dc572bf7beed01e65511
> sha256: d9a9c54268ad982dcfd0f0485084acce73278a281813593234b4bad9c5d31044
>
>
> The CHANGES list for this release is available at:
> https://github.com/apache/thrift/blob/0.18.1/CHANGES.md
>
>
> Please download, verify sig/sum, install and test the libraries and 
> languages of your choice.
>
> This vote will close in 122 hours on 2023-03-01 00:00 UTC
> https://www.timeanddate.com/countdown/generic?iso=20230301T=1440
>
> [ ] +1 Release this as Apache Thrift 0.18.1
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.18.1 because...
>
> Have fun,
> JensG

Re: [VOTE] Apache Thrift 0.18.0-rc0 release candidate

[Duru Can Celasun]

+1

On Tue, 7 Feb 2023, at 20:50, Yuxuan Wang wrote:
> +1
>
> On Mon, Feb 6, 2023 at 4:12 PM Jens Geyer  wrote:
>
>> All,
>>
>> I propose that we accept the following release candidate as the official
>> Apache Thrift 0.18.0 release:
>>
>>
>> https://dist.apache.org/repos/dist/dev/thrift/0.18.0-rc0/thrift-0.18.0.tar.gz
>>
>> The release candidate was created from the release/0.18.0 branch and can
>> be cloned using:
>>
>> git clone -b release/0.18.0 https://github.com/apache/thrift.git
>>
>> The release candidates GPG signature can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/thrift/0.18.0-rc0/thrift-0.18.0.tar.gz.asc
>>
>> The release candidates checksums are:
>> md5: f1b607c6d1cf8d87390dc5f1fb46c9b5
>> sha1: ee79ca962aadcb9186a6b8ed6370891bde0121e3
>> sha256: 7c19389cb7910a20e58b8e46903c8c1a36353008f9fcc1b03f748accf9b5f3e1
>>
>>
>> A prebuilt statically-linked Windows compiler is available at:
>> https://dist.apache.org/repos/dist/dev/thrift/0.18.0-rc0/thrift-0.18.0.exe
>>
>> Prebuilt statically-linked Windows compiler GPG signature:
>>
>> https://dist.apache.org/repos/dist/dev/thrift/0.18.0-rc0/thrift-0.18.0.exe.asc
>>
>> Prebuilt statically-linked Windows compiler checksums are:
>> md5: 188284499cc74e370b8a208c7b9424b3
>> sha1: ac8bca9020105e18bd548848f657611cac6270c8
>> sha256: 42dd2e4f727d335926c5bd0dfd2013d5af65a410782464144192c8061bfc10bb
>>
>>
>> The CHANGES list for this release is available at:
>> https://github.com/apache/thrift/blob/0.18.0/CHANGES.md
>>
>>
>> Please download, verify sig/sum, install and test the libraries and
>> languages of your choice.
>>
>> This vote will close in 143 hours on 2023-02-13 00:00 UTC
>> https://www.timeanddate.com/countdown/generic?iso=20230213T=1440
>>
>> [ ] +1 Release this as Apache Thrift 0.18.0
>> [ ] +0
>> [ ] -1 Do not release this as Apache Thrift 0.18.0 because...
>>
>>
>>

Re: The UUID change seems to be a big breaking change

[Duru Can Celasun]

Agreed. It seems a new reserved word is unavoidable, so let's at least prefix 
it.

On Fri, 9 Sep 2022, at 18:30, Yuxuan Wang wrote:
> If making it not a reserved word is infeasible, my next suggestion would be
> to rename it to something like "tuuid" (similar to how we prefix t to a lot
> of the names).
>
> It would still be a big breaking change if someone have a thrift file with
> a field/type named tuuid, but that's far less likely compare to the name
> uuid.
>
> On Fri, Sep 9, 2022 at 10:24 AM Yuxuan Wang  wrote:
>
>> I was trying the compiler from the latest master branch, and got this
>> error on one of our existing thrift files:
>>
>> [ERROR:/path/to/file.thrift:182] (last token was 'uuid')
>>
>> The line is basically a field named uuid:
>>
>>   40: optional string uuid,
>>
>> So I think what happens is that uuid is now a reserved word of thrift, and
>> we can no longer use it as the name of a field/struct/etc. (the same as we
>> cannot name a field "string" or "i64")
>>
>> This is a big problem. This means that old thrift file no longer compiles
>> without modification (uuid is likely a commonly used field name right now
>> when we actually needs an uuid there), and renaming an existing field is
>> also a breaking change (it means all the code have to be changed to
>> accommodate the new field name).
>>
>> I'm not sure how feasible it is to make it not a reserved word?
>>

Re: [VOTE] Apache Thrift 0.17.0-rc0 release candidate

[Duru Can Celasun]

+1

On Thu, 8 Sep 2022, at 18:34, Yuxuan Wang wrote:
> +1
>
> On Wed, Sep 7, 2022 at 1:50 PM Jens Geyer  wrote:
>
>> All,
>>
>> I propose that we accept the following release candidate as the official
>> Apache Thrift 0.17.0 release:
>>
>>
>> https://dist.apache.org/repos/dist/dev/thrift/0.17.0-rc0/thrift-0.17.0.tar.gz
>>
>> The release candidate was created from the release/0.17.0 branch and can
>> be cloned using:
>>
>> git clone -b release/0.17.0 https://github.com/apache/thrift.git
>>
>> The release candidates GPG signature can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/thrift/0.17.0-rc0/thrift-0.17.0.tar.gz.asc
>>
>> The release candidates checksums are:
>> md5: 19752476c590a1147ecea610e4fc2b00
>> sha1: e285e13b1a508185682bcbd434ddaddfe1f2d95c
>> sha256: b272c1788bb165d99521a2599b31b97fa69e5931d099015d91ae107a0b0cc58f
>>
>>
>> A prebuilt statically-linked Windows compiler is available at:
>> https://dist.apache.org/repos/dist/dev/thrift/0.17.0-rc0/thrift-0.17.0.exe
>>
>> Prebuilt statically-linked Windows compiler GPG signature:
>>
>> https://dist.apache.org/repos/dist/dev/thrift/0.17.0-rc0/thrift-0.17.0.exe.asc
>>
>> Prebuilt statically-linked Windows compiler checksums are:
>> md5: 3a08c902e490f959c632c28c5199e384
>> sha1: f0010ea6ec1f199c545f873be31d15d0b3b6a1ad
>> sha256: e2406226921e8d2822ec20a199060342398084f130e85fbe1dba0cb1f060e592
>>
>>
>> The CHANGES list for this release is available at:
>> https://github.com/apache/thrift/blob/0.17.0/CHANGES.md
>>
>>
>> Please download, verify sig/sum, install and test the libraries and
>> languages of your choice.
>>
>> This vote will close in 147 hours on 2022-09-17 00:00 UTC
>> https://www.timeanddate.com/countdown/generic?iso=20220914T=1440
>>
>> [ ] +1 Release this as Apache Thrift 0.17.0
>> [ ] +0
>> [ ] -1 Do not release this as Apache Thrift 0.17.0 because...
>>
>>
>>

[jira] [Commented] (THRIFT-5609) TJSONProtocol and TSimpleJSONProtocol are unsafe to be used with TDeserializerPool and TSerializerPool

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17576063#comment-17576063
 ] 

Duru Can Celasun commented on THRIFT-5609:
--

4 is clean and safe, but 2 is cleaner. Can you think of a legitimate use case 
that would be broken by 2? Nothing comes to mind.

> TJSONProtocol and TSimpleJSONProtocol are unsafe to be used with 
> TDeserializerPool and TSerializerPool
> --
>
> Key: THRIFT-5609
> URL: https://issues.apache.org/jira/browse/THRIFT-5609
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.16.0
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
>
> We just realized that when using TJSONProtocol with TDeserializerPool like 
> this:
> {code:go}
> var deserializerPool = thrift.NewTDeserializerPoolSizeFactory(1024, 
> thrift.NewTJSONProtocolFactory())
> {code}
> It only works when it never fails (e.g. it never encounters invalid json 
> blobs). Whenever a failure happens, because of the internal state stack and 
> other states in TJSONProtocol, it will be put back into the pool with the 
> wrong state, and when it's next used it will fail again.
> There are a few approaches we can take to fix it:
> # The simplest "fix" would be just document in TDeserializerPool and 
> TSerializerPool that TJSONProtocol and TSimpleJSONProtocol are not safe to be 
> used, and maybe provide some examples of how to use them (only pool the 
> TMemoryBuffer and recreate TProtocol every time)
> # In TJSONProtocol and TSimpleJSONProtocol's 
> [Read|Write][Message|Struct]Begin, implicitly reset the internal state. But 
> I'm not sure how safe that is
> # Make a breaking change to TProtocol to add a Reset (or maybe ResetState) 
> API to be used by TDeserializer/TSerializer (similar to how they always reset 
> the TMemoryBuffer before doing anything)
> # Similar to 3 but less breaking, just add a Reset/ResetState to 
> TJSONProtocol and TSimpleJSONProtocol (but not TProtocol), and in 
> TDeserializer/TSerializer do a type assertion and call the Reset API on the 
> protocol if it exists.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Apache Thrift 0.16.0-rc2 release candidate

[Duru Can Celasun]

+1



On Thu, 10 Feb 2022, at 18:48, Yuxuan Wang wrote:
> +1
>
> Thanks for all the work, Jens!
>
> On Wed, Feb 9, 2022 at 12:19 PM Jens Geyer  wrote:
>
>>
>> All,
>>
>> I propose that we accept the following release candidate as the official
>> Apache Thrift 0.16.0 release:
>>
>>
>> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc2/thrift-0.16.0.tar.gz
>>
>> The release candidate was created from the release/0.16.0 branch and can
>> be cloned using:
>>
>> git clone -b release/0.16.0 https://github.com/apache/thrift.git
>>
>> The release candidates GPG signature can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc2/thrift-0.16.0.tar.gz.asc
>>
>> The release candidates checksums are:
>> md5: 44cf1b54b4ec1890576c85804acfa637
>> sha1: a4770d0d16851b59b657348d6d167437938dd750
>> sha256: f460b5c1ca30d8918ff95ea3eb6291b3951cf518553566088f3f2be8981f6209
>>
>>
>> A prebuilt statically-linked Windows compiler is available at:
>> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc2/thrift-0.16.0.exe
>>
>> Prebuilt statically-linked Windows compiler GPG signature:
>>
>> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc2/thrift-0.16.0.exe.asc
>>
>> Prebuilt statically-linked Windows compiler checksums are:
>> md5: 9ff1a90f8dd5b1fa73d55990b775a516
>> sha1: 16a85665a095b5924f2d00efe1e7ae4595c1a317
>> sha256: e106135ee72c5328ccf13faa1180570c672d4bb7af44d3f9e34642874474b58a
>>
>>
>> The CHANGES list for this release is available at:
>> https://github.com/apache/thrift/blob/0.16.0/CHANGES.md
>>
>>
>> Please download, verify sig/sum, install and test the libraries and
>> languages of your choice.
>>
>> This vote will close in 123 hours on 2022-02-15 00:00 UTC
>> https://www.timeanddate.com/countdown/generic?iso=20220215T=1440
>>
>> [ ] +1 Release this as Apache Thrift 0.16.0
>> [ ] +0
>> [ ] -1 Do not release this as Apache Thrift 0.16.0 because...
>>
>> PS: Thanks to all that made it possible.
>>
>>
>>

Re: [VOTE] Apache Thrift 0.16.0-rc1 release candidate

[Duru Can Celasun]

+1

On Sat, 5 Feb 2022, at 21:56, Mario Emmenlauer wrote:
> Thanks a lot Jens! +1 from my side, and keep up the good work!
>
> Happy evening,
>
> Mario
>
>
> On 04.02.22 23:10, Jens Geyer wrote:
>> All,
>> 
>> I propose that we accept the following release candidate as the official 
>> Apache Thrift 0.16.0 release:
>> 
>> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc1/thrift-0.16.0.tar.gz
>> 
>> The release candidate was created from the release/0.16.0 branch and can be 
>> cloned using:
>> 
>> git clone -b release/0.16.0 https://github.com/apache/thrift.git
>> 
>> The release candidates GPG signature can be found at:
>> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc1/thrift-0.16.0.tar.gz.asc
>> 
>> The release candidates checksums are:
>> md5: b57857fe9f32f4cdeb8368ed74b6f5d1
>> sha1: 750ef4d74f5a863bf1431fa1a64b346a1e2ff0d3
>> sha256: 036894dc05d439889f2a302db95af44f7e2aea64d6b17014b2c941df2798b1b3
>> 
>> 
>> A prebuilt statically-linked Windows compiler is available at:
>> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc1/thrift-0.16.0.exe
>> 
>> Prebuilt statically-linked Windows compiler GPG signature:
>> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc1/thrift-0.16.0.exe.asc
>> 
>> Prebuilt statically-linked Windows compiler checksums are:
>> md5: 574fb28bcec48a27f3e911f3dab23b99
>> sha1: ee2692de1f38aa45d285709d177c92d490e9ac73
>> sha256: 18f055010bc67ed59b824d8fe41a67dc083177bb6ccd7787499123a04f33f870
>> 
>> 
>> The CHANGES list for this release is available at:
>> https://github.com/apache/thrift/blob/0.16.0/CHANGES.md
>> 
>> 
>> Please download, verify sig/sum, install and test the libraries and 
>> languages of your choice.
>> 
>> This vote will close in 121 hours on 2022-02-10 00:00 UTC
>> https://www.timeanddate.com/countdown/generic?iso=20220210T=1440
>> 
>> [ ] +1 Release this as Apache Thrift 0.16.0
>> [ ] +0
>> [ ] -1 Do not release this as Apache Thrift 0.16.0 because...
>> 
>> 
>> 
>
>
>
> Viele Grüße,
>
> Mario Emmenlauer
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/

[jira] [Commented] (THRIFT-5509) Potential connection leaks caused by the connectivity check

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486650#comment-17486650
 ] 

Duru Can Celasun commented on THRIFT-5509:
--

Option 2, definitely.

> Potential connection leaks caused by the connectivity check
> ---
>
> Key: THRIFT-5509
> URL: https://issues.apache.org/jira/browse/THRIFT-5509
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Affects Versions: 0.15.0
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
>
> Historically, for a TTransport, IsOpen returns true means that the connection 
> is already explicitly closed. So third party code (for example, client pool 
> management logic) could just throw the connection away after IsOpen returned 
> false without worry.
> But since the adding of connectivity check in go library (first release 
> version 0.14.0), that is no longer true: IsOpen could return true when the 
> remote closed the connection, and in such cases Close shall still be 
> explicitly called. If we just throw the connection away without explicitly 
> calling Close, the action of "throw away the connection" will cause 
> connection leaks.
> There are 2 ways to mitigate it:
>  # Document in IsOpen that IsOpen returning false does not necessarily mean 
> the connection is already closed, and an explicit Close call is still needed.
>  # Implicitly call Close inside IsOpen when connectivity check fails. This 
> way we keep the assumption that IsOpen returns false means Close was already 
> called being true.
> [~dcelasun] what's your preference between the 2 paths?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: Drop support of Python 2?

[Duru Can Celasun]

On Fri, 7 Jan 2022, at 21:27, Yuxuan Wang wrote:
> According to https://www.python.org/doc/sunset-python-2/, support for
> Python 2 was stopped from 2020-01-01, which is already more than two years
> ago from now. Is there any reason that thrift should continue to support
> Python 2 in the newer versions?
>
> If there's no objections I would like to remove python 2 from CI
> configuration and docs (for example, LANGUAGES.md).
>
> If JIRA is a better place to discuss this than the maillist I can move the
> discussion there as well.
>
> (This came up as we found out that a fix we did for Python 3 failed the
> Python 2 tests. That in itself is not a very big deal that we can make the
> tests to work for both 2 and 3, but continuing support something that's
> already dropped by upstream for 2 years doesn't really make much sense to
> me.)

+1 for dropping it. The wire formats have been stable for a very long time and 
anyone who needs Python 2 support can stick to 0.15 without worrying about 
compatibility.

Re: [VOTE] Apache Thrift 0.15.0-rc0 release candidate

[Duru Can Celasun]

+1



On Wed, 8 Sep 2021, at 01:31, Yuxuan Wang wrote:
> +1
> 
> On Sat, Sep 4, 2021 at 1:01 PM Jens Geyer  wrote:
> 
> > All,
> >
> > I propose that we accept the following release candidate as the official
> > Apache Thrift 0.15.0 release:
> >
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.15.0-rc0/thrift-0.15.0.tar.gz
> >
> > The release candidate was created from the 0.15.0 branch and can be cloned
> > using:
> >
> > git clone -b 0.15.0 https://github.com/apache/thrift.git
> >
> > The release candidates GPG signature can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.15.0-rc0/thrift-0.15.0.tar.gz.asc
> >
> > The release candidates checksums are:
> > md5: 81954d55567e2996ba186f8776aa8b1b
> > sha1: a2f9f2bc3db1f045c1e2d429a8951912fb2d253b
> > sha256: d5883566d161f8f6ddd4e21f3a9e3e6b8272799d054820f1c25b11e86718f86b
> >
> >
> > A prebuilt Windows compiler is available at:
> > https://dist.apache.org/repos/dist/dev/thrift/0.15.0-rc0/thrift-0.15.0.exe
> >
> > Prebuilt Windows compiler GPG signature:
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.15.0-rc0/thrift-0.15.0.exe.asc
> >
> > Prebuilt Windows compiler checksums are:
> > md5: c43896461df259f3b3815336fe42040e
> > sha1: 1687f2b2d648391c3aa3a540df6ec791be03c38e
> > sha256: 4c584556233a95e78b17d89ce9506ad8dbea651b5bbc63da1467f97564b58849
> >
> >
> > The CHANGES list for this release is available at:
> > https://github.com/apache/thrift/blob/0.15.0/CHANGES.md
> >
> >
> > Please download, verify sig/sum, install and test the libraries and
> > languages of your choice.
> >
> > This vote will close in 104 hours on Thu, 2021-SEP-09 00:00 UTC5
> > https://www.timeanddate.com/countdown/generic?iso=20210909T=1440
> >
> > [ ] +1 Release this as Apache Thrift 0.15.0
> > [ ] +0
> > [ ] -1 Do not release this as Apache Thrift 0.15.0 because...
> >
> > Best,
> > JensG
> >
> >
>

Re: question about pull request

[Duru Can Celasun]

On Fri, 6 Aug 2021, at 04:03, Bhalchandra Pandit wrote:
> I created this pull request 
> which only has javadoc fixes. Apparently, some checks failed (appveyor and
> travis ci). I looked at the links but I am not able to figure out why they
> failed for javadoc only changes. Can someone please help me understand the
> failure? and let me know what I need to do from my side to make progress on
> this pull request?
> 
> Kumar
>

There are ongoing, unrelated issues with certain tests. You can ignore any 
failures not related to your changes.

Re: partial deserialization of Thrift

[Duru Can Celasun]

On Tue, 13 Jul 2021, at 01:07, Bhalchandra Pandit wrote:
> Thanks for showing interest and for raising valid questions.
> 
> I do not currently have a forked branch to show how it is done. However, I
> can certainly make it happen. It will take me a couple of weeks or so to do
> it. I will need to get myself familiarized with the contribution process.

The short version is that you need to open a ticket on Jira [1] and then send a 
PR against the master branch on Github [2] with the title "THRIFT-: Your 
title". Everything else can be figured out later.

[1] https://issues.apache.org/jira/projects/THRIFT/issues

[2] https://github.com/apache/thrift/

> 
> To answer other questions:
> 
>1. The current implementation is in Java. However, it can also be easily
>ported to other languages. Happy to help in that direction as well.
>2. The solution does not modify the definition of any structure (eg,
>Payload => SlimPayload). The output instance has the same type regardless
>of whether we use full deserialization or partial deserialization. In that
>sense, it is 100% compatible in both directions (partial <=> full). The
>solution enables selectively deserializing any arbitrary nested subset.
> 
> Kumar
> 
> On Mon, Jul 12, 2021 at 4:10 PM Duru Can Celasun 
> wrote:
> 
> > This is definitely an interesting problem at scale and it'd be great to
> > have a solution upstream.
> >
> > I second Yuxuan's questions. From the blog post it seems you have an
> > implementation for Java, but it would be great to have at least one more.
> >
> > On Tue, 13 Jul 2021, at 00:00, Yuxuan Wang wrote:
> > >  Hi Bhalchandra,
> > >
> > > Do you have any open source code (e.g. forked thrift) to show how you
> > > implemented it? The blog post stated what's the problem but really lack
> > > information on the solution side:
> > >
> > > 1. How did you solve the problem?
> > > 2. In which language(s) did you implement the solution?
> > >
> > > Without that information it's really not much we can do here.
> > >
> > > Also just based on the problem you described, a simple solution would be
> > > just to duplicate the struct definition and remove the fields you don't
> > > need, for example:
> > >
> > > // Original struct
> > > struct Payload {
> > >   1: optional Type1 field1,
> > >   2: optional Type2 field2,
> > >   3: optional Type3 field3,
> > >   ...
> > > }
> > >
> > > // Slim struct
> > > struct SlimPayload {
> > >   1: optional Type1 field1,
> > >   // field2 removed because we don't care about it in this use case
> > >   3: optional SlimType3 field3,
> > >   ...
> > > }
> > >
> > > But of course it's hard to keep SlimPayload in sync with the original
> > > Payload so I can see there are some values to have some helpers to help
> > > that, but as long as you don't make breaking changes into Payload "keep
> > > them in sync" is a false problem.
> > >
> > > On Mon, Jul 12, 2021 at 12:56 PM Bhalchandra Pandit
> > >  wrote:
> > >
> > > > Hi All,
> > > > I work for Pinterest. I developed a technique for partial
> > deserialization
> > > > of Thrift that has been very useful in significantly improving
> > efficiency
> > > > of the data processing at Pinterest. I would like to contribute that
> > > > feature to Apache Thrift. More details on this technique are available
> > in
> > > > this blog I recently wrote:
> > > >
> > > >
> > https://medium.com/pinterest-engineering/improving-data-processing-efficiency-using-partial-deserialization-of-thrift-16bc3a4a38b4
> > > >
> > > > I would like to know if any of you are interested in helping with
> > > > contributing this work to the main branch.
> > > >
> > > > Kumar
> > > >
> > >
> >
>

Re: partial deserialization of Thrift

[Duru Can Celasun]

This is definitely an interesting problem at scale and it'd be great to have a 
solution upstream.

I second Yuxuan's questions. From the blog post it seems you have an 
implementation for Java, but it would be great to have at least one more.

On Tue, 13 Jul 2021, at 00:00, Yuxuan Wang wrote:
>  Hi Bhalchandra,
> 
> Do you have any open source code (e.g. forked thrift) to show how you
> implemented it? The blog post stated what's the problem but really lack
> information on the solution side:
> 
> 1. How did you solve the problem?
> 2. In which language(s) did you implement the solution?
> 
> Without that information it's really not much we can do here.
> 
> Also just based on the problem you described, a simple solution would be
> just to duplicate the struct definition and remove the fields you don't
> need, for example:
> 
> // Original struct
> struct Payload {
>   1: optional Type1 field1,
>   2: optional Type2 field2,
>   3: optional Type3 field3,
>   ...
> }
> 
> // Slim struct
> struct SlimPayload {
>   1: optional Type1 field1,
>   // field2 removed because we don't care about it in this use case
>   3: optional SlimType3 field3,
>   ...
> }
> 
> But of course it's hard to keep SlimPayload in sync with the original
> Payload so I can see there are some values to have some helpers to help
> that, but as long as you don't make breaking changes into Payload "keep
> them in sync" is a false problem.
> 
> On Mon, Jul 12, 2021 at 12:56 PM Bhalchandra Pandit
>  wrote:
> 
> > Hi All,
> > I work for Pinterest. I developed a technique for partial deserialization
> > of Thrift that has been very useful in significantly improving efficiency
> > of the data processing at Pinterest. I would like to contribute that
> > feature to Apache Thrift. More details on this technique are available in
> > this blog I recently wrote:
> >
> > https://medium.com/pinterest-engineering/improving-data-processing-efficiency-using-partial-deserialization-of-thrift-16bc3a4a38b4
> >
> > I would like to know if any of you are interested in helping with
> > contributing this work to the main branch.
> >
> > Kumar
> >
>

Re: [VOTE] Apache Thrift 0.14.2-rc1 release candidate

[Duru Can Celasun]

+1

On Sat, 12 Jun 2021, at 18:27, Yuxuan Wang wrote:
> +1
> 
> On Sat, Jun 12, 2021 at 10:13 AM Jens Geyer  wrote:
> 
> > All,
> >
> > I propose that we accept the following release candidate as the official
> > Apache Thrift 0.14.2 release:
> >
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.2-rc1/thrift-0.14.2.tar.gz
> >
> > The release candidate was created from the 0.14.2 branch and can be cloned
> > using:
> >
> > git clone -b 0.14.2 https://github.com/apache/thrift.git
> >
> > The release candidates GPG signature can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.2-rc1/thrift-0.14.2.tar.gz.asc
> >
> > The release candidates checksums are:
> > md5: 284a48df355aa3910687ee9b894d3ae8
> > sha1: daf3640f5f18ddb7c194133903b6882df93c5d51
> > sha256: 4191bfc0b7490e20cc69f9f4dc6e991fbb612d4551aa9eef1dbf7f4c47ce554d
> >
> >
> > A prebuilt Windows compiler is available at:
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.2-rc1/thrift-0.14.2.exe
> >
> > Prebuilt Windows compiler GPG signature:
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.2-rc1/thrift-0.14.2.exe.asc
> >
> > Prebuilt Windows compiler checksums are:
> > md5: fd0bda468e65f552e15a585ef5de83fe
> > sha1: 52a0a177cea7d5431fa5b19d8d6caa753b02eba1
> > sha256: 2a0911dbd5899ebb37a08dcc517188ce02987cdebdfc5e5f1db29215ed5355bb
> >
> >
> > The CHANGES list for this release is available at:
> > https://github.com/apache/thrift/blob/0.14.2/CHANGES.md
> >
> >
> > Please download, verify sig/sum, install and test the libraries and
> > languages of your choice.
> >
> > This vote will close on Thu, 2021-06-17 00:00 UTC
> > https://www.timeanddate.com/countdown/generic?iso=20210617T=1440
> >
> > [ ] +1 Release this as Apache Thrift 0.14.2
> > [ ] +0
> > [ ] -1 Do not release this as Apache Thrift 0.14.2 because...
> >
> > I start with my own +1.
> >
> > Best,
> > JensG
> >
> >
>

Re: [VOTE] Apache Thrift 0.14.1-rc0 release candidate

[Duru Can Celasun]

+1

On Tue, 2 Mar 2021, at 23:13, Yuxuan Wang wrote:
> +1
> 
> On Tue, Mar 2, 2021 at 1:35 PM Jens Geyer  wrote:
> 
> > All,
> >
> > I propose that we accept the following release candidate as the official
> > Apache Thrift 0.14.1 release:
> >
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.1-rc0/thrift-0.14.1.tar.gz
> >
> > The release candidate was created from the 0.14.1 branch and can be cloned
> > using:
> >
> > git clone -b 0.14.1 https://github.com/apache/thrift.git
> >
> > The release candidates GPG signature can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.1-rc0/thrift-0.14.1.tar.gz.asc
> >
> > The release candidates checksums are:
> > md5: c64434548438df2cb1e53fb27c600e85
> > sha1: 7b322742610ef6c9f15e22101862163b72a7efe7
> > sha256: 13da5e1cd9c8a3bb89778c0337cc57eb0c29b08f3090b41cf6ab78594b410ca5
> >
> >
> > A prebuilt Windows compiler is available at:
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.1-rc0/thrift-0.14.1.exe
> >
> > Prebuilt Windows compiler GPG signature:
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.1-rc0/thrift-0.14.1.exe.asc
> >
> > Prebuilt Windows compiler checksums are:
> > md5: adda033e9a721e13215e13994ca0d5bd
> > sha1: 1080b396ad3e8ce5aafffb26664ccf7fa6ca1b52
> > sha256: 2529e9e8dfe0c6bfaeb8f618705e5ea6703b56acbd7566ea7a1e75521b24dfff
> >
> >
> >
> > The CHANGES list for this release is available at:
> > https://github.com/apache/thrift/blob/0.14.1/CHANGES.md
> >
> >
> > Please download, verify sig/sum, install and test the libraries and
> > languages of your choice.
> >
> > This vote will close in 72 hours on Mon, 2021-03-08 00:00 UTC
> > https://www.timeanddate.com/countdown/generic?iso=20210308T=1440
> >
> > [ ] +1 Release this as Apache Thrift 0.14.1
> > [ ] +0
> > [ ] -1 Do not release this as Apache Thrift 0.14.1 because...
> >
> > Best,
> > JensG
> >
>

Re: Travis open-source builds sharply reduced

[Duru Can Celasun]

Keep in mind that the ASF has a paid subscription [1] to Travis, so we are not 
limited to the open source plan.

[1] https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci

On Tue, 2 Mar 2021, at 08:28, Mario Emmenlauer wrote:
> 
> Hi,
> 
> On 02.03.21 05:28, Allen George wrote:
> > Hi -
> > 
> > Really sorry if I missed the conversation about this, but it seems like
> > Travis open source builds are being drastically reduced. I only realized
> > this when looking at the ominous warning on the Travis build page for
> > Thrift. Counting up the minutes for a single push indicates that we use 500
> > minutes per PR (!) This is a serious problem, because as far as I can tell,
> 
> I'm not sure how much this is related, but I'm under the impression that
> currently every build is starting from vanilla environment and installing
> all dependencies from scratch. This spends significant time on downloads
> and installations, and (what's almost worse) it often fails when upstream
> dependencies are temporarily unavailable or changed.
> 
> It could be much better to have a persistent environment, for example
> preserve the pre-installed docker containers?
> 
> All the best,
> 
> Mario Emmenlauer
> 
> 
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
>

[jira] [Comment Edited] (THRIFT-5358) Add go.mod file(s)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287393#comment-17287393
 ] 

Duru Can Celasun edited comment on THRIFT-5358 at 2/19/21, 10:18 PM:
-

Sounds like a plan. I suggest we do a quick 0.14.1 release to unblock anyone on 
1.16.


was (Author: calcifer):
Sounds like a plan. I suggest we do a quick 0.14.1 release to unblock anyone on 
1.16.

[~jensg] thoughts?

> Add go.mod file(s)
> --
>
> Key: THRIFT-5358
> URL: https://issues.apache.org/jira/browse/THRIFT-5358
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.14.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> Go 1.16 already disallowed building without go.mod file by default (still 
> override-able with GO111MODULES=auto environment variable), and Go 1.17 will 
> remove that override option, so we need to add go.mod file(s) to unblock 
> developers working on tip and using Go 1.16+.
> Based on the current discussion on https://github.com/golang/go/issues/34055, 
> we probably will need to add 2 go.mod files:
> # one under lib/go/thrift for our users to use. A release process change is 
> also required because of this file: for all the future releases, we would 
> need to double tag with "lib/go/thrift/" prefix (e.g. for 0.15.0 release we 
> would need to git tag "v0.15.0" and "lib/go/thrift/v0.15.0" on the same 
> commit)
> # another under root for the tests to work on Go 1.16+



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5358) Add go.mod file(s)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287398#comment-17287398
 ] 

Duru Can Celasun commented on THRIFT-5358:
--

Ah ok, we haven't upgraded to 1.16 yet so I assumed it also affected users. No 
rush then.

> Add go.mod file(s)
> --
>
> Key: THRIFT-5358
> URL: https://issues.apache.org/jira/browse/THRIFT-5358
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.14.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> Go 1.16 already disallowed building without go.mod file by default (still 
> override-able with GO111MODULES=auto environment variable), and Go 1.17 will 
> remove that override option, so we need to add go.mod file(s) to unblock 
> developers working on tip and using Go 1.16+.
> Based on the current discussion on https://github.com/golang/go/issues/34055, 
> we probably will need to add 2 go.mod files:
> # one under lib/go/thrift for our users to use. A release process change is 
> also required because of this file: for all the future releases, we would 
> need to double tag with "lib/go/thrift/" prefix (e.g. for 0.15.0 release we 
> would need to git tag "v0.15.0" and "lib/go/thrift/v0.15.0" on the same 
> commit)
> # another under root for the tests to work on Go 1.16+



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (THRIFT-5358) Add go.mod file(s)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287393#comment-17287393
 ] 

Duru Can Celasun edited comment on THRIFT-5358 at 2/19/21, 10:03 PM:
-

Sounds like a plan. I suggest we do a quick 0.14.1 release to unblock anyone on 
1.16.

[~jensg] thoughts?


was (Author: calcifer):
Sounds like a plan. I suggest we do a quick 0.14.1 release to unblock anyone on 
1.16.

@jensg thoughts?

> Add go.mod file(s)
> --
>
> Key: THRIFT-5358
> URL: https://issues.apache.org/jira/browse/THRIFT-5358
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.14.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> Go 1.16 already disallowed building without go.mod file by default (still 
> override-able with GO111MODULES=auto environment variable), and Go 1.17 will 
> remove that override option, so we need to add go.mod file(s) to unblock 
> developers working on tip and using Go 1.16+.
> Based on the current discussion on https://github.com/golang/go/issues/34055, 
> we probably will need to add 2 go.mod files:
> # one under lib/go/thrift for our users to use. A release process change is 
> also required because of this file: for all the future releases, we would 
> need to double tag with "lib/go/thrift/" prefix (e.g. for 0.15.0 release we 
> would need to git tag "v0.15.0" and "lib/go/thrift/v0.15.0" on the same 
> commit)
> # another under root for the tests to work on Go 1.16+



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5358) Add go.mod file(s)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287393#comment-17287393
 ] 

Duru Can Celasun commented on THRIFT-5358:
--

Sounds like a plan. I suggest we do a quick 0.14.1 release to unblock anyone on 
1.16.

@jensg thoughts?

> Add go.mod file(s)
> --
>
> Key: THRIFT-5358
> URL: https://issues.apache.org/jira/browse/THRIFT-5358
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.14.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> Go 1.16 already disallowed building without go.mod file by default (still 
> override-able with GO111MODULES=auto environment variable), and Go 1.17 will 
> remove that override option, so we need to add go.mod file(s) to unblock 
> developers working on tip and using Go 1.16+.
> Based on the current discussion on https://github.com/golang/go/issues/34055, 
> we probably will need to add 2 go.mod files:
> # one under lib/go/thrift for our users to use. A release process change is 
> also required because of this file: for all the future releases, we would 
> need to double tag with "lib/go/thrift/" prefix (e.g. for 0.15.0 release we 
> would need to git tag "v0.15.0" and "lib/go/thrift/v0.15.0" on the same 
> commit)
> # another under root for the tests to work on Go 1.16+



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE][RESULT] Apache Thrift 0.14.0-rc0 release candidate

[Duru Can Celasun]

Hey all,

Maybe I'm reading that page wrong, but I think the vote is good. It says 
"minimum three positive votes" are required, it doesn't say they have to be 
binding. My understanding is that PMC members can choose to count or not count 
non-binding votes.

So if we do count Yuxuan's vote (we should) we can go ahead with the release.

Thoughts?

On Wed, 10 Feb 2021, at 20:04, Jens Geyer wrote:
> All,
> 
> Including my own vote of +1 we have 2 binding +1.
> Additionally, we received one non-binding +1.
> No -1 votes have been cast.
> 
> Binding Votes
> +1 Jens Geyer
> +1 Duru Can Celasun
> 
> Non-binding votes
> +1 Yuxuan Wang
> 
> According to the ASF trelease policy, the vote for the Apache Thrift 0.14.0 
> release is NOT successful, because we did not reach the minimum required 
> amount of positive binding votes.
> 
> http://www.apache.org/legal/release-policy.html#release-approval
> http://www.apache.org/legal/release-policy.html#approving-a-release
> 
> Thank you to all who helped test and verify.
> 
> JensG
> 
> 
> -Ursprüngliche Nachricht- 
> From: Jens Geyer
> Sent: Friday, February 5, 2021 12:52 AM
> To: Thrift-Dev
> Subject: [VOTE] Apache Thrift 0.14.0-rc0 release candidate
> 
> All,
> 
> I propose that we accept the following release candidate as the official 
> Apache Thrift 0.14.0 release:
> 
> https://dist.apache.org/repos/dist/dev/thrift/0.14.0-rc0/thrift-0.14.0.tar.gz
> 
> The release candidate was created from the release/0.14.0 branch and can be 
> cloned using:
> 
> git clone -b release/0.14.0 https://github.com/apache/thrift.git
> 
> The release candidates GPG signature can be found at:
> https://dist.apache.org/repos/dist/dev/thrift/0.14.0-rc0/thrift-0.14.0.tar.gz.asc
> 
> The release candidates checksums are:
> md5: 53a61cd60ff2f06d3102e1bf6dd62b37
> sha1: ced3c99bede66e27daff7bd097adc329ff3682b9
> sha256: 8dcb64f63126522e1a3fd65bf6e5839bc3d3f1e13eb514ce0c2057c9b898ff71
> 
> 
> A prebuilt statically-linked Windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.14.0-rc0/thrift-0.14.0.exe
> 
> Prebuilt statically-linked Windows compiler GPG signature:
> https://dist.apache.org/repos/dist/dev/thrift/0.14.0-rc0/thrift-0.14.0.exe.asc
> 
> Prebuilt statically-linked Windows compiler checksums are:
> md5: 28ff1f363ead1f4c11485cef9c2ac696
> sha1: 078001bcd4ac6d179c2d09a0323eb5fc9bc5bb78
> sha256: 2630d039d3548db9eae70f7cd76ace0672f8535ef0021b9ad02205ed63d3f204
> 
> 
> The CHANGES list for this release is available at:
> https://github.com/apache/thrift/blob/release/0.14.0/CHANGES.md
> 
> 
> Please download, verify sig/sum, install and test the libraries and 
> languages of your choice.
> 
> This vote will close in 114 hours on 2021-02-09 18:00 UTC, giving enough 
> room for everybody even with a weekend in between.
> 
> [ ] +1 Release this as Apache Thrift 0.14.0
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.14.0 because...
> 
> https://www.timeanddate.com/countdown/generic?iso=20210209T1800=1440
> 
> Have fun,
> JensG 
> 
>

Re: [VOTE] Apache Thrift 0.14.0-rc0 release candidate

[Duru Can Celasun]

+1

On Fri, 5 Feb 2021, at 00:13, Yuxuan Wang wrote:
> +1 (is this how voting works?)
> 
> Also I think you have a typo on the branch name. I don't see
> "release/0.14.0" branch, but I do see "0.14.0" branch
> 
> On Thu, Feb 4, 2021 at 3:52 PM Jens Geyer  wrote:
> 
> > All,
> >
> > I propose that we accept the following release candidate as the official
> > Apache Thrift 0.14.0 release:
> >
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.0-rc0/thrift-0.14.0.tar.gz
> >
> > The release candidate was created from the release/0.14.0 branch and can
> > be cloned using:
> >
> > git clone -b release/0.14.0 https://github.com/apache/thrift.git
> >
> > The release candidates GPG signature can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.0-rc0/thrift-0.14.0.tar.gz.asc
> >
> > The release candidates checksums are:
> > md5: 53a61cd60ff2f06d3102e1bf6dd62b37
> > sha1: ced3c99bede66e27daff7bd097adc329ff3682b9
> > sha256: 8dcb64f63126522e1a3fd65bf6e5839bc3d3f1e13eb514ce0c2057c9b898ff71
> >
> >
> > A prebuilt statically-linked Windows compiler is available at:
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.0-rc0/thrift-0.14.0.exe
> >
> > Prebuilt statically-linked Windows compiler GPG signature:
> >
> > https://dist.apache.org/repos/dist/dev/thrift/0.14.0-rc0/thrift-0.14.0.exe.asc
> >
> > Prebuilt statically-linked Windows compiler checksums are:
> > md5: 28ff1f363ead1f4c11485cef9c2ac696
> > sha1: 078001bcd4ac6d179c2d09a0323eb5fc9bc5bb78
> > sha256: 2630d039d3548db9eae70f7cd76ace0672f8535ef0021b9ad02205ed63d3f204
> >
> >
> > The CHANGES list for this release is available at:
> > https://github.com/apache/thrift/blob/release/0.14.0/CHANGES.md
> >
> >
> > Please download, verify sig/sum, install and test the libraries and
> > languages of your choice.
> >
> > This vote will close in 114 hours on 2021-02-09 18:00 UTC, giving enough
> > room for everybody even with a weekend in between.
> >
> > [ ] +1 Release this as Apache Thrift 0.14.0
> > [ ] +0
> > [ ] -1 Do not release this as Apache Thrift 0.14.0 because...
> >
> > https://www.timeanddate.com/countdown/generic?iso=20210209T1800=1440
> >
> > Have fun,
> > JensG
>

[jira] [Commented] (THRIFT-4914) Go: Link between THeader and context object

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270055#comment-17270055
 ] 

Duru Can Celasun commented on THRIFT-4914:
--

Sounds reasonable. I agree that there are likely very few direct users of 
Tclient.Call so the BC break is minor.

> Go: Link between THeader and context object
> ---
>
> Key: THRIFT-4914
> URL: https://issues.apache.org/jira/browse/THRIFT-4914
> Project: Thrift
>  Issue Type: New Feature
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We have "raw" THeader support for Go in THRIFT-4612 now, the next step would 
> be to make them more easily accessible.
> The are 2 directions, 4 parts of this ticket:
>  * client -> server (requests)
>  ** Read headers on server
>  ** Write headers on client
>  * server -> client (responses)
>  ** Write headers on server
>  ** Read headers on client
> Take the reading on server as an example. Currently we can read the headers 
> from either the transport or the protocol, but neither the transport nor the 
> protocol objects are "easily accessible" when you are writing the business 
> logic code (writing the request handler in the server code). It would be much 
> better if we inject the headers into the context object passed into the 
> request handlers.
> We already have code injecting the headers to the context object that lives 
> outside of the thrift library working. I'll send out a PR in the coming days 
> to add that to the thrift library, so the performance would be better (we no 
> longer need to do the extra injecting work), and it would be a lot easier to 
> use.
> We'll think about how to best do the client writing part (probably auto read 
> the headers from the context object that passed into the client request code, 
> and write to THeaderProtocol automatically), and send out a PR soon-ish.
> The other direction, server -> client, is used much less often with headers, 
> so we'll probably punt on it for now, and come back revisit them in the 
> future.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (THRIFT-5338) Proposal: Raise minimal supported Go version with upcoming 0.14.0 release

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268065#comment-17268065
 ] 

Duru Can Celasun edited comment on THRIFT-5338 at 1/19/21, 5:35 PM:


I'm happy to go for 1.14x. It has been quite a while since the last thrift 
release and anyone willing to upgrade thrift can surely use a newer version of 
Go, which doesn't break BC.


was (Author: calcifer):
I'm happy to go for 1.14x. It has been quite a while since the last thrift 
release and anyone willing to upgrade thrift can surely use newer version of 
Go, which doesn't break BC.

> Proposal: Raise minimal supported Go version with upcoming 0.14.0 release
> -
>
> Key: THRIFT-5338
> URL: https://issues.apache.org/jira/browse/THRIFT-5338
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>
> Currently (as of 0.13.0), the minimal supported Go version is 1.10.8, which 
> is the latest point release in 1.10.x (released on 2019-01-23). I propose 
> that we raise this version with 0.14.0 release. There are 3 potential 
> versions we can raise it to:
> 1. go1.12.17 (released on 2020-02-12). This proposal is based on the release 
> cycles of the 2 projects. (Go has a release very 6 months, while thrift has a 
> release roughly every 12 months, so we raise 2 versions of Go with our 
> release). This would give us benefit of proper go modules support, which was 
> introduced in go 1.11.
> 2. go1.13.15 (released on 2020-08-06). This would give us the additional 
> benefit of better error/exception handling, as currently in go library code 
> there are a few places we have to do extra work because we have to support 
> pre-go1.13 (examples: 
> [1|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/transport_exception_test.go#L50-L51],
>  
> [2|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/transport_exception_test.go#L69-L70],
>  
> [3|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/simple_server.go#L318-L319])
> 3. go1.14.x. There's no additional benefit for this one, but this will be the 
> -latest- minimal officially supported go release when we release 0.14.0 (as 
> stated by [Go release 
> policy|https://golang.org/doc/devel/release.html#policy], only 2 most recent 
> major releases will be supported by security fixes).
> I don't know if any of the thrift users are stuck with an older Go version. 
> Consider go has very strong backward compatibility guarantee on the whole 1.x 
> tree, I highly doubt that would be the case (unless someone is stuck on a 
> platform that's dropped in later Go releases).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5338) Proposal: Raise minimal supported Go version with upcoming 0.14.0 release

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268065#comment-17268065
 ] 

Duru Can Celasun commented on THRIFT-5338:
--

I'm happy to go for 1.14x. It has been quite a while since the last thrift 
release and anyone willing to upgrade thrift can surely use newer version of 
Go, which doesn't break BC.

> Proposal: Raise minimal supported Go version with upcoming 0.14.0 release
> -
>
> Key: THRIFT-5338
> URL: https://issues.apache.org/jira/browse/THRIFT-5338
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>
> Currently (as of 0.13.0), the minimal supported Go version is 1.10.8, which 
> is the latest point release in 1.10.x (released on 2019-01-23). I propose 
> that we raise this version with 0.14.0 release. There are 3 potential 
> versions we can raise it to:
> 1. go1.12.17 (released on 2020-02-12). This proposal is based on the release 
> cycles of the 2 projects. (Go has a release very 6 months, while thrift has a 
> release roughly every 12 months, so we raise 2 versions of Go with our 
> release). This would give us benefit of proper go modules support, which was 
> introduced in go 1.11.
> 2. go1.13.15 (released on 2020-08-06). This would give us the additional 
> benefit of better error/exception handling, as currently in go library code 
> there are a few places we have to do extra work because we have to support 
> pre-go1.13 (examples: 
> [1|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/transport_exception_test.go#L50-L51],
>  
> [2|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/transport_exception_test.go#L69-L70],
>  
> [3|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/simple_server.go#L318-L319])
> 3. go1.14.x. There's no additional benefit for this one, but this will be the 
> latest officially supported go release when we release 0.14.0 (as stated by 
> [Go release policy|https://golang.org/doc/devel/release.html#policy], only 2 
> most recent major releases will be supported by security fixes).
> I don't know if any of the thrift users are stuck with an older Go version. 
> Consider go has very strong backward compatibility guarantee on the whole 1.x 
> tree, I highly doubt that would be the case (unless someone is stuck on a 
> platform that's dropped in later Go releases).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Plans/process for 0.14.0 release?

[Duru Can Celasun]

I'd say get as many commits in as you can. Our release schedule is at best 
erratic, who knows when 0.15 might happen :)

On Wed, 6 Jan 2021, at 21:35, Mario Emmenlauer wrote:
> 
> On 04.01.21 21:41, Yuxuan Wang wrote:
> > Judging from history the end of the years are usually when we do releases,
> > is there a plan for 0.14.0 release?
> > 
> 
> I have a few PRs in the pipeline, that are already reviewed and ready for
> merge. I just did not have time to perform the merge yet.
> 
> Is it rather encouraged to get them into 0.14.0, or rather discouraged?
> In other words, should as much go into the release as possible, or should
> current master already "settle down" to be as stable as possible before
> the release?
> 
> All the best,
> 
>  Mario Emmenlauer
>

Re: Plans/process for 0.14.0 release?

[Duru Can Celasun]

I have those PRs on my backlog, sorry for the delay :) I'll definitely take a 
look this week.

On Tue, 5 Jan 2021, at 22:40, Yuxuan Wang wrote:
> For Go I certainly want to merge https://github.com/apache/thrift/pull/2298
> & https://github.com/apache/thrift/pull/2296 before the next release
> (v0.14.0). @Can might take a look at them? :)
> 
> On Tue, Jan 5, 2021 at 2:38 PM Duru Can Celasun  wrote:
> 
> > I'm in favour of cutting a new release, though I never did one for thrift
> > and I won't have the time to get involved any time soon.
> >
> > On Tue, 5 Jan 2021, at 21:47, Jens Geyer wrote:
> > > @all
> > >
> > > > Good question. I'm in favour of it. Who does it?
> > >
> > > That was actually a real question. I support the proposal but would like
> > to
> > > know the opinion of other people.
> > > - Anything we absolutely should include in the next release (i.e.
> > blockers)?
> > > - Or is everybody happy already and thinks we are ready to cut a branch
> > and
> > > do the real heavy lifting?
> > >
> > > That's not a real vote, but at least some feedback would be helpful.
> > >
> > > Have fun,
> > > JensG
> > >
> > >
> > > -Ursprüngliche Nachricht-
> > > From: Yuxuan Wang
> > > Sent: Monday, January 4, 2021 9:41 PM
> > > To: dev@thrift.apache.org
> > > Subject: Plans/process for 0.14.0 release?
> > >
> > > Judging from history the end of the years are usually when we do
> > releases,
> > > is there a plan for 0.14.0 release?
> > >
> > >
> >
>

Re: Plans/process for 0.14.0 release?

[Duru Can Celasun]

I'm in favour of cutting a new release, though I never did one for thrift and I 
won't have the time to get involved any time soon.

On Tue, 5 Jan 2021, at 21:47, Jens Geyer wrote:
> @all
> 
> > Good question. I'm in favour of it. Who does it?
> 
> That was actually a real question. I support the proposal but would like to 
> know the opinion of other people.
> - Anything we absolutely should include in the next release (i.e. blockers)?
> - Or is everybody happy already and thinks we are ready to cut a branch and 
> do the real heavy lifting?
> 
> That's not a real vote, but at least some feedback would be helpful.
> 
> Have fun,
> JensG
> 
> 
> -Ursprüngliche Nachricht- 
> From: Yuxuan Wang
> Sent: Monday, January 4, 2021 9:41 PM
> To: dev@thrift.apache.org
> Subject: Plans/process for 0.14.0 release?
> 
> Judging from history the end of the years are usually when we do releases,
> is there a plan for 0.14.0 release? 
> 
>

[jira] [Commented] (THRIFT-5326) Expand TException interface in go library

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17253300#comment-17253300
 ] 

Duru Can Celasun commented on THRIFT-5326:
--

I like the enum approach better. This will break type assertions, but judging 
by a [quick search on 
Github|https://github.com/search?q=TException+ok=Code=Go] it won't 
really be a problem.

> Expand TException interface in go library
> -
>
> Key: THRIFT-5326
> URL: https://issues.apache.org/jira/browse/THRIFT-5326
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Compiler, Go - Library
>Affects Versions: 0.13.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> This is an issue unique to go, because of go's duck typing interface system: 
> There's no way to distinguish TException from other errors.
> Currently TException is defined to be identical to error 
> ([link|https://github.com/apache/thrift/blob/3b9259d88b6ceb13bb6b8c6afe676fed707dcd4e/lib/go/thrift/exception.go#L27-L29]):
> {code:go}
> type TException interface {
>   error
> }
> {code}
> Which means when you try to do
> {code:go}
> var texception thrift.TException
> if errors.As(err, ) {
> }
> {code}
> It's always true.
> TTransportException, TApplicationException, and TProtocolException are 
> identifiable, but for exceptions generated from the compiler (that's defined 
> in thrift files), TExecption is the only "common" type they share and it's 
> very hard to write library code to handle them collectively.
> My proposal is to add a new function to TException interface (which also need 
> to be added to TTransportException, TApplicationException, 
> TProtocolException, and all compiler generated exceptions). There are 2 ways 
> to define this new function:
> 1. TExceptionType() TExceptionType, where TExceptionType is an enum type, 
> with values of TTransportException, TApplicationException, 
> TProtocolException, TIDLException (name tbd, open to suggestions, this is the 
> one intended to be used by compiler)
> 2. TExceptionName() string, which for TTransportException the string would 
> just be "TTransportException", etc. For compiler generated exceptions, I 
> think the name should be the name of the exception with the thrift filename 
> as the namespace. For example, for:
> {code}
> exception MyError {
>   ...
> }
> {code}
> that's defined in my_service.thrift, the compiler generated name would be 
> "my_service.MyError". Note that the namespace could be different from the 
> actual go import namespace, as in if the thrift file have the line of 
> "namespace go foo.bar.my_service_2", the go namespace would be "my_service_2" 
> instead of "my_service"
> I would slightly prefer the enum approach as it's simpler (there's no 
> ambiguity on the namespace part of the string approach). Either way this 
> requires compiler change to add the new function to generated exception types.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5322) Go compact_protocol allocating unreasonable buffer size

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17247254#comment-17247254
 ] 

Duru Can Celasun commented on THRIFT-5322:
--

Buffer size limits have been implemented [1] for a number of languages in the 
aftermath of CVE-2019-11939 [2] but nobody has done so for Go yet. PRs are very 
welcome.


[1] Java example: https://github.com/apache/thrift/pull/2191


[2] https://nvd.nist.gov/vuln/detail/CVE-2019-11939

> Go compact_protocol allocating unreasonable buffer size
> ---
>
> Key: THRIFT-5322
> URL: https://issues.apache.org/jira/browse/THRIFT-5322
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.13.0
>Reporter: Juraci Paixão Kröhling
>Priority: Major
>
> I don't yet know all the pieces to this puzzle, and it's quite possible that 
> the problem is on our side, but we use the Thrift Go library in the Jaeger 
> Agent and we are seeing a case where the memory consumption for a payload of 
> 4k bytes to result in a buffer allocation in the compact_protocol.go with 
> unreasonable sizes. I found buffers of 1.4GiB while debugging the issue.
>  
> This is the code that we are seeing this memory usage:
> [https://github.com/apache/thrift/blob/b75e88a33d67ae05ef9b5fa001d2a63a2effe377/lib/go/thrift/compact_protocol.go#L556-L577]
>  
> Here's more information about this, including a reproducer and initial 
> diagnostics:
> [https://github.com/jaegertracing/jaeger/issues/2638#issuecomment-741848201]
>  
> As mentioned above, I'm still getting all the pieces together, but perhaps 
> you've seen this before or know what might be going on. What I know for sure 
> at the moment is that this happens on malformed payloads, but I would expect 
> the library to have an upper limit on the buffer size.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4685) Support the new golang modules (1.11 or later)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17246095#comment-17246095
 ] 

Duru Can Celasun commented on THRIFT-4685:
--

Indeed, even the Go module spec [1] mentions it:

> A version is considered unstable if its major version is 0 or it has a 
> pre-release suffix. Unstable versions are not subject to compatibility 
> requirements. For example, v0.2.0 may not be compatible with v0.1.0, and 
> v1.5.0-beta may not be compatible with v1.5.0.

[1] https://golang.org/ref/mod#versions

> Support the new golang modules (1.11 or later)
> --
>
> Key: THRIFT-4685
> URL: https://issues.apache.org/jira/browse/THRIFT-4685
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Affects Versions: 0.12.0
> Environment: golang 1.11 or later
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Minor
>
> Go added new module support in 1.11, see:
> https://github.com/golang/go/wiki/Modules
> We should move towards it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4685) Support the new golang modules (1.11 or later)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245965#comment-17245965
 ] 

Duru Can Celasun commented on THRIFT-4685:
--

I'm not sure if it's ok to change the versioning scheme for the whole project 
for the sake of one language but I'm not really opposed to it either.

The trouble is, we allow breaking changes for every tagged release, so 
basically all releases would come with a new major version, even if there are 
no breaking changes for Go.

In any case, this should probably be settled when we decide to do another 
release, whenever that might be.

What do you think [~jensg]?

> Support the new golang modules (1.11 or later)
> --
>
> Key: THRIFT-4685
> URL: https://issues.apache.org/jira/browse/THRIFT-4685
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Affects Versions: 0.12.0
> Environment: golang 1.11 or later
>Reporter: James E. King III
>    Assignee: Duru Can Celasun
>Priority: Minor
>
> Go added new module support in 1.11, see:
> https://github.com/golang/go/wiki/Modules
> We should move towards it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Your project's website

[Duru Can Celasun]

All right, this should be all done now.

https://thrift.staged.apache.org/
https://thrift.apache.org/

I've pushed all branches to the new repo [1] and it seems the Github Action and 
asf.yml are both working correctly, 

Christopher, thank you once again for working on this. Please take a look and 
let me know if anything is wrong or missing.

Best,
Can

[1] https://github.com/apache/thrift-website

On Fri, 30 Oct 2020, at 10:36, Mario Emmenlauer wrote:
> 
> Hi guys,
> 
> thanks for the great move forward! Can you send a link to the page
> as soon as something can be seen? I'm still pretty new to the project
> and might have missed if you sent it already, sorry for that :-(
> 
> All the best, Mario
> 
> 
> On 30.10.20 11:19, Duru Can Celasun wrote:
> > I've created the repo using self-service 
> > https://github.com/apache/thrift-website
> > 
> > Once I get write access (I'm assuming it's automated) I'll push all 3 
> > branches and we can take it from there.
> > 
> > On Thu, 29 Oct 2020, at 20:33, Christopher wrote:
> >> I finished the syntax highlighting, but didn't get to the sitemap...
> >> I'm not sure it's all that important.
> >>
> >> I pushed 3 branches to my repo (main, asf-staging, asf-site). Once you
> >> get the official repo created, all three branches should be moved
> >> over, as-is, in order for everything to work smoothly. You may need to
> >> ask INFRA to set the "main" branch as the default branch, though.
> >>
> >> If everything is working correctly, you should see the site at
> >> https://thrift.staged.apache.org ; if that is working correctly, then
> >> you can use the _scripts/publish.sh script to push the staging branch
> >> to the publish branch (see README for explanation), and then you'll be
> >> completely off of CMS and can do whatever you want after that. :)
> >>
> >> On Thu, Oct 29, 2020 at 4:08 PM Duru Can Celasun  
> >> wrote:
> >>>
> >>> This looks excellent Christopher, thank you for working on this so 
> >>> quickly! I'll see if I can create an official repo tomorrow and we can 
> >>> take it from there.
> >>>
>

Re: Your project's website

[Duru Can Celasun]

I've created the repo using self-service 
https://github.com/apache/thrift-website

Once I get write access (I'm assuming it's automated) I'll push all 3 branches 
and we can take it from there.

On Thu, 29 Oct 2020, at 20:33, Christopher wrote:
> I finished the syntax highlighting, but didn't get to the sitemap...
> I'm not sure it's all that important.
> 
> I pushed 3 branches to my repo (main, asf-staging, asf-site). Once you
> get the official repo created, all three branches should be moved
> over, as-is, in order for everything to work smoothly. You may need to
> ask INFRA to set the "main" branch as the default branch, though.
> 
> If everything is working correctly, you should see the site at
> https://thrift.staged.apache.org ; if that is working correctly, then
> you can use the _scripts/publish.sh script to push the staging branch
> to the publish branch (see README for explanation), and then you'll be
> completely off of CMS and can do whatever you want after that. :)
> 
> On Thu, Oct 29, 2020 at 4:08 PM Duru Can Celasun  wrote:
> >
> > This looks excellent Christopher, thank you for working on this so quickly! 
> > I'll see if I can create an official repo tomorrow and we can take it from 
> > there.
> >
> > On Thu, 29 Oct 2020, at 16:58, Christopher wrote:
> > > While there may be an interest in making quality changes to improve
> > > the layout and content of the site, the immediate need is to migrate
> > > off of CMS, for which INFRA has discontinued (or is discontinuing)
> > > support.
> > >
> > > I spent a few hours today converting all the Markdown over to Jekyll
> > > today... and only have 2 small things left that I'm still working on
> > > are the things that were previously being done in CMS's Perl code:
> > > 1. ensure syntax highlighting for code blocks is working for when code
> > > blocks are pulled in from the main thrift repo, and
> > > 2. fix the sitemap (I have a flattened version in Jekyll, but it
> > > doesn't show the hierarchy).
> > >
> > > The way I have it set up is complete with build instructions for
> > > testing locally, GitHub Actions CI builds for pull requests,
> > > configuration for INFRA's builders to automatically create a staging
> > > website whenever commits are merged to the main branch, and a
> > > convenience script to quickly publish from the asf-staging branch to
> > > the asf-site branch (or you can just merge the commit in git
> > > yourself). The complete lifecycle, from contributor pull request to
> > > publication is taken into consideration.
> > >
> > > The code so far (minus the bits I'm still finishing up) is at
> > > https://github.com/ctubbsii/thrift-website
> > > Of course, the Thrift PMC is not obligated to use what I've done, but
> > > it will get them off of CMS immediately if they want to use it.
> > >
> > > On Thu, Oct 29, 2020 at 5:08 AM Mario Emmenlauer  
> > > wrote:
> > > >
> > > > On 29.10.20 02:33, Christopher wrote:
> > > > > On Wed, Oct 28, 2020 at 1:50 PM Duru Can Celasun 
> > > > >  wrote:
> > > > >
> > > > > [SNIP]
> > > > >>> I'm more than happy to do it your way, especially if you think it'd 
> > > > >>> be
> > > > >>> easier. My one concern is that the current CMS content isn't exactly
> > > > >>> great and my RTD version has improvements, but we can sort that 
> > > > >>> later.
> > > > >>> How should we proceed?
> > > > >
> > > > > Well, ultimately, the decision is up to the Thrift PMC. I can only
> > > > > offer suggestions and opinions, as I'm neither a PMC member nor a
> > > > > committer for Thrift. The CMS content may not be "great" as is, but it
> > > > > is  what is there and working now, and its static HTML and/or basic
> > > > > Markdown is 99% compatible with Jekyll's Markdown, so it's easy to
> > > > > convert while preserving the existing site look and feel... just to
> > > > > get off of CMS as quickly as possible. However, since I'm not a
> > > > > committer for Thrift, there's little I can do to actually make it
> > > > > happen. *IF* the PMC wants to go that route to get things done
> > > > > quickly, I can convert over the Markdown this week, and put it in my
> > > > > own repo for them to use directly, but I don't want to do that effort
> > > > &

Re: Your project's website

[Duru Can Celasun]

This looks excellent Christopher, thank you for working on this so quickly! 
I'll see if I can create an official repo tomorrow and we can take it from 
there.

On Thu, 29 Oct 2020, at 16:58, Christopher wrote:
> While there may be an interest in making quality changes to improve
> the layout and content of the site, the immediate need is to migrate
> off of CMS, for which INFRA has discontinued (or is discontinuing)
> support.
> 
> I spent a few hours today converting all the Markdown over to Jekyll
> today... and only have 2 small things left that I'm still working on
> are the things that were previously being done in CMS's Perl code:
> 1. ensure syntax highlighting for code blocks is working for when code
> blocks are pulled in from the main thrift repo, and
> 2. fix the sitemap (I have a flattened version in Jekyll, but it
> doesn't show the hierarchy).
> 
> The way I have it set up is complete with build instructions for
> testing locally, GitHub Actions CI builds for pull requests,
> configuration for INFRA's builders to automatically create a staging
> website whenever commits are merged to the main branch, and a
> convenience script to quickly publish from the asf-staging branch to
> the asf-site branch (or you can just merge the commit in git
> yourself). The complete lifecycle, from contributor pull request to
> publication is taken into consideration.
> 
> The code so far (minus the bits I'm still finishing up) is at
> https://github.com/ctubbsii/thrift-website
> Of course, the Thrift PMC is not obligated to use what I've done, but
> it will get them off of CMS immediately if they want to use it.
> 
> On Thu, Oct 29, 2020 at 5:08 AM Mario Emmenlauer  wrote:
> >
> > On 29.10.20 02:33, Christopher wrote:
> > > On Wed, Oct 28, 2020 at 1:50 PM Duru Can Celasun  
> > > wrote:
> > >
> > > [SNIP]
> > >>> I'm more than happy to do it your way, especially if you think it'd be
> > >>> easier. My one concern is that the current CMS content isn't exactly
> > >>> great and my RTD version has improvements, but we can sort that later.
> > >>> How should we proceed?
> > >
> > > Well, ultimately, the decision is up to the Thrift PMC. I can only
> > > offer suggestions and opinions, as I'm neither a PMC member nor a
> > > committer for Thrift. The CMS content may not be "great" as is, but it
> > > is  what is there and working now, and its static HTML and/or basic
> > > Markdown is 99% compatible with Jekyll's Markdown, so it's easy to
> > > convert while preserving the existing site look and feel... just to
> > > get off of CMS as quickly as possible. However, since I'm not a
> > > committer for Thrift, there's little I can do to actually make it
> > > happen. *IF* the PMC wants to go that route to get things done
> > > quickly, I can convert over the Markdown this week, and put it in my
> > > own repo for them to use directly, but I don't want to do that effort
> > > if that's not what they want to do. If they want to go with
> > > readthedocs to replace the site look and feel at the same time as
> > > getting off of CMS (rather than two steps), then I'd rather spend my
> > > effort trying to help you (since you're a PMC member working on this)
> > > get the builds automated and an .asf.yaml file in place to trigger the
> > > publication.
> >
> > I have to admit that I'm becoming a bit frustrated with the situation
> > of the website. I was ready to invest a few days of work in the content
> > when I started with thrift _one_year_ago_. But the content was not
> > (easily) editable and was spread out over multiple pages. In my very
> > personal opinion it would be essential for the project to get a page
> > ASAP. And it would _really_ help new users if the new page replaces all
> > spread-out information from current pages like thrift.apache.org,
> > github.com/apache/thrift, thrift-tutorial.readthedocs.io etc. And the
> > page should be really easy to edit for non-members, like i.e. in a
> > public git repository.
> >
> > I was under the impression that this is where Duru Can Celasun was going,
> > and I think that _if_ this requires more discussion then whoever suggests
> > something else should also carry this wagon for a bit. Whoever can
> > provide that gets my vote.
> >
> > All the best,
> >
> > Mario
> >
>

Re: Your project's website

[Duru Can Celasun]

Apologies, I thought I was replying to Andrew and I only just now realize it 
was Christopher. My point stands though, if there is an easier/preferred way to 
do this just let me know and we'll do that.

On Wed, 28 Oct 2020, at 17:46, Duru Can Celasun wrote:
> Andrew,
> 
> I think there has been some misunderstanding. Comments below.
> 
> On Wed, 28 Oct 2020, at 16:31, Christopher wrote:
> > Can,
> > 
> > The official site for Apache Thrift is located at thrift.apache.org
> > It is the sources for that site that needs to move away from CMS. It
> > is not sufficient to create a new site located elsewhere to address
> > the CMS issue.
> > 
> > While this "readthedocs" site looks good, it is missing some key
> > things required for ASF projects... like the mandatory foundation
> > links and copyright footer information (see
> > https://whimsy.apache.org/site/project/thrift).
> 
> Thanks, I wasn't aware but I'm happy to add all of this.
> 
> >  I also think it
> > doesn't look quite as good as the current site's layout, but that's
> > probably personal taste.
> 
> I'm not a designer and I know nothing about frontend development. The 
> current "look" of the site is simply the default provided by RTD. I 
> have neither the skills nor the interest in a new design and nobody 
> else ever volunteered.
> 
>  It might also be a problem that it has ads on
> > it at readthedocs.io, though I think that might be possible to address
> > if it is generated locally and not hosted on readthedocs.io.
> 
> That was always the intention, as stated in the original Jira issue 
> [1]. In fact, I've provided build instructions that can be used by 
> INFRA.
> 
> I wasn't aware of any ads, but then again that website is simply a 
> proof of concept on my personal RTD account.
> 
> > 
> > So, where it is currently hosted at readthedocs.io, it is not a
> > suitable alternative to the CMS hosted thrift.apache.org site... which
> > still needs to be addressed.
> 
> See above.
> 
> > 
> > In order to replace the CMS site with this new site as the new
> > thrift.apache.org, the issues I mentioned would need to be fixed, and
> > then you'd have to generate the site locally and publish it in an ASF
> > git repository, and configure it to publish to thrift.apache.org using
> > an '.asf.yaml' configuration file (see
> > https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-WebSiteDeploymentServiceforGitRepositories).
> 
> Thanks for the link. I'm not familiar with this but if INFRA could 
> create a thrift-website repo for us on Github I'd be happy to take a 
> look.
> 
> > 
> > However, I think it would be much easier to set up a simple
> > jekyll-based site using the existing CMS content as a starting point.
> > It's really not hard to do that at all. I could help with the effort,
> > but it's harder to explain than it is to do. I've already been helping
> > maintain both Accumulo and Fluo's websites in this same way, as a
> > committer on those projects, so I know it's super easy to maintain
> > once it's set up, and the set up isn't hard at all. I'm not a Thrift
> > committer, so I can't do most of the steps myself for Thrift, but I
> > can try to walk a committer through the process.
> 
> 
> I'm more than happy to do it your way, especially if you think it'd be 
> easier. My one concern is that the current CMS content isn't exactly 
> great and my RTD version has improvements, but we can sort that later. 
> How should we proceed?
> 
> > 
> > Christopher
> 
> [1] 
> https://issues.apache.org/jira/browse/THRIFT-4710?focusedCommentId=16972218=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16972218
> 
> 
> > 
> > On Wed, Oct 28, 2020 at 8:43 AM Duru Can Celasun  
> > wrote:
> > >
> > > Hi Andrew,
> > >
> > > The site on ReadTheDocs [1] isn't just documentation, it's the full 
> > > website including downloads [2] so I'm not sure if any other static 
> > > landing page is necessary.
> > >
> > > If you can clarify that first I'll go ahead and open an INFRA ticket.
> > >
> > > Can
> > >
> > > [1] https://thrift-fork.readthedocs.io/en/docs/index.html
> > > [2] https://thrift-fork.readthedocs.io/en/docs/download.html
> > >
> > > On Wed, 28 Oct 2020, at 12:35, Andrew Wetmore wrote:
> > > > Hi, Can:
> > > >
> > > > I spoke with Gavin MacDonald on our team, and he said the Thrift project
> > > > will stil

Re: Your project's website

[Duru Can Celasun]

Andrew,

I think there has been some misunderstanding. Comments below.

On Wed, 28 Oct 2020, at 16:31, Christopher wrote:
> Can,
> 
> The official site for Apache Thrift is located at thrift.apache.org
> It is the sources for that site that needs to move away from CMS. It
> is not sufficient to create a new site located elsewhere to address
> the CMS issue.
> 
> While this "readthedocs" site looks good, it is missing some key
> things required for ASF projects... like the mandatory foundation
> links and copyright footer information (see
> https://whimsy.apache.org/site/project/thrift).

Thanks, I wasn't aware but I'm happy to add all of this.

>  I also think it
> doesn't look quite as good as the current site's layout, but that's
> probably personal taste.

I'm not a designer and I know nothing about frontend development. The current 
"look" of the site is simply the default provided by RTD. I have neither the 
skills nor the interest in a new design and nobody else ever volunteered.

 It might also be a problem that it has ads on
> it at readthedocs.io, though I think that might be possible to address
> if it is generated locally and not hosted on readthedocs.io.

That was always the intention, as stated in the original Jira issue [1]. In 
fact, I've provided build instructions that can be used by INFRA.

I wasn't aware of any ads, but then again that website is simply a proof of 
concept on my personal RTD account.

> 
> So, where it is currently hosted at readthedocs.io, it is not a
> suitable alternative to the CMS hosted thrift.apache.org site... which
> still needs to be addressed.

See above.

> 
> In order to replace the CMS site with this new site as the new
> thrift.apache.org, the issues I mentioned would need to be fixed, and
> then you'd have to generate the site locally and publish it in an ASF
> git repository, and configure it to publish to thrift.apache.org using
> an '.asf.yaml' configuration file (see
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-WebSiteDeploymentServiceforGitRepositories).

Thanks for the link. I'm not familiar with this but if INFRA could create a 
thrift-website repo for us on Github I'd be happy to take a look.

> 
> However, I think it would be much easier to set up a simple
> jekyll-based site using the existing CMS content as a starting point.
> It's really not hard to do that at all. I could help with the effort,
> but it's harder to explain than it is to do. I've already been helping
> maintain both Accumulo and Fluo's websites in this same way, as a
> committer on those projects, so I know it's super easy to maintain
> once it's set up, and the set up isn't hard at all. I'm not a Thrift
> committer, so I can't do most of the steps myself for Thrift, but I
> can try to walk a committer through the process.


I'm more than happy to do it your way, especially if you think it'd be easier. 
My one concern is that the current CMS content isn't exactly great and my RTD 
version has improvements, but we can sort that later. How should we proceed?

> 
> Christopher

[1] 
https://issues.apache.org/jira/browse/THRIFT-4710?focusedCommentId=16972218=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16972218


> 
> On Wed, Oct 28, 2020 at 8:43 AM Duru Can Celasun  wrote:
> >
> > Hi Andrew,
> >
> > The site on ReadTheDocs [1] isn't just documentation, it's the full website 
> > including downloads [2] so I'm not sure if any other static landing page is 
> > necessary.
> >
> > If you can clarify that first I'll go ahead and open an INFRA ticket.
> >
> > Can
> >
> > [1] https://thrift-fork.readthedocs.io/en/docs/index.html
> > [2] https://thrift-fork.readthedocs.io/en/docs/download.html
> >
> > On Wed, 28 Oct 2020, at 12:35, Andrew Wetmore wrote:
> > > Hi, Can:
> > >
> > > I spoke with Gavin MacDonald on our team, and he said the Thrift project
> > > will still need at least a basic static landing page at thrift.a.o. If I
> > > understand correctly, you can redirect traffic from there to what you have
> > > set up in ReadTheDocs. The landing page should also have information on
> > > links for downloading software releases.
> > >
> > > Gavin requested that you open a Jira ticket directed at Infra to cover the
> > > project's migration so we can keep track of what we need to do to provide 
> > > a
> > > smooth transition for the project.
> > >
> > > Andrew
> > >
> > > On Sat, Oct 3, 2020 at 1:10 PM Duru Can Celasun  wrote:
> > >
> > > > Hi Andrew,
> > > >
> > > > Any news on this? How 

Re: Your project's website

[Duru Can Celasun]

Hi Andrew,

The site on ReadTheDocs [1] isn't just documentation, it's the full website 
including downloads [2] so I'm not sure if any other static landing page is 
necessary.

If you can clarify that first I'll go ahead and open an INFRA ticket.

Can

[1] https://thrift-fork.readthedocs.io/en/docs/index.html
[2] https://thrift-fork.readthedocs.io/en/docs/download.html

On Wed, 28 Oct 2020, at 12:35, Andrew Wetmore wrote:
> Hi, Can:
> 
> I spoke with Gavin MacDonald on our team, and he said the Thrift project
> will still need at least a basic static landing page at thrift.a.o. If I
> understand correctly, you can redirect traffic from there to what you have
> set up in ReadTheDocs. The landing page should also have information on
> links for downloading software releases.
> 
> Gavin requested that you open a Jira ticket directed at Infra to cover the
> project's migration so we can keep track of what we need to do to provide a
> smooth transition for the project.
> 
> Andrew
> 
> On Sat, Oct 3, 2020 at 1:10 PM Duru Can Celasun  wrote:
> 
> > Hi Andrew,
> >
> > Any news on this? How should we proceed?
> >
> > Cheers,
> > Can
> >
> > On Wed, 26 Aug 2020, at 16:38, Duru Can Celasun wrote:
> > > Hi Andrew,
> > >
> > > Sorry for the late response. Last year I started working on a migration
> > > from Apache CMS to "read the docs" [1] but I never got a chance to
> > > finish it.
> > >
> > > It's mostly complete, but we could definitely use some INFRA help to
> > > get it over the finish line.
> > >
> > > Would it be possible to have a thrift-website repo on Github and have
> > > it deployed via Travis?
> > >
> > > The linked issue has build instructions but I'd be happy to make
> > > changes if needed.
> > >
> > > Please let me how you'd like to proceed.
> > >
> > > Cheers,
> > > Can
> > >
> > > [1]
> > >
> > https://issues.apache.org/jira/browse/THRIFT-4710?focusedCommentId=16972218=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16972218
> > >
> > > On Mon, 24 Aug 2020, at 14:06, Andrew Wetmore wrote:
> > > > Hi:
> > > >
> > > > I wrote to you two weeks ago about your project website, but have not
> > seen
> > > > a response. Whom should I contact directly? I am trying to see whether
> > your
> > > > project still uses the Apache CMS and, if so, what your plans are to
> > > > migrate off it.
> > > >
> > > > Thanks in advance for your help.
> > > >
> > > > Andrew
> > > >
> > > > On Fri, Aug 7, 2020 at 10:06 AM Andrew Wetmore 
> > wrote:
> > > >
> > > > > Hi:
> > > > >
> > > > > I am part of the Infrastructure team, and am writing to ask whether
> > your
> > > > > project is still using the Apache CMS for your project website. As
> > you
> > > > > know, the CMS is reaching end-of-life, and we need projects to move
> > their
> > > > > websites onto a different option within the next few weeks.
> > > > >
> > > > > There are several alternatives available, including those listed on
> > this
> > > > > page [1] on managing project websites. Infra is assembling a Wiki
> > page [2]
> > > > > on migrating a website from the CMS, and is looking forward to
> > helping
> > > > > projects with this transition.
> > > > >
> > > > > Please let me know whether your site is still on the Apache CMS and,
> > if
> > > > > so, who will be the project point-of-contact with Infra for the
> > migration.
> > > > >
> > > > > Thank you!
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > [1] https://infra.apache.org/project-site.html
> > > > >
> > > > > [2]
> > > > >
> > https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
> > > > >
> > > > >
> > > > > --
> > > > > Andrew Wetmore
> > > > > Technical Writer-Editor
> > > > > Infra
> > > > > *Apache Software Foundation*
> > > > > andr...@apache.org
> > > > >
> > > > >
> > > > > <
> > https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> > Virus-free.
> > > > > www.avast.com
> > > > > <
> > https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> > >
> > > > > <#m_3918189248972690169_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > >
> > > >
> > > >
> > > > --
> > > > Andrew Wetmore
> > > > Technical Writer-Editor
> > > > Infra
> > > > *Apache Software Foundation*
> > > > andr...@apache.org
> > > >
> > >
> >
> 
> 
> -- 
> Andrew Wetmore
> Technical Writer-Editor
> Infra
> *Apache Software Foundation*
> andr...@apache.org
>

Re: Your project's website

[Duru Can Celasun]

Hi Andrew,

Any news on this? How should we proceed?

Cheers,
Can

On Wed, 26 Aug 2020, at 16:38, Duru Can Celasun wrote:
> Hi Andrew,
> 
> Sorry for the late response. Last year I started working on a migration 
> from Apache CMS to "read the docs" [1] but I never got a chance to 
> finish it.
> 
> It's mostly complete, but we could definitely use some INFRA help to 
> get it over the finish line.
> 
> Would it be possible to have a thrift-website repo on Github and have 
> it deployed via Travis?
> 
> The linked issue has build instructions but I'd be happy to make 
> changes if needed.
> 
> Please let me how you'd like to proceed.
> 
> Cheers,
> Can
> 
> [1] 
> https://issues.apache.org/jira/browse/THRIFT-4710?focusedCommentId=16972218=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16972218
> 
> On Mon, 24 Aug 2020, at 14:06, Andrew Wetmore wrote:
> > Hi:
> > 
> > I wrote to you two weeks ago about your project website, but have not seen
> > a response. Whom should I contact directly? I am trying to see whether your
> > project still uses the Apache CMS and, if so, what your plans are to
> > migrate off it.
> > 
> > Thanks in advance for your help.
> > 
> > Andrew
> > 
> > On Fri, Aug 7, 2020 at 10:06 AM Andrew Wetmore  wrote:
> > 
> > > Hi:
> > >
> > > I am part of the Infrastructure team, and am writing to ask whether your
> > > project is still using the Apache CMS for your project website. As you
> > > know, the CMS is reaching end-of-life, and we need projects to move their
> > > websites onto a different option within the next few weeks.
> > >
> > > There are several alternatives available, including those listed on this
> > > page [1] on managing project websites. Infra is assembling a Wiki page [2]
> > > on migrating a website from the CMS, and is looking forward to helping
> > > projects with this transition.
> > >
> > > Please let me know whether your site is still on the Apache CMS and, if
> > > so, who will be the project point-of-contact with Infra for the migration.
> > >
> > > Thank you!
> > >
> > >
> > >
> > >
> > > [1] https://infra.apache.org/project-site.html
> > >
> > > [2]
> > > https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
> > >
> > >
> > > --
> > > Andrew Wetmore
> > > Technical Writer-Editor
> > > Infra
> > > *Apache Software Foundation*
> > > andr...@apache.org
> > >
> > >
> > > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> > >  Virus-free.
> > > www.avast.com
> > > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> > > <#m_3918189248972690169_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >
> > 
> > 
> > -- 
> > Andrew Wetmore
> > Technical Writer-Editor
> > Infra
> > *Apache Software Foundation*
> > andr...@apache.org
> >
>

Re: Your project's website

[Duru Can Celasun]

Hi Andrew,

Sorry for the late response. Last year I started working on a migration from 
Apache CMS to "read the docs" [1] but I never got a chance to finish it.

It's mostly complete, but we could definitely use some INFRA help to get it 
over the finish line.

Would it be possible to have a thrift-website repo on Github and have it 
deployed via Travis?

The linked issue has build instructions but I'd be happy to make changes if 
needed.

Please let me how you'd like to proceed.

Cheers,
Can

[1] 
https://issues.apache.org/jira/browse/THRIFT-4710?focusedCommentId=16972218=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16972218

On Mon, 24 Aug 2020, at 14:06, Andrew Wetmore wrote:
> Hi:
> 
> I wrote to you two weeks ago about your project website, but have not seen
> a response. Whom should I contact directly? I am trying to see whether your
> project still uses the Apache CMS and, if so, what your plans are to
> migrate off it.
> 
> Thanks in advance for your help.
> 
> Andrew
> 
> On Fri, Aug 7, 2020 at 10:06 AM Andrew Wetmore  wrote:
> 
> > Hi:
> >
> > I am part of the Infrastructure team, and am writing to ask whether your
> > project is still using the Apache CMS for your project website. As you
> > know, the CMS is reaching end-of-life, and we need projects to move their
> > websites onto a different option within the next few weeks.
> >
> > There are several alternatives available, including those listed on this
> > page [1] on managing project websites. Infra is assembling a Wiki page [2]
> > on migrating a website from the CMS, and is looking forward to helping
> > projects with this transition.
> >
> > Please let me know whether your site is still on the Apache CMS and, if
> > so, who will be the project point-of-contact with Infra for the migration.
> >
> > Thank you!
> >
> >
> >
> >
> > [1] https://infra.apache.org/project-site.html
> >
> > [2]
> > https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
> >
> >
> > --
> > Andrew Wetmore
> > Technical Writer-Editor
> > Infra
> > *Apache Software Foundation*
> > andr...@apache.org
> >
> >
> > 
> >  Virus-free.
> > www.avast.com
> > 
> > <#m_3918189248972690169_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> 
> 
> -- 
> Andrew Wetmore
> Technical Writer-Editor
> Infra
> *Apache Software Foundation*
> andr...@apache.org
>

[jira] [Commented] (THRIFT-5269) Contexts are missing from GO generated code

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183399#comment-17183399
 ] 

Duru Can Celasun commented on THRIFT-5269:
--

Sorry, we don't have a fixed schedule. It should be released this year though.

> Contexts are missing from GO generated code
> ---
>
> Key: THRIFT-5269
> URL: https://issues.apache.org/jira/browse/THRIFT-5269
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.13.0
> Environment: ubuntu, thrift 0.13.0, go 1.14.6
>Reporter: Paolo Elefante
>Priority: Trivial
>
> Hi,
> [Contexts|https://golang.org/pkg/context/#Context] are missing from golang 
> generated code.
> I'm on ubuntu, thrift 0.13.0 and go 1.14.6.
> To reproduce the fault just follow the Go Tutorial 
> ([link|https://thrift.apache.org/tutorial/go])
> Thanks. 
> BR, Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5269) Contexts are missing from GO generated code

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5269.
--
Resolution: Not A Problem

> Contexts are missing from GO generated code
> ---
>
> Key: THRIFT-5269
> URL: https://issues.apache.org/jira/browse/THRIFT-5269
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.13.0
> Environment: ubuntu, thrift 0.13.0, go 1.14.6
>Reporter: Paolo Elefante
>Priority: Blocker
>
> Hi,
> [Contexts|https://golang.org/pkg/context/#Context] are missing from golang 
> generated code.
> I'm on ubuntu, thrift 0.13.0 and go 1.14.6.
> To reproduce the fault just follow the Go Tutorial 
> ([link|https://thrift.apache.org/tutorial/go])
> Thanks. 
> BR, Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5269) Contexts are missing from GO generated code

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5269:
-
Priority: Trivial  (was: Blocker)

> Contexts are missing from GO generated code
> ---
>
> Key: THRIFT-5269
> URL: https://issues.apache.org/jira/browse/THRIFT-5269
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.13.0
> Environment: ubuntu, thrift 0.13.0, go 1.14.6
>Reporter: Paolo Elefante
>Priority: Trivial
>
> Hi,
> [Contexts|https://golang.org/pkg/context/#Context] are missing from golang 
> generated code.
> I'm on ubuntu, thrift 0.13.0 and go 1.14.6.
> To reproduce the fault just follow the Go Tutorial 
> ([link|https://thrift.apache.org/tutorial/go])
> Thanks. 
> BR, Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5269) Contexts are missing from GO generated code

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183373#comment-17183373
 ] 

Duru Can Celasun commented on THRIFT-5269:
--

OK, I see the problem. You are trying to use the Go library from master, but 
the compiler from 0.13. This is unsupported. Context support for protocol 
read/write methods were added in [this 
commit|https://github.com/apache/thrift/commit/e79f764f09afdfe829a06ca721059d34244d7c20],
 which will only be included in the upcoming 0.14 release.

Make sure to use the same version for library and compiler.

> Contexts are missing from GO generated code
> ---
>
> Key: THRIFT-5269
> URL: https://issues.apache.org/jira/browse/THRIFT-5269
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.13.0
> Environment: ubuntu, thrift 0.13.0, go 1.14.6
>Reporter: Paolo Elefante
>Priority: Blocker
>
> Hi,
> [Contexts|https://golang.org/pkg/context/#Context] are missing from golang 
> generated code.
> I'm on ubuntu, thrift 0.13.0 and go 1.14.6.
> To reproduce the fault just follow the Go Tutorial 
> ([link|https://thrift.apache.org/tutorial/go])
> Thanks. 
> BR, Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5269) Contexts are missing from GO generated code

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183362#comment-17183362
 ] 

Duru Can Celasun commented on THRIFT-5269:
--

Missing where? There are many places where contexts are used. The generated 
service looks fine to me:
{code:java}
type Calculator interface {
  shared.SharedService
  //Ahh, now onto the cool part, defining a service. Services just need a name
  //and can optionally inherit from another service using the extends keyword.  
// A method definition looks like C code. It has a return type, arguments,
  // and optionally a list of exceptions that it may throw. Note that argument
  // lists and exception lists are specified using the exact same syntax as
  // field lists in struct or exception definitions.
  Ping(ctx context.Context) (err error)
  // Parameters:
  //  - Num1
  //  - Num2
  Add(ctx context.Context, num1 int32, num2 int32) (r int32, err error)
  // Parameters:
  //  - Logid
  //  - W
  Calculate(ctx context.Context, logid int32, w *Work) (r int32, err error)
  // This method has a oneway modifier. That means the client only makes
  // a request and does not listen for any response at all. Oneway methods
  // must be void.
  Zip(ctx context.Context) (err error)
}
{code}

> Contexts are missing from GO generated code
> ---
>
> Key: THRIFT-5269
> URL: https://issues.apache.org/jira/browse/THRIFT-5269
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.13.0
> Environment: ubuntu, thrift 0.13.0, go 1.14.6
>Reporter: Paolo Elefante
>Priority: Blocker
>
> Hi,
> [Contexts|https://golang.org/pkg/context/#Context] are missing from golang 
> generated code.
> I'm on ubuntu, thrift 0.13.0 and go 1.14.6.
> To reproduce the fault just follow the Go Tutorial 
> ([link|https://thrift.apache.org/tutorial/go])
> Thanks. 
> BR, Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5233) I/O timeout handling in go library

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5233.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> I/O timeout handling in go library
> --
>
> Key: THRIFT-5233
> URL: https://issues.apache.org/jira/browse/THRIFT-5233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler, Go - Library
>Affects Versions: 0.13.0
>Reporter: Yuxuan Wang
>Priority: Major
>  Labels: Breaking-Change
> Fix For: 0.14.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> While debugging the bug in the first implementation of THRIFT-5214, I started 
> to look into the rabbit hole of I/O timeouts in the go library (mainly the 
> socket timeout on TSocket), and start to realize that the current way we 
> handle it is not great.
> From client's perspective, how a request goes is:
> client prepare the request TStruct -> send the request over the wire -> start 
> reading the response over the wire -> handle the response or I/O error
> The problem here, is that server will only send the first byte of response 
> out after it finished processing the request. So if the client incorrectly 
> configured a socket timeout on the TSocket used by this request to a value 
> that's too low, the reading will just report i/o timeout when the deadline 
> reaches, and the client will just fail the whole request.
> This will cause problems:
> # Client can't set socket timeout to something too low. In fact, if they use 
> a client pool (so for most requests there's no overhead on connecting), they 
> need the socket timeout to be at least the latency SLA of the server they 
> talk to, otherwise there's a serious risk that the client will fail a lot of 
> requests prematurely.
> # On the other hand, setting the socket timeout to something too high is also 
> a bad practice. In case that server is overloaded and cannot handle requests 
> in a timely fashion, client should have a way to fail faster, instead of 
> waiting for a very long timeout to expire.
> If the client set a deadline on the context object with the call, their 
> expectation usually would be that the request will fail after the deadline 
> passed (a small overhead is usually acceptable). But the socket timeout is 
> usually some fixed value configured to the program, while the actual deadline 
> on the context is more variable (e.g. this could be a server talking to 
> upstream server, it has a fixed totally deadline for the whole endpoint, but 
> the steps before that might take variable time so the deadline left here can 
> vary a lot).
> This leads to the point that we would need a way to keep socket timeout and 
> the deadline set in the context object in-sync.
> There are a few different options. The first obvious one, is to pass the 
> context object all the way to TSocket.Read, so that function can extract the 
> deadline out of the context object (if any), and set that as the socket 
> timeout instead of the pre-configured, fixed one.
> But that is also easy to be ruled out, because that would change the function 
> signature of TSocket.Read, making TSocket no longer implement io.Reader 
> interface.
> The next option, I think, is to handle it on TProtocol level. The idea is 
> that we pass the context object all the way into TProtocol.ReadMessageBegin 
> (and maybe other read functions of TProcotol?). This way, it can handle the 
> read errors, check if it's a timeout error, and if it is and the context 
> deadline haven't passed, it can just keep retrying again. This way, we can 
> set the fixed socket timeout to a low number when we know we will always have 
> a real deadline in the context attached, and just let TProtocol 
> implementation to keep retrying instead. If the user don't attach a deadline 
> to the context object, then they still need to set a large number on the 
> socket timeout.
> A slightly different option, is to add SetReadTimeout function to TTransport 
> interface. So all the TTransport implementations wrapping TSocket should just 
> pass that along. If the terminal one is actually not a TSocket (for example, 
> it's TMemoryBuffer), then this function just does nothing. This way, the 
> TProtocol.Read* functions can just extract deadline out of the context 
> object, and call their TTransport.SetReadTimeout with that deadline.
> Either way, this is going to be a breaking change that we need to add context 
> object to TProtocol.Read* function signatures. As a result, I believe some 
> compiler chan

[jira] [Commented] (THRIFT-5233) I/O timeout handling in go library

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134564#comment-17134564
 ] 

Duru Can Celasun commented on THRIFT-5233:
--

> I started to look into the rabbit hole of I/O timeouts in the go library 
> (mainly the socket timeout on TSocket), and start to realize that the current 
> way we handle it is not great.

Yeah, most of that code predates context in stdlib so there is nothing more 
granular than the socket timeout. The problem you describe is valid, but 
honestly none of the options seem ideal.

Option 1 is definitely off the table. If I understand your proposal correctly, 
option 2 only breaks TProtocol whereas option 3 breaks TTransport as well. 
Custom TProtocol in the wild are rare, but we should definitely try to avoid 
breaking TTransport. So if you'd like to open a PR, let's go with option 2.

Even then, it's a fairly big BC break. I don't like it, but we broke 
compatibility for context propagation before and this is more of the same.

> I believe some compiler change might also be required to pass it all the way 
> to TProtocol calls.

Yes, I think you'll have to pass the context into various iprot.Read* calls in 
the compiler but that should be a small change.

> I/O timeout handling in go library
> --
>
> Key: THRIFT-5233
> URL: https://issues.apache.org/jira/browse/THRIFT-5233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler, Go - Library
>Affects Versions: 0.13.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> While debugging the bug in the first implementation of THRIFT-5214, I started 
> to look into the rabbit hole of I/O timeouts in the go library (mainly the 
> socket timeout on TSocket), and start to realize that the current way we 
> handle it is not great.
> From client's perspective, how a request goes is:
> client prepare the request TStruct -> send the request over the wire -> start 
> reading the response over the wire -> handle the response or I/O error
> The problem here, is that server will only send the first byte of response 
> out after it finished processing the request. So if the client incorrectly 
> configured a socket timeout on the TSocket used by this request to a value 
> that's too low, the reading will just report i/o timeout when the deadline 
> reaches, and the client will just fail the whole request.
> This will cause problems:
> # Client can't set socket timeout to something too low. In fact, if they use 
> a client pool (so for most requests there's no overhead on connecting), they 
> need the socket timeout to be at least the latency SLA of the server they 
> talk to, otherwise there's a serious risk that the client will fail a lot of 
> requests prematurely.
> # On the other hand, setting the socket timeout to something too high is also 
> a bad practice. In case that server is overloaded and cannot handle requests 
> in a timely fashion, client should have a way to fail faster, instead of 
> waiting for a very long timeout to expire.
> If the client set a deadline on the context object with the call, their 
> expectation usually would be that the request will fail after the deadline 
> passed (a small overhead is usually acceptable). But the socket timeout is 
> usually some fixed value configured to the program, while the actual deadline 
> on the context is more variable (e.g. this could be a server talking to 
> upstream server, it has a fixed totally deadline for the whole endpoint, but 
> the steps before that might take variable time so the deadline left here can 
> vary a lot).
> This leads to the point that we would need a way to keep socket timeout and 
> the deadline set in the context object in-sync.
> There are a few different options. The first obvious one, is to pass the 
> context object all the way to TSocket.Read, so that function can extract the 
> deadline out of the context object (if any), and set that as the socket 
> timeout instead of the pre-configured, fixed one.
> But that is also easy to be ruled out, because that would change the function 
> signature of TSocket.Read, making TSocket no longer implement io.Reader 
> interface.
> The next option, I think, is to handle it on TProtocol level. The idea is 
> that we pass the context object all the way into TProtocol.ReadMessageBegin 
> (and maybe other read functions of TProcotol?). This way, it can handle the 
> read errors, check if it's a timeout error, and if it is and the context 
> deadline haven't passed, it can just keep retrying again. This way, we can 
> set the fixed socket timeout to a low number when we k

[jira] [Comment Edited] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134473#comment-17134473
 ] 

Duru Can Celasun edited comment on THRIFT-5164 at 6/12/20, 7:35 PM:


I think both approaches have their merits. [~fishywang]'s minimal approach is 
cleaner by being limited to the library, which is why I quite liked it and 
accepted the PR.

The [other one|https://github.com/apache/thrift/pull/1992] is much heavier and 
requires extensive changes to the compiler. I'm not opposed to it in principle 
and I like that it makes it easier to intercept RPC parameters, but it adds a 
lot of verbosity and duplicated code to the generator output for something 
that's not strictly necessary. As [~fishywang] showed above, 
ProcessorMiddleware can be used to the same effect, it just needs a bit of 
manual mapping.

There is also the fact that the thrift project is understaffed nowadays and 
active contributors who understand the compiler are few, so I'm hesitant to 
increase our maintenance burden when the same functionality can be achieved in 
user code.

That said, I still haven't made up my mind about it so the PR remains open.


was (Author: calcifer):
I think both approaches have their merits. [~fishywang]'s minimal approach is 
cleaner by being limited to the library, which is why I quite liked it and 
accepted the PR.

The [other one|https://github.com/apache/thrift/pull/1992] is much heavier and 
requires extensive changes to the compiler. I'm not opposed to it in principle, 
but it adds a lot of verbosity and duplicated code to the generator output for 
something that's not strictly necessary. As [~fishywang] showed above, 
ProcessorMiddleware can be used to the same effect, it just needs a bit of 
manual mapping.

There is also the fact that the thrift project is understaffed nowadays and 
active contributors who understand the compiler are few, so I'm hesitant to 
increase our maintenance burden when the same functionality can be achieved in 
user code.

That said, I still haven't made up my mind about it so the PR remains open.

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>    Assignee: Duru Can Celasun
>Priority: Major
>  Labels: Breaking-Change
> Fix For: 0.14.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134473#comment-17134473
 ] 

Duru Can Celasun commented on THRIFT-5164:
--

I think both approaches have their merits. [~fishywang]'s minimal approach is 
cleaner by being limited to the library, which is why I quite liked it and 
accepted the PR.

The [other one|https://github.com/apache/thrift/pull/1992] is much heavier and 
requires extensive changes to the compiler. I'm not opposed to it in principle, 
but it adds a lot of verbosity and duplicated code to the generator output for 
something that's not strictly necessary. As [~fishywang] showed above, 
ProcessorMiddleware can be used to the same effect, it just needs a bit of 
manual mapping.

There is also the fact that the thrift project is understaffed nowadays and 
active contributors who understand the compiler are few, so I'm hesitant to 
increase our maintenance burden when the same functionality can be achieved in 
user code.

That said, I still haven't made up my mind about it so the PR remains open.

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>    Assignee: Duru Can Celasun
>Priority: Major
>  Labels: Breaking-Change
> Fix For: 0.14.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Docker build not working as expected?

[Duru Can Celasun]

On Wed, 3 Jun 2020, at 08:49, Mario Emmenlauer wrote:
> 
> Hi Can and all,
> 
> On 03.06.20 00:14, Duru Can Celasun wrote:
> > Hi,
> > 
> > On Tue, 2 Jun 2020, at 21:56, Mario Emmenlauer wrote:
> >>
> >> Hi all,
> >>
> >> whenever I check the Travis builds, I see that many of them take
> >> a significant portion of their time to build new docker images. I've
> >> checked the Travis build instructions but is not completely obvious
> >> what the desired behavior would be. Is somebody maintaining this
> >> and could take a look?
> > 
> > I think James King (jking) was maintaining the Docker images, but that was 
> > at least a year ago and he doesn't seem to be active anymore. I'd say feel 
> > free to make any improvements.
> > 
> >>
> >> In short, I'm under the impression that the docker-stages do _not_
> >> build and push the updated docker images, and therefore subsequent
> >> build jobs _do_ build updated images but lack the push credentials.
> >>
> >> Rather than just looking for the flaw in this, I would prefer to
> >> build docker images completely independent of the build jobs.
> >> I think a cron job and a completely separated build logic would be
> >> better and easier to maintain?
> > 
> > Cron jobs would require us to talk to INFRA and have them setup some sort 
> > of system and I'm hesitant to create yet another thing we'd have to 
> > maintain. We're already struggling as is (e.g the npm package situation).
> 
> I agree that low maintenance overhead is a very high goal. I'm not
> very knowledgable with Travis. Does it directly allow cron jobs?
> I found something here: https://docs.travis-ci.com/user/cron-jobs/
> but I've never seen the admin interface. Do you know who can do
> admin maintenance on Travis?

I wasn't aware Travis had cron jobs either but it seems like I have access to 
the settings and I can setup new cron jobs for the master branch.

> 
> I'm really open to any ideas, but generally I think building the
> docker images and the normal build jobs together may not be the
> "easiest" route. I could even think a separate thrift-docker-images
> project would be simpler. Would that be an idea?

I think we can keep it as a single repository, but skip the docker images if 
the build is not triggered by cron. Travis says we can check for 
TRAVIS_EVENT_TYPE=cron environment variable.

What do you think?

Best,
Can

> 
> All the best,
> 
> Mario
> 
> 
> >>
> >> All the best,
> >>
> >>  Mario Emmenlauer
> >>
> >>
> >> --
> >> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> >> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> >> D-81669 München  http://www.biodataanalysis.de/
> >>
> > 
> 
> 
> 
> Viele Gruesse,
> 
> Mario Emmenlauer
> 
> 
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
>

Re: Docker build not working as expected?

[Duru Can Celasun]

Hi,

On Tue, 2 Jun 2020, at 21:56, Mario Emmenlauer wrote:
> 
> Hi all,
> 
> whenever I check the Travis builds, I see that many of them take
> a significant portion of their time to build new docker images. I've
> checked the Travis build instructions but is not completely obvious
> what the desired behavior would be. Is somebody maintaining this
> and could take a look?

I think James King (jking) was maintaining the Docker images, but that was at 
least a year ago and he doesn't seem to be active anymore. I'd say feel free to 
make any improvements.

> 
> In short, I'm under the impression that the docker-stages do _not_
> build and push the updated docker images, and therefore subsequent
> build jobs _do_ build updated images but lack the push credentials.
> 
> Rather than just looking for the flaw in this, I would prefer to
> build docker images completely independent of the build jobs.
> I think a cron job and a completely separated build logic would be
> better and easier to maintain?

Cron jobs would require us to talk to INFRA and have them setup some sort of 
system and I'm hesitant to create yet another thing we'd have to maintain. 
We're already struggling as is (e.g the npm package situation).

Best,
Can

> 
> All the best,
> 
> Mario Emmenlauer
> 
> 
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
>

[jira] [Commented] (THRIFT-5214) go: Implement connection check in TSocket

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17118910#comment-17118910
 ] 

Duru Can Celasun commented on THRIFT-5214:
--

[~fishywang] 0.14 isn't a concern right now so we can wait a few days. Can you 
share what exactly went wrong? Increased latency, error rates?

Before merging I've played with your PR locally and it seemed fine. We only 
have Go servers, not clients at work so there is no real traffic I can test it 
on.

> go: Implement connection check in TSocket
> -
>
> Key: THRIFT-5214
> URL: https://issues.apache.org/jira/browse/THRIFT-5214
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The first issue described in [this GitHub engineering blog 
> article|https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-driver/] is 
> also an issue when we use thrift client pools. We implemented a thrift client 
> pool by checking client's TTransport.IsOpen before using that client, and 
> also added (arbitrary) TTL to the clients to avoid using clients that's been 
> opened for too long, but we still occasionally get broken pipes and 
> unexpected EOF errors when using those clients. I think implementing the same 
> connection check described by that article in TSocket.IsOpen (and/or when try 
> to read 0 byte from TSocket.Read) would greatly help the situation.
> But there are a few limitations of the connection check implementation, and 
> I'm not sure how acceptable are they in the thrift library:
> 1. It only works on non-windows systems (so for windows we'll have to 
> fallback to the old IsOpen implementation, I guess?)
> 2. It requires go 1.9+, what's thrift library's minimal go version supported?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5214) go: Implement connection check in TSocket

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5214.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> go: Implement connection check in TSocket
> -
>
> Key: THRIFT-5214
> URL: https://issues.apache.org/jira/browse/THRIFT-5214
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The first issue described in [this GitHub engineering blog 
> article|https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-driver/] is 
> also an issue when we use thrift client pools. We implemented a thrift client 
> pool by checking client's TTransport.IsOpen before using that client, and 
> also added (arbitrary) TTL to the clients to avoid using clients that's been 
> opened for too long, but we still occasionally get broken pipes and 
> unexpected EOF errors when using those clients. I think implementing the same 
> connection check described by that article in TSocket.IsOpen (and/or when try 
> to read 0 byte from TSocket.Read) would greatly help the situation.
> But there are a few limitations of the connection check implementation, and 
> I'm not sure how acceptable are they in the thrift library:
> 1. It only works on non-windows systems (so for windows we'll have to 
> fallback to the old IsOpen implementation, I guess?)
> 2. It requires go 1.9+, what's thrift library's minimal go version supported?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5214) go: Implement connection check in TSocket

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113828#comment-17113828
 ] 

Duru Can Celasun commented on THRIFT-5214:
--

1. Github's fix for that issue was also non-windows only, but I'm not sure why. 
Windows sockets seem to have EWOULDBLOCK (as 
[WSAEWOULDBLOCK|https://docs.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2])
 as well but I'm not really familiar with Windows so I can't be sure. In any 
case, a non-windows build tag is fine.
2. [Officially|https://github.com/apache/thrift/blob/v0.13.0/LANGUAGES.md] we 
support 1.10.8+ so that should be fine.

> go: Implement connection check in TSocket
> -
>
> Key: THRIFT-5214
> URL: https://issues.apache.org/jira/browse/THRIFT-5214
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>
> The first issue described in [this GitHub engineering blog 
> article|https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-driver/] is 
> also an issue when we use thrift client pools. We implemented a thrift client 
> pool by checking client's TTransport.IsOpen before using that client, and 
> also added (arbitrary) TTL to the clients to avoid using clients that's been 
> opened for too long, but we still occasionally get broken pipes and 
> unexpected EOF errors when using those clients. I think implementing the same 
> connection check described by that article in TSocket.IsOpen (and/or when try 
> to read 0 byte from TSocket.Read) would greatly help the situation.
> But there are a few limitations of the connection check implementation, and 
> I'm not sure how acceptable are they in the thrift library:
> 1. It only works on non-windows systems (so for windows we'll have to 
> fallback to the old IsOpen implementation, I guess?)
> 2. It requires go 1.9+, what's thrift library's minimal go version supported?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5209) WIP: Support TinyGo

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106975#comment-17106975
 ] 

Duru Can Celasun commented on THRIFT-5209:
--

I'm generally open to this sort of addition to Thrift's Go support and the diff 
so far seems small enough to not create any maintenance headaches.

That said, I do have a few concerns:

- The transports and protocols supported for Go with the gc compiler is listed 
[here|https://github.com/apache/thrift/blob/26e6c84cde490a22d39c43ba3903dd94bbb8497f/LANGUAGES.md].
 Since TinyGo can't support all of them, it will need a separate entry on that 
table.

- Tests. There are tests that use encoding/json. These will either have to be 
updated, or have separate TinyGo versions guarded by build tags.

- Continuous Integration. TinyGo must be added to the Travis CI config and must 
support [cross 
tests|https://github.com/apache/thrift/tree/master/test#apache-thrift---integration-test-suite]
 which tests every language against every other language.

- Server support. Are you planning to support servers or just clients? Servers 
implement 
[TServerTransport|https://github.com/apache/thrift/blob/26e6c84cde490a22d39c43ba3903dd94bbb8497f/lib/go/thrift/server_transport.go#L23-L34]
 and usually depend on net.

> Personally I think I would lean toward using the "Android" model I described 
> above with a single generator/library using a compiler option and build 
> flags, respectively. 

I agree.

> WIP: Support TinyGo
> ---
>
> Key: THRIFT-5209
> URL: https://issues.apache.org/jira/browse/THRIFT-5209
> Project: Thrift
>  Issue Type: New Feature
>  Components: Go - Compiler, Go - Library
>Reporter: Benjamin Gould
>Priority: Minor
>
> TinyGo ([https://tinygo.org/)] provides a compiler for the Go programming 
> language that is an alternative to the standard Go compiler and is based on 
> LLVM.  It uses the standard Go toolchain to compile programs to Go's SSA 
> format, and then translates the SSA to LLVM IR that can subsequently be 
> compiled for various microcontrollers, wasm, or Linux.  The important 
> takeaway from that explanation is that since TinyGo programs use the standard 
> Go compiler for the compiler frontend, is not is a subset of the Go language 
> - it is the same language, with some small caveats.
> The main caveat as far as Thrift support is concerned is that not all 
> packages in the standard library are supported yet, including the {{net}} and 
> {{encoding/json}} packages.  This presents an obvious problem for using 
> Thrift, since these packages are imported by the Thrift Go library.  
> Additionally, some small tweaks to the code from the compiler are necessary 
> to work around limited support for the {{reflect}} and {{database/sql 
> packages}}.
> In general, Thrift can work with TinyGo, but until TinyGo gains more complete 
> support for the standard library it does require a compiler flag and 
> excluding a number of features of the Thrift Go library.
> Initial support for TinyGo is found here: 
> [https://github.com/bgould/thrift/tree/fc2f380a2a390860160df851e9a9698f8e3c66f4]
> However I have the following questions about the best way to proceed:
>  # Should TinyGo support be implemented in the compiler via a flag on the Go 
> generator that eliminates references to packages unsupported by TinyGo such 
> as reflect and database/sql from the generated code?  This would be similar 
> in concept I think to the -android option to the Java generator. 
> Alternatively, should a separate generator altogether be added, in the same 
> way that Java and JavaME are separate generators in Thrift?  For reference, 
> the scope of the changes to the Go generator for supporting TinyGo are 
> roughly this - 
> [https://github.com/bgould/thrift/commit/f1a57bf94731a262b68d5a519bcbbb4c8c303a23#diff-36ef31e670e3df20e286373dfb7ecc23]
>  # Similarly, the changes in the Thrift library can mostly be implemented by 
> adding build tags to exclude unsupported transports etc when compiling for 
> TinyGo (the TinyGo compiler sets a {{tinygo}} build tag automatically for all 
> TinyGo builds).  It would also be feasible to maintain a separate library 
> that is explicitly compatible with TinyGo.  Again, the analogy of the 
> distinction between Java/Android and Java/JavaME applies here I think.  The 
> sorts of changes necessary are like this: 
> https://github.com/bgould/thrift/commit/f1a57bf94731a262b68d5a519bcbbb4c8c303a23#diff-90f0f50bdfa55c6a4a1d53580c103ae0
> The main reason I am asking these questions is that I would really like to 
> land this feature, and the same time want to make sure it does not 

[jira] [Commented] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17105554#comment-17105554
 ] 

Duru Can Celasun commented on THRIFT-5205:
--

I think doing "go get library@revision" only in libA would solve your problem.

> the leaf repositories cannot inherit this restriction since it's not a 
> constraint that Go modules can follow

Are you sure? I'm not aware of anything in the module spec that says this. Can 
you share a repo, even a dummy one, to reproduce this problem?

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Prashant V
>Priority: Minor
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5205:
-
Issue Type: Wish  (was: Task)

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Prashant V
>Priority: Blocker
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17105132#comment-17105132
 ] 

Duru Can Celasun edited comment on THRIFT-5205 at 5/12/20, 6:34 AM:


v0.12.0 is already [tagged|https://github.com/apache/thrift/tree/v0.12.0] with 
the "v" prefix.

If you need to use older versions, you can simply use "go get" with a specific 
commit hash. For example 0.11.0 was tagged on [this 
commit|https://github.com/apache/thrift/commit/327ebb6c2b6df8bf075da02ef45a2a034e9b79ba]
 and you can simply run:

{code}
$ go get github.com/apache/thrift@327ebb6c2b6df8bf075da02ef45a2a034e9b79ba
{code}

and your go.mod file will look like this:

{code}
module github.com/example/project

go 1.14

require github.com/apache/thrift v0.0.0-20171203172758-327ebb6c2b6d // indirect
{code}


was (Author: calcifer):
v0.12.0 is already [tagged|https://github.com/apache/thrift/tree/v0.12.0] with 
the "v" prefix.

If you need to use older version, you can simply use "go get" with a specific 
commit hash. For example 0.11.0 was tagged on [this 
commit|https://github.com/apache/thrift/commit/327ebb6c2b6df8bf075da02ef45a2a034e9b79ba]
 and you can simply run:

{code}
$ go get github.com/apache/thrift@327ebb6c2b6df8bf075da02ef45a2a034e9b79ba
{code}

and your go.mod file will look like this:

{code}
module github.com/example/project

go 1.14

require github.com/apache/thrift v0.0.0-20171203172758-327ebb6c2b6d // indirect
{code}

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Prashant V
>Priority: Minor
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5205:
-
Affects Version/s: (was: 0.12.0)

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Prashant V
>Priority: Blocker
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17105132#comment-17105132
 ] 

Duru Can Celasun commented on THRIFT-5205:
--

v0.12.0 is already [tagged|https://github.com/apache/thrift/tree/v0.12.0] with 
the "v" prefix.

If you need to use older version, you can simply use "go get" with a specific 
commit hash. For example 0.11.0 was tagged on [this 
commit|https://github.com/apache/thrift/commit/327ebb6c2b6df8bf075da02ef45a2a034e9b79ba]
 and you can simply run:

{code}
$ go get github.com/apache/thrift@327ebb6c2b6df8bf075da02ef45a2a034e9b79ba
{code}

and your go.mod file will look like this:

{code}
module github.com/example/project

go 1.14

require github.com/apache/thrift v0.0.0-20171203172758-327ebb6c2b6d // indirect
{code}

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0, 0.12.0
>Reporter: Prashant V
>Priority: Blocker
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5205:
-
Priority: Minor  (was: Blocker)

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Prashant V
>Priority: Minor
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094199#comment-17094199
 ] 

Duru Can Celasun commented on THRIFT-5164:
--

I use something very similar with opencensus and it's definitely a good idea to 
have it upstream. Go ahead and send a PR :) 

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>    Assignee: Duru Can Celasun
>Priority: Major
>  Labels: Breaking-Change
> Fix For: 0.14.0
>
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5179) Thrift compiler will generate wrong code if IDL struct's name is 'a' or 'b'

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5179.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Thrift compiler will generate wrong code if IDL struct's name is 'a' or  'b'
> 
>
> Key: THRIFT-5179
> URL: https://issues.apache.org/jira/browse/THRIFT-5179
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Compiler
>Reporter: Zezeng Wang
>Assignee: Zezeng Wang
>Priority: Minor
> Fix For: 0.14.0
>
>
> test.thrift file is as below:
> struct a {
>  1: string name,
>  2: double price
> }
> struct b {
>  1: i8 size,
>  2: i32 seq
> }
> struct a1 {
>  1: i8 size,
>  2: i32 seq
> }
> struct a2 {
>  1: i8 size,
>  2: i32 seq
> }
> When struct is named as 'a' or 'b' will throw compile errors as below:
> In file included from test_constants.h:10:0,
>  from test_constants.cpp:7:
> test_types.h:76:17: error: ‘a’ is not a type
>  void swap(a , a );
>  ^
> In file included from test_types.cpp:7:0:
> test_types.h:76:17: error: ‘a’ is not a type
>  void swap(a , a );
>  ^
> test_types.cpp:102:17: error: ‘a’ is not a type
>  void swap(a , a ) {
>  ^
> test_types.cpp: In function ‘void swap(a&, int&)’:
> test_types.cpp:104:18: error: request for member ‘name’ in ‘b’, which is of 
> non-class type ‘int’
>  swap(a.name, b.name);
>  ^~~~
> test_types.cpp:105:19: error: request for member ‘price’ in ‘b’, which is of 
> non-class type ‘int’
>  swap(a.price, b.price);
>  ^
> test_types.cpp:106:21: error: request for member ‘__isset’ in ‘b’, which is 
> of non-class type ‘int’
>  swap(a.__isset, b.__isset);
>  ^~~



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5164.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>    Assignee: Duru Can Celasun
>Priority: Major
>  Labels: Breaking-Change
> Fix For: 0.14.0
>
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5184) D: WebSocket Server Transport Fix for Firefox

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5184.
--
Resolution: Fixed

> D: WebSocket Server Transport Fix for Firefox
> -
>
> Key: THRIFT-5184
> URL: https://issues.apache.org/jira/browse/THRIFT-5184
> Project: Thrift
>  Issue Type: Bug
>  Components: D - Library
>Affects Versions: 0.14.0
>Reporter: James Lacey
>Assignee: James Lacey
>Priority: Major
> Fix For: 0.14.0
>
>
> When establishing a WebSocket connection, Firefox sends Connection: 
> keep-alive, Upgrade instead of just Connection: Upgrade. Check to see if 
> Upgrade is in the header instead of checking to see if it is the entire 
> header value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun reassigned THRIFT-5164:


Assignee: Duru Can Celasun

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>    Assignee: Duru Can Celasun
>Priority: Major
>  Labels: Breaking-Change
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Is Travis CI building docker images?

[Duru Can Celasun]

CC'ing James King who did our Travis setup IIRC. 

On Fri, 24 Apr 2020, at 10:42, Mario Emmenlauer wrote:
> 
> In the past weeks I've had a significant number of failing Travis CI
> builds, the majority of which was failing in something that looked like
> a docker build.
> 
> Is it correct and intended that Travis builds, or at least updates, a
> docker image for every test? Maybe this step could be split out of the
> standard tests and moved to a dedicated task? This may have the down-
> side that tests would use whatever status the latest official docker
> image has, which may or may not be up-to-date with upstream ressoures.
> But it brings a significant speedup, much better error resilience and
> last, not least, a more reproducible test experience.
> 
> Can anyone comment about the current design?
> 
> All the best,
> 
> Mario
> 
>

[jira] [Resolved] (THRIFT-4282) StressTestNonBlocking is disabled in Appveyor as it is unstable on Windows in general

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-4282.
--
Fix Version/s: 0.14.0
   Resolution: Resolved

> StressTestNonBlocking is disabled in Appveyor as it is unstable on Windows in 
> general
> -
>
> Key: THRIFT-4282
> URL: https://issues.apache.org/jira/browse/THRIFT-4282
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.10.0
> Environment: Windows, Appveyor
>Reporter: James E. King III
>Priority: Major
> Fix For: 0.14.0
>
>
> I have not been able to complete most of my local builds including 
> StressTestNonBlocking because the test fails.  It is disabled in AppVeyor so 
> the builds will pass.  We need this test to be fixed so we can enable it for 
> CI builds again.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5171) Fix maven-ant-tasks to use HTTPS instead of HTTP

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5171.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Fix maven-ant-tasks to use HTTPS instead of HTTP
> 
>
> Key: THRIFT-5171
> URL: https://issues.apache.org/jira/browse/THRIFT-5171
> Project: Thrift
>  Issue Type: Bug
>  Components: Test Suite
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I ran {{make check}} in the lib/json directory and came across the following 
> error.
> {code:java}
> $ ./bootstrap.sh
> $ ./configure
> $ make
> $ cd lib/json
> $ make check
> (snip)
> mvn.init:
> [artifact:dependencies] Downloading: 
> com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.pom 
> from repository central at http://repo1.maven.org/maven2
> [artifact:dependencies] Error transferring file: Server returned HTTP 
> response code: 501 for URL: 
> http://repo1.maven.org/maven2/com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.pom
> [artifact:dependencies] [WARNING] Unable to get resource 
> 'com.github.fge:json-schema-validator:pom:2.2.6' from repository central 
> (http://repo1.maven.org/maven2): Error transferring file: Server returned 
> HTTP response code: 501 for URL: 
> http://repo1.maven.org/maven2/com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.pom
> [artifact:dependencies] Downloading: 
> com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.jar 
> from repository central at http://repo1.maven.org/maven2
> [artifact:dependencies] Error transferring file: Server returned HTTP 
> response code: 501 for URL: 
> http://repo1.maven.org/maven2/com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.jar
> [artifact:dependencies] [WARNING] Unable to get resource 
> 'com.github.fge:json-schema-validator:jar:2.2.6' from repository central 
> (http://repo1.maven.org/maven2): Error transferring file: Server returned 
> HTTP response code: 501 for URL: 
> http://repo1.maven.org/maven2/com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.jar
> [artifact:dependencies] An error has occurred while processing the Maven 
> artifact tasks.
> [artifact:dependencies]  Diagnosis:
> [artifact:dependencies] 
> [artifact:dependencies] Unable to resolve artifact: Missing:
> [artifact:dependencies] --
> [artifact:dependencies] 1) com.github.fge:json-schema-validator:jar:2.2.6
> [artifact:dependencies] 
> [artifact:dependencies]   Try downloading the file manually from the project 
> website.
> [artifact:dependencies] 
> [artifact:dependencies]   Then, install it using the command: 
> [artifact:dependencies]   mvn install:install-file 
> -DgroupId=com.github.fge -DartifactId=json-schema-validator -Dversion=2.2.6 
> -Dpackaging=jar -Dfile=/path/to/file
> [artifact:dependencies] 
> [artifact:dependencies]   Alternatively, if you host your own repository you 
> can deploy the file there: 
> [artifact:dependencies]   mvn deploy:deploy-file -DgroupId=com.github.fge 
> -DartifactId=json-schema-validator -Dversion=2.2.6 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [artifact:dependencies] 
> [artifact:dependencies]   Path to dependency: 
> [artifact:dependencies]   1) org.apache.maven:super-pom:pom:2.0
> [artifact:dependencies]   2) 
> com.github.fge:json-schema-validator:jar:2.2.6
> [artifact:dependencies] 
> [artifact:dependencies] --
> [artifact:dependencies] 1 required artifact is missing.
> [artifact:dependencies] 
> [artifact:dependencies] for artifact: 
> [artifact:dependencies]   org.apache.maven:super-pom:pom:2.0
> [artifact:dependencies] 
> [artifact:dependencies] from the specified remote repositories:
> [artifact:dependencies]   central (http://repo1.maven.org/maven2)
> [artifact:dependencies] 
> [artifact:dependencies] 
> BUILD FAILED
> /home/sekikn/repos/thrift/lib/json/test/build.xml:116: Unable to resolve 
> artifact: Missing:
> --
> 1) com.github.fge:json-schema-validator:jar:2.2.6
>   Try downloading the file manually from the project website.
>   Then, install it using the command: 
>   mvn install:install-file -DgroupId=com.github.fge 
> -DartifactId=json-schema-validator -Dversion=2.2.6 -Dpackaging=jar 
> -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can d

[jira] [Commented] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083083#comment-17083083
 ] 

Duru Can Celasun commented on THRIFT-5164:
--

I agree that middleware isn't exactly transferable between languages.

[~fishywang] your work overlaps with [this 
PR|https://github.com/apache/thrift/pull/1992] but judging by the baseplate 
repo I like your version better so a PR would definitely be appreciated.

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074391#comment-17074391
 ] 

Duru Can Celasun commented on THRIFT-5164:
--

I'm much more open to the idea today than I was back then. Your tracing 
middleware certainly looks much cleaner than what we use for tracing.

As for the interface, I'm happy to expand TProcessor for this. Please go ahead 
with the PR and I'll take a look.

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046188#comment-17046188
 ] 

Duru Can Celasun commented on THRIFT-4710:
--

That's good to know, thanks. We should stick to supported ways to reduce 
maintenance burden as much as possible.  Though I do remember Apache Airflow 
using readthedocs until recently, so it might already be supported by INFRA.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>    Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17045922#comment-17045922
 ] 

Duru Can Celasun commented on THRIFT-4710:
--

That can all be figured out later, once the new website is up and running. The 
more important work of building API docs on Travis with every commit can happen 
in parallel.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>    Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17045902#comment-17045902
 ] 

Duru Can Celasun commented on THRIFT-4710:
--

I don't personally have any plans for it but I'm happy to accept contributions 
to auto generate API docs for specific languages.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>    Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5113) Web-based developer and user chat?

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17045882#comment-17045882
 ] 

Duru Can Celasun commented on THRIFT-5113:
--

I've been slowly working on a new version of the website that unifies various 
bits of documentation here: https://issues.apache.org/jira/browse/THRIFT-4710 
It's quite stalled at this point, but I'd like to get back to it eventually. 
Contributions are welcome.

I agree that the current state of documentation is somewhere between lacking 
and abysmal and makes the project less approachable. However, nobody assigns 
tasks in thrift, so any improvements must come from volunteers and so far 
nobody has really stepped up to the (admittedly monumental) task.

I also generally agree about mailing lists. I grew up with them, but their 
suitability for attracting new talent decreases every day. I'd personally be 
happy to suggest the ASF Slack as the official communication medium on the 
website, but that should be approved by at least a few more PMC members.

> Web-based developer and user chat?
> --
>
> Key: THRIFT-5113
> URL: https://issues.apache.org/jira/browse/THRIFT-5113
> Project: Thrift
>  Issue Type: Wish
>Reporter: Mario Emmenlauer
>Priority: Minor
>
> I think it would be very helpful if there where a developer chat, where users 
> and developers could ask questions and get (sometimes) a response with 
> shorter turnaround times and less overhead. Is this something thrift 
> developers could consider?
> An often-used web-based chat with little overhead that integrates well with 
> github is [https://gitter.im/]. There are already a significant number of 
> Apache projects present:
>  * [https://gitter.im/apache/home]
> Relates to THRIFT-5112



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5107) Travis build fails with missing Python 3.3 or newer?

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042212#comment-17042212
 ] 

Duru Can Celasun commented on THRIFT-5107:
--

Nice find! Mind sending in a PR?

> Travis build fails with missing Python 3.3 or newer?
> 
>
> Key: THRIFT-5107
> URL: https://issues.apache.org/jira/browse/THRIFT-5107
> Project: Thrift
>  Issue Type: Improvement
>Reporter: Mario Emmenlauer
>Priority: Major
>
> The travis tests seem to fail because of a missing Python error. See 
> [https://travis-ci.org/apache/thrift/builds/653469766?utm_source=github_status_medium=notification]
> I would like to help fix this, but I do not understand how travis docker 
> images are set or created. Can someone help?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5075) Backport fixes for CVE-2019-0205 to (Java) 0.9.3-1 version

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023641#comment-17023641
 ] 

Duru Can Celasun commented on THRIFT-5075:
--

I don't think it's a good idea either. Which specific projects are still 
depending on a half a decade old version of thrift and what exactly is blocking 
them from upgrading to a newer version?

> Backport fixes for CVE-2019-0205 to (Java) 0.9.3-1 version
> --
>
> Key: THRIFT-5075
> URL: https://issues.apache.org/jira/browse/THRIFT-5075
> Project: Thrift
>  Issue Type: Bug
>Reporter: Laurent Goujon
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Similar to THRIFT-4506, would it be possible to backport fixes for 
> CVE-2019-0205 to 0.9.x branch. There are still several projects still relying 
> on 0.9.3-1, and the vulnerability seems to impact them as well.
> I believe the fix for Java was part of THRIFT-4024



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5069) Go: TDserializer is not resource pool friendly

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5069.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Go: TDserializer is not resource pool friendly
> --
>
> Key: THRIFT-5069
> URL: https://issues.apache.org/jira/browse/THRIFT-5069
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently TSerializer is resource pool friendly (see 
> [here|https://github.com/reddit/baseplate.go/blob/7b73f185eacd319a018df85d683fb2c29b50e2a9/events/events.go#L105-L111]
>  for an example), but TDeserializer is not. When putting a TDeserializer back 
> into resource pool, some extra works need to be done:
> {code:go}
> defer func() {
>   deserializer.Transport.(*thrift.TMemoryBuffer).Reset()
>   deserializerPool.Put(deserializer)
> }()
> {code}
> If we change the type of TDeserializer.Transport to *TMemoryBuffer, and also 
> call Transport.Reset() at the beginning of Read and ReadString (we already do 
> both in TSerializer), it will make it more resource pool friendly.
> This will be a breaking change, though.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5069) Go: TDserializer is not resource pool friendly

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018526#comment-17018526
 ] 

Duru Can Celasun commented on THRIFT-5069:
--

OK, sounds good. Let's include that in this PR.

> Go: TDserializer is not resource pool friendly
> --
>
> Key: THRIFT-5069
> URL: https://issues.apache.org/jira/browse/THRIFT-5069
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently TSerializer is resource pool friendly (see 
> [here|https://github.com/reddit/baseplate.go/blob/7b73f185eacd319a018df85d683fb2c29b50e2a9/events/events.go#L105-L111]
>  for an example), but TDeserializer is not. When putting a TDeserializer back 
> into resource pool, some extra works need to be done:
> {code:go}
> defer func() {
>   deserializer.Transport.(*thrift.TMemoryBuffer).Reset()
>   deserializerPool.Put(deserializer)
> }()
> {code}
> If we change the type of TDeserializer.Transport to *TMemoryBuffer, and also 
> call Transport.Reset() at the beginning of Read and ReadString (we already do 
> both in TSerializer), it will make it more resource pool friendly.
> This will be a breaking change, though.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5069) Go: TDserializer is not resource pool friendly

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018163#comment-17018163
 ] 

Duru Can Celasun commented on THRIFT-5069:
--

[~fishywang] it could be useful, depends on what exactly you have in mind. Is 
it just a wrapper around sync.Pool?

> Go: TDserializer is not resource pool friendly
> --
>
> Key: THRIFT-5069
> URL: https://issues.apache.org/jira/browse/THRIFT-5069
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently TSerializer is resource pool friendly (see 
> [here|https://github.com/reddit/baseplate.go/blob/7b73f185eacd319a018df85d683fb2c29b50e2a9/events/events.go#L105-L111]
>  for an example), but TDeserializer is not. When putting a TDeserializer back 
> into resource pool, some extra works need to be done:
> {code:go}
> defer func() {
>   deserializer.Transport.(*thrift.TMemoryBuffer).Reset()
>   deserializerPool.Put(deserializer)
> }()
> {code}
> If we change the type of TDeserializer.Transport to *TMemoryBuffer, and also 
> call Transport.Reset() at the beginning of Read and ReadString (we already do 
> both in TSerializer), it will make it more resource pool friendly.
> This will be a breaking change, though.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017960#comment-17017960
 ] 

Duru Can Celasun commented on THRIFT-5068:
--

Thanks for the PR! Travis is all green now.

> CI is broken due to http://repo1.maven.org
> --
>
> Key: THRIFT-5068
> URL: https://issues.apache.org/jira/browse/THRIFT-5068
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>        Reporter: Duru Can Celasun
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Upstream has 
> [removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
> for HTTP based access. I've 
> [updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
>  all references I could find, but the build is [still 
> broken|https://travis-ci.org/apache/thrift/builds/637642594] as we somehow 
> still have references to the HTTP endpoint.
> [~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5068.
--
Resolution: Fixed

> CI is broken due to http://repo1.maven.org
> --
>
> Key: THRIFT-5068
> URL: https://issues.apache.org/jira/browse/THRIFT-5068
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>        Reporter: Duru Can Celasun
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Upstream has 
> [removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
> for HTTP based access. I've 
> [updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
>  all references I could find, but the build is [still 
> broken|https://travis-ci.org/apache/thrift/builds/637642594] as we somehow 
> still have references to the HTTP endpoint.
> [~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017881#comment-17017881
 ] 

Duru Can Celasun commented on THRIFT-5068:
--

Thanks, that does seem to be the cause. I won't have time to investigate this 
in the next few weeks, so PRs are appreciated.

> CI is broken due to http://repo1.maven.org
> --
>
> Key: THRIFT-5068
> URL: https://issues.apache.org/jira/browse/THRIFT-5068
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>        Reporter: Duru Can Celasun
>Priority: Major
>
> Upstream has 
> [removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
> for HTTP based access. I've 
> [updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
>  all references I could find, but the build is [still 
> broken|https://travis-ci.org/apache/thrift/builds/637642594] as we somehow 
> still have references to the HTTP endpoint.
> [~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016374#comment-17016374
 ] 

Duru Can Celasun commented on THRIFT-5068:
--

This has effected other Apache projects as well: 
https://issues.apache.org/jira/browse/THRIFT-5068?jql=summary%20~%20%22repo1.maven.org*%22%20OR%20description%20~%20%22repo1.maven.org*%22%20ORDER%20BY%20created%20DESC

> CI is broken due to http://repo1.maven.org
> --
>
> Key: THRIFT-5068
> URL: https://issues.apache.org/jira/browse/THRIFT-5068
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>        Reporter: Duru Can Celasun
>Priority: Major
>
> Upstream has 
> [removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
> for HTTP based access. I've 
> [updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
>  all references I could find, but the build is [still 
> broken](https://travis-ci.org/apache/thrift/builds/637642594) as we somehow 
> still have references to the HTTP endpoint.
> [~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5068:
-
Description: 
Upstream has 
[removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
for HTTP based access. I've 
[updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
 all references I could find, but the build is [still 
broken|https://travis-ci.org/apache/thrift/builds/637642594] as we somehow 
still have references to the HTTP endpoint.

[~jensg] any ideas?

  was:
Upstream has 
[removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
for HTTP based access. I've 
[updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
 all references I could find, but the build is [still 
broken](https://travis-ci.org/apache/thrift/builds/637642594) as we somehow 
still have references to the HTTP endpoint.

[~jensg] any ideas?


> CI is broken due to http://repo1.maven.org
> --
>
> Key: THRIFT-5068
> URL: https://issues.apache.org/jira/browse/THRIFT-5068
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>        Reporter: Duru Can Celasun
>Priority: Major
>
> Upstream has 
> [removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
> for HTTP based access. I've 
> [updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
>  all references I could find, but the build is [still 
> broken|https://travis-ci.org/apache/thrift/builds/637642594] as we somehow 
> still have references to the HTTP endpoint.
> [~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

Duru Can Celasun created THRIFT-5068:


 Summary: CI is broken due to http://repo1.maven.org
 Key: THRIFT-5068
 URL: https://issues.apache.org/jira/browse/THRIFT-5068
 Project: Thrift
  Issue Type: Bug
  Components: Build Process
Reporter: Duru Can Celasun


Upstream has 
[removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
for HTTP based access. I've 
[updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
 all references I could find, but the build is [still 
broken](https://travis-ci.org/apache/thrift/builds/637642594) as we somehow 
still have references to the HTTP endpoint.

[~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5003) Websocket Connection in Browsers with nodejs code

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5003.
--
Resolution: Fixed

> Websocket Connection in Browsers with nodejs code
> -
>
> Key: THRIFT-5003
> URL: https://issues.apache.org/jira/browse/THRIFT-5003
> Project: Thrift
>  Issue Type: Improvement
>  Components: Node.js - Library, TypeScript - Library
>Affects Versions: 0.13.0
> Environment: Webpack 4.41.2
> Thrift 0.13.0
> NodeJS thrift lib required in browser env
>Reporter: Eugen Kandakov
>Assignee: Eugen Kandakov
>Priority: Major
>  Labels: Browser, JavaScript, WebSocket, webpack
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> After some changes to the ws_connection.js file in the nodejs code, I could 
> create a version of the WSConnection, createWSConnection and createWSClient 
> which is able to run similar code of WebSocket connections in the browser and 
> NodeJS
> Solution is package, `{{isomorphic-ws` which provides the proper Websocket 
> libs depending on the env (browser or node)}}
>  
> Testable Repo with thrift branch from PR: 
> [https://github.com/alabama/thrift-testing]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5049) Process panic in generated processor

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5049:
-
Issue Type: Wish  (was: Improvement)

> Process panic in generated processor
> 
>
> Key: THRIFT-5049
> URL: https://issues.apache.org/jira/browse/THRIFT-5049
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Serhii
>Priority: Major
>
> Hello. In current version go generator doesn't provide functionality to 
> handle panic in generated processor. You can pass defer function which will 
> write TApplicationException to output protocol there 
> https://github.com/apache/thrift/blob/0.13.0/compiler/cpp/src/thrift/generate/t_go_generator.cc#L2787.
>  
> In current version on processor we need to process panic in custom server to 
> send NewTApplicationException to clients and it is very uncomfortable.
> Thanks.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5049) Process panic in generated processor

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008676#comment-17008676
 ] 

Duru Can Celasun commented on THRIFT-5049:
--

The library - correctly - doesn't handle panics caused by the user's code. If 
there are panics _in the library_ though, please point them out and we'll fix 
them.

> Process panic in generated processor
> 
>
> Key: THRIFT-5049
> URL: https://issues.apache.org/jira/browse/THRIFT-5049
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Serhii
>Priority: Major
>
> Hello. In current version go generator doesn't provide functionality to 
> handle panic in generated processor. You can pass defer function which will 
> write TApplicationException to output protocol there 
> https://github.com/apache/thrift/blob/0.13.0/compiler/cpp/src/thrift/generate/t_go_generator.cc#L2787.
>  
> In current version on processor we need to process panic in custom server to 
> send NewTApplicationException to clients and it is very uncomfortable.
> Thanks.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5049) Process panic in generated processor

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5049:
-
Priority: Minor  (was: Major)

> Process panic in generated processor
> 
>
> Key: THRIFT-5049
> URL: https://issues.apache.org/jira/browse/THRIFT-5049
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Serhii
>Priority: Minor
>
> Hello. In current version go generator doesn't provide functionality to 
> handle panic in generated processor. You can pass defer function which will 
> write TApplicationException to output protocol there 
> https://github.com/apache/thrift/blob/0.13.0/compiler/cpp/src/thrift/generate/t_go_generator.cc#L2787.
>  
> In current version on processor we need to process panic in custom server to 
> send NewTApplicationException to clients and it is very uncomfortable.
> Thanks.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5039) thrift npm package should be published from root folder

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16998999#comment-16998999
 ] 

Duru Can Celasun commented on THRIFT-5039:
--

cc [~jking]

> thrift npm package should be published from root folder
> ---
>
> Key: THRIFT-5039
> URL: https://issues.apache.org/jira/browse/THRIFT-5039
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Library
>Affects Versions: 0.13.0
>Reporter: Soner Okur
>Priority: Major
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Thrift npm package was published from js folder. Therefore, we can't build 
> our software because lack of nodejs library. Can you re-publish the package ?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-4995) [Rust] Use `ToSocketAddrs` for expressing network addresses

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-4995.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> [Rust] Use `ToSocketAddrs` for expressing network addresses
> ---
>
> Key: THRIFT-4995
> URL: https://issues.apache.org/jira/browse/THRIFT-4995
> Project: Thrift
>  Issue Type: Improvement
>  Components: Rust - Library
>Reporter: Marcin Pajkowski
>Priority: Minor
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Right now addresses must be a  and must match format host:port. However, 
> there are no obstacles for using types bound by ToSocketAddrs trait.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5046) Custom tags remove db and json tags

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5046.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Custom tags remove db and json tags
> ---
>
> Key: THRIFT-5046
> URL: https://issues.apache.org/jira/browse/THRIFT-5046
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>    Reporter: Duru Can Celasun
>    Assignee: Duru Can Celasun
>Priority: Minor
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Given the IDL:
> {code}
> struct Example {
>   1: bool withTag (go.tag = "foo:\"bar\"")
>   2: bool withoutTag
> }
> {code}
> The generated code looks like:
> {code}
> type Example struct {
>   WithTag bool `thrift:"withTag,1", foo:"bar"`
>   WithoutTag bool `thrift:"withoutTag,2" db:"withoutTag" json:"withoutTag"`
> }
> {code}
> The bug is on [this 
> line|https://github.com/apache/thrift/blob/6e023df1ded255dda00eb4c041c201e66c8d1fbc/compiler/cpp/src/thrift/generate/t_go_generator.cc#L1396]
>  of the Go generator where any custom tag overwrites the existing db and json 
> tags.
> Custom tags that aren't overrides should be appended instead of replacing the 
> whole thing.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)