submitting D and JavaScript enhancements

[James Lacey <ja...@gmail.com>]

I am working on a project where I need to run Thrift over WebSockets
between a server running on the local host and a client running in the
browser. In the course of the project, I developed some enhancements to the
current library. Besides simple bug fixes, I have never contributed to an
open source project before. I read the basic information on the website
about contributing, but I wanted to email this list before opening any
items in JIRA.

For my project, I wrote a server-side WebSocket transport for the D library
and fixed several compilation errors and warnings on Windows. I also made a
fix for a runtime ReferenceError in the JavaScript code generated by the
Thrift compiler. At the beginning of the project, I was evaluating both
Vala and D for the server portion. I added a Vala code generator to the
Thrift project and VAPI file generation to the c_glib build. The Vala work
isn't complete, but I was planning on finishing it up and possibly
submitting that as well.

I guess my first question is whether any of this work is of interest to the
wider community. If it is, how many pull requests should I submit? The D
and JavaScript work would be separate, but I was unsure whether I should
separate the D compilation fixes into a separate item. If I complete the
Vala work, would that be one PR or multiple?

Thanks,
James

Re: submitting D and JavaScript enhancements

[Jens Geyer <je...@hotmail.com>]

Hi,

> Besides simple bug fixes, I have never contributed to an
> open source project before. [...] I guess my first question
> is whether any of this work is of interest to the wider
> community. If it is, how many pull requests should I submit?

What's not mentioned explicitly so much but everybody contributing should be 
aware of is that you need not only to be technically able, but also legally 
allowed to contribute the code. If you write code as an employee that might 
not necessarily be the case in certain countries, because the code is 
usually owned by the company you work for.

Once that is clear ...

In general, try to split PRs by language, which in most cases is easily 
doable.

Next, unless you have some really big feature like adding a new language to 
the project, try to keep each PR at a level where someone can realistically 
do a review on it. The exact granularity may vary, it makes usually sense to 
have a PR cover a specific problem completely, have a ticket for it (unless 
it is a real nobrainer) where there is a suitable description and maybe a 
test case that can be used to verify the solution. Getting too many minorish 
PRs to review is bad, but getting one big lump of code across 85 files 
and/or spanning three languages, labelled only "misc. bug fixes" or the like 
is not really good either.

A good rule of thumb is this: Assumed, the PR is squashed into one commit 
and let's pretend you do not know the patch (someone else wrote it), what 
would be your answer when asked to review it yourself?

For cases where a large feature is to be added, like adding Vala as a new 
language, it would be super awesome if there is at least one person out 
there that has enough knowledge and expertise using that language who can 
take over a reviewer part. Getting early feedback on especially larger 
features is almost always a valuable idea that contributes to the quality of 
the work. And it also can help answer the question whether a particular 
patch is of interest to the community, but you will get some feedback on 
that as well once you sent the PR. Speaking of that, even receiving 
rejection and finally closing a PR unmerged is something that just happens 
in real life sometimes, so don't worry about that too much.

BTW there is also a document on the web site giving a brief outline on what 
should be the minimum when adding new language bindings. Also, in that 
regard I might add that we currently have two build systems, an older one 
based on autotools and the other, newer one, based on Cmake.

Have fun,
JensG




-----Ursprüngliche Nachricht----- 
From: James Lacey
Sent: Sunday, March 22, 2020 10:07 PM
To: dev@thrift.apache.org
Subject: submitting D and JavaScript enhancements

I am working on a project where I need to run Thrift over WebSockets
between a server running on the local host and a client running in the
browser. In the course of the project, I developed some enhancements to the
current library. Besides simple bug fixes, I have never contributed to an
open source project before. I read the basic information on the website
about contributing, but I wanted to email this list before opening any
items in JIRA.

For my project, I wrote a server-side WebSocket transport for the D library
and fixed several compilation errors and warnings on Windows. I also made a
fix for a runtime ReferenceError in the JavaScript code generated by the
Thrift compiler. At the beginning of the project, I was evaluating both
Vala and D for the server portion. I added a Vala code generator to the
Thrift project and VAPI file generation to the c_glib build. The Vala work
isn't complete, but I was planning on finishing it up and possibly
submitting that as well.

I guess my first question is whether any of this work is of interest to the
wider community. If it is, how many pull requests should I submit? The D
and JavaScript work would be separate, but I was unsure whether I should
separate the D compilation fixes into a separate item. If I complete the
Vala work, would that be one PR or multiple?

Thanks,
James