Skip to content

Commit 452b05d

Browse files
viktorklangviktorklang
committedOct 2, 2017
Initial seed commit from reactive-streams-jvm repo
1 parent 9e040a7 commit 452b05d

File tree

6 files changed

+680
-2
lines changed

6 files changed

+680
-2
lines changed
 

‎CONTRIBUTING.md

+70
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
# Contributing to the Reactive Streams Project
2+
3+
The Reactive Streams project welcomes contributions from anybody who wants to participate in moving this initiative forward. All code or documentation that is contributed will have to be covered by a waiver of all copyrights and other rights as detailed by the LICENSE and COPYING files at each repository root, the rationale for this is that the APIs defined by this project shall be freely implementable and usable by everyone.
4+
5+
## Copyright Statement
6+
7+
The aforementioned waiver of copyrights and other rights is represented by the addition of a line to the file [CopyrightWaivers.txt](https://github.com/reactive-streams/reactive-streams-jvm/blob/master/CopyrightWaivers.txt). For a pull request to be considered every contributor must have signed the copyright statement in this way; this may be included within that same pull request.
8+
9+
## Gatekeepers
10+
11+
To ensure consistent development of Reactive Streams towards their goal, a group of gatekeepers is defined:
12+
13+
* Example Inc., currently represented by John Doe (@GITHUBHANDLE_JOHNDOE)
14+
15+
The role of this group is detailed in the following, additions to this list are made by pull request as defined below, removals require the consent of the entity to be removed or unanimous consent of all other Gatekeepers. Changing a representative of one of the gatekeeper entities can be done by a member of that entity without requiring consent from the other Gatekeepers.
16+
17+
Gatekeepers commit to the following:
18+
19+
1. 1-week SLA on :+1: or :-1: Pull Requests
20+
* If a Gatekeeper will be unavailable for a period of time, notify @reactive-streams/contributors and appoint who will vote in his/her place in the mean time
21+
2. tag @reactive-streams/contributors with a deadline when there needs to be a vote on an Issue,
22+
with at least 1 week of notice (see rule 1 above)
23+
24+
## General Workflow
25+
26+
1. Make sure you have signed the Copyright Statement, see above.
27+
2. Before starting to work on a change, make sure that:
28+
1. There is a ticket for your work in the project's issue tracker. If not, create it first. It can help accelerating the pull request acceptance process if the change is agreed upon beforehand within the ticket, but in some cases it may be preferable to discuss the necessity of the change in consideration of a concrete proposal.
29+
2. The ticket has been scheduled for the current milestone.
30+
3. You should always perform your work in a Git feature branch within your own fork of the repository your are targeting (even if you should have push rights to the target repository).
31+
4. When the change is completed you should open a [Pull Request](https://help.github.com/articles/using-pull-requests) on GitHub.
32+
5. Anyone can comment on the pull request while it is open, and you are expected to answer questions or incorporate feedback.
33+
6. Once at least two thirds of the gatekeepers have signaled their consent, the pull request is merged by one of the gatekeepers into the branch and repository it is targeting. Consent is signaled by commenting on the pull request with the text “LGTM”, and it suffices for one representative of a gatekeeper to signal consent for that gatekeeper to be counted towards the two thirds quorum.
34+
7. It is not allowed to force-push to the branch on which the pull request is based. Replacing or adding to the commits on that branch will invalidate all previous consenting comments and consent needs to be re-established.
35+
8. Before merging a branch that contains multiple commits, it is recommended that these are squashed into a single commit before performing the merge. To aid in verification that no new changes are introduced, a new pull request should be opened in this case, targeting the same branch and repository and containing just one commit which encompasses the full change set of the original pull request.
36+
37+
## Pull Request Requirements
38+
39+
For a Pull Request to be considered at all it has to meet these requirements:
40+
41+
1. If applicable, the new or fixed features must be accompanied by comprehensive tests.
42+
2. If applicable, the pull request must contain all necessary documentation updates required by the changes introduced.
43+
3. The pull request must not contain changes that are unrelated to the ticket that it corresponds to. One pull request is meant to introduce only one logically contiguous change.
44+
45+
## Creating Commits And Writing Commit Messages
46+
47+
Follow these guidelines when creating public commits and writing commit messages.
48+
49+
1. If your work spans multiple local commits (for example; if you do safe point commits while working in a feature branch or work in a branch for long time doing merges/rebases etc.) then please do not commit it all but rewrite the history by squashing the commits into a single big commit which you write a good commit message for (like discussed in the following sections). For more info read this article: [Git Workflow](http://sandofsky.com/blog/git-workflow.html). Every commit should be able to be used in isolation, cherry picked etc.
50+
51+
2. First line should be a descriptive sentence what the commit is doing. It should be possible to fully understand what the commit does—but not necessarily how it does it—by just reading this single line. We follow the “imperative present tense” style for commit messages ([more info here](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)).
52+
53+
It is **not ok** to only list the ticket number, type "minor fix" or similar. In order to help with automatic filtering of the commit history (generating ChangeLogs, writing the migration guide, code archaeology) we use the following encoding:
54+
55+
3. Following the single line description should be a blank line followed by an enumerated list with the details of the commit. For very simple commits this may be empty.
56+
57+
4. Add keywords for your commit:
58+
* ``Review by @gituser`` - if you want to notify someone specifically for review; this has no influence on the acceptance process described above
59+
60+
Example:
61+
62+
add CONTRIBUTING.md
63+
64+
* clarify how pull requests should look like
65+
* describe the acceptance process
66+
* define the Copyright Statement signing process
67+
68+
## Performing Official Releases
69+
70+
Creating binary artifacts, uploading them to central repositories and declaring these to be an official release of the Reactive Streams project requires the consent of all gatekeepers. The process is initiated by creating a ticket in the `reactive-streams` repository for this purpose and consent is signaled in the same way as for pull requests. The actual work of updating version numbers and publishing the artifacts will typically involve pull requests targeting the affected repositories.

‎COPYING

+121
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,121 @@
1+
Creative Commons Legal Code
2+
3+
CC0 1.0 Universal
4+
5+
CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
6+
LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
7+
ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
8+
INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
9+
REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
10+
PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
11+
THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
12+
HEREUNDER.
13+
14+
Statement of Purpose
15+
16+
The laws of most jurisdictions throughout the world automatically confer
17+
exclusive Copyright and Related Rights (defined below) upon the creator
18+
and subsequent owner(s) (each and all, an "owner") of an original work of
19+
authorship and/or a database (each, a "Work").
20+
21+
Certain owners wish to permanently relinquish those rights to a Work for
22+
the purpose of contributing to a commons of creative, cultural and
23+
scientific works ("Commons") that the public can reliably and without fear
24+
of later claims of infringement build upon, modify, incorporate in other
25+
works, reuse and redistribute as freely as possible in any form whatsoever
26+
and for any purposes, including without limitation commercial purposes.
27+
These owners may contribute to the Commons to promote the ideal of a free
28+
culture and the further production of creative, cultural and scientific
29+
works, or to gain reputation or greater distribution for their Work in
30+
part through the use and efforts of others.
31+
32+
For these and/or other purposes and motivations, and without any
33+
expectation of additional consideration or compensation, the person
34+
associating CC0 with a Work (the "Affirmer"), to the extent that he or she
35+
is an owner of Copyright and Related Rights in the Work, voluntarily
36+
elects to apply CC0 to the Work and publicly distribute the Work under its
37+
terms, with knowledge of his or her Copyright and Related Rights in the
38+
Work and the meaning and intended legal effect of CC0 on those rights.
39+
40+
1. Copyright and Related Rights. A Work made available under CC0 may be
41+
protected by copyright and related or neighboring rights ("Copyright and
42+
Related Rights"). Copyright and Related Rights include, but are not
43+
limited to, the following:
44+
45+
i. the right to reproduce, adapt, distribute, perform, display,
46+
communicate, and translate a Work;
47+
ii. moral rights retained by the original author(s) and/or performer(s);
48+
iii. publicity and privacy rights pertaining to a person's image or
49+
likeness depicted in a Work;
50+
iv. rights protecting against unfair competition in regards to a Work,
51+
subject to the limitations in paragraph 4(a), below;
52+
v. rights protecting the extraction, dissemination, use and reuse of data
53+
in a Work;
54+
vi. database rights (such as those arising under Directive 96/9/EC of the
55+
European Parliament and of the Council of 11 March 1996 on the legal
56+
protection of databases, and under any national implementation
57+
thereof, including any amended or successor version of such
58+
directive); and
59+
vii. other similar, equivalent or corresponding rights throughout the
60+
world based on applicable law or treaty, and any national
61+
implementations thereof.
62+
63+
2. Waiver. To the greatest extent permitted by, but not in contravention
64+
of, applicable law, Affirmer hereby overtly, fully, permanently,
65+
irrevocably and unconditionally waives, abandons, and surrenders all of
66+
Affirmer's Copyright and Related Rights and associated claims and causes
67+
of action, whether now known or unknown (including existing as well as
68+
future claims and causes of action), in the Work (i) in all territories
69+
worldwide, (ii) for the maximum duration provided by applicable law or
70+
treaty (including future time extensions), (iii) in any current or future
71+
medium and for any number of copies, and (iv) for any purpose whatsoever,
72+
including without limitation commercial, advertising or promotional
73+
purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
74+
member of the public at large and to the detriment of Affirmer's heirs and
75+
successors, fully intending that such Waiver shall not be subject to
76+
revocation, rescission, cancellation, termination, or any other legal or
77+
equitable action to disrupt the quiet enjoyment of the Work by the public
78+
as contemplated by Affirmer's express Statement of Purpose.
79+
80+
3. Public License Fallback. Should any part of the Waiver for any reason
81+
be judged legally invalid or ineffective under applicable law, then the
82+
Waiver shall be preserved to the maximum extent permitted taking into
83+
account Affirmer's express Statement of Purpose. In addition, to the
84+
extent the Waiver is so judged Affirmer hereby grants to each affected
85+
person a royalty-free, non transferable, non sublicensable, non exclusive,
86+
irrevocable and unconditional license to exercise Affirmer's Copyright and
87+
Related Rights in the Work (i) in all territories worldwide, (ii) for the
88+
maximum duration provided by applicable law or treaty (including future
89+
time extensions), (iii) in any current or future medium and for any number
90+
of copies, and (iv) for any purpose whatsoever, including without
91+
limitation commercial, advertising or promotional purposes (the
92+
"License"). The License shall be deemed effective as of the date CC0 was
93+
applied by Affirmer to the Work. Should any part of the License for any
94+
reason be judged legally invalid or ineffective under applicable law, such
95+
partial invalidity or ineffectiveness shall not invalidate the remainder
96+
of the License, and in such case Affirmer hereby affirms that he or she
97+
will not (i) exercise any of his or her remaining Copyright and Related
98+
Rights in the Work or (ii) assert any associated claims and causes of
99+
action with respect to the Work, in either case contrary to Affirmer's
100+
express Statement of Purpose.
101+
102+
4. Limitations and Disclaimers.
103+
104+
a. No trademark or patent rights held by Affirmer are waived, abandoned,
105+
surrendered, licensed or otherwise affected by this document.
106+
b. Affirmer offers the Work as-is and makes no representations or
107+
warranties of any kind concerning the Work, express, implied,
108+
statutory or otherwise, including without limitation warranties of
109+
title, merchantability, fitness for a particular purpose, non
110+
infringement, or the absence of latent or other defects, accuracy, or
111+
the present or absence of errors, whether or not discoverable, all to
112+
the greatest extent permissible under applicable law.
113+
c. Affirmer disclaims responsibility for clearing rights of other persons
114+
that may apply to the Work or any use thereof, including without
115+
limitation any person's Copyright and Related Rights in the Work.
116+
Further, Affirmer disclaims responsibility for obtaining any necessary
117+
consents, permissions or other rights required for any use of the
118+
Work.
119+
d. Affirmer understands and acknowledges that Creative Commons is not a
120+
party to this document and has no duty or obligation with respect to
121+
this CC0 or use of the Work.

‎CopyrightWaivers.txt

+20
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
Copyright Statement for Contributions to the Reactive Streams Project
2+
=====================================================================
3+
4+
I hereby represent that all present, past and future contributions I make to
5+
the Reactive Streams project (which includes all repositories owned by the
6+
“reactive-streams” github organization) are governed by the Creative Commons
7+
Zero 1.0 Universal copyright statement, placing my contributions in the public
8+
domain. This entails that to the extent possible under law I waive all
9+
copyright and related or neighboring rights to the code or documents I
10+
contribute. I also represent that I have the authority to perform the above
11+
waiver with respect to the entirety of my contributions.
12+
13+
The text of the copyright statement is included in the COPYING file at the root
14+
of the reactive-streams repository at
15+
https://github.com/reactive-streams/reactive-streams-jvm/blob/master/COPYING.
16+
17+
Underwriting parties:
18+
19+
github name | Real Name, Email Address used for git commits, Company
20+
---------------+----------------------------------------------------------------------------

‎LICENSE

+8
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
Licensed under Public Domain (CC0)
2+
3+
To the extent possible under law, the person who associated CC0 with
4+
this code has waived all copyright and related or neighboring
5+
rights to this code.
6+
7+
You should have received a copy of the CC0 legalcode along with this
8+
work. If not, see <http://creativecommons.org/publicdomain/zero/1.0/>.

‎README.md

+283-2
Large diffs are not rendered by default.

‎RELEASE-NOTES.md

+178
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,178 @@
1+
# Release notes for Reactive Streams
2+
3+
---
4+
5+
# Version 1.0.1 released on 2017-08-09
6+
7+
## Announcement:
8+
9+
After more than two years since 1.0.0, we are proud to announce the immediate availability of `Reactive Streams version 1.0.1`.
10+
11+
Since 1.0.0 was released `Reactive Streams` has managed to achieve most, if not all, it set out to achieve. There are now numerous implementations, and it is scheduled to be included in [JDK9](http://download.java.net/java/jdk9/docs/api/java/util/concurrent/Flow.html).
12+
13+
Also, most importantly, there are no semantical incompatibilities included in this release.
14+
15+
When JDK9 ships, `Reactive Streams` will publish a compatibility/conversion library to seamlessly convert between the `java.util.concurrent.Flow` and the `org.reactivestreams` namespaces.
16+
17+
## Highlights:
18+
19+
- Specification
20+
+ A new [Glossary](https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.1/README.md#glossary) section
21+
+ Description of the intent behind every single rule
22+
+ No breaking semantical changes
23+
+ Multiple rule [clarifications](#specification-clarifications)
24+
- Interfaces
25+
+ No changes
26+
+ Improved JavaDoc
27+
- Technology Compatibility Kit (TCK)
28+
+ Improved coverage
29+
+ Improved JavaDoc
30+
+ Multiple test [alterations](#tck-alterations)
31+
32+
## Specification clarifications
33+
34+
## Publisher Rule 1
35+
36+
**1.0.0:** The total number of onNext signals sent by a Publisher to a Subscriber MUST be less than or equal to the total number of elements requested by that Subscriber´s Subscription at all times.
37+
38+
**1.0.1:** The total number of onNext´s signalled by a Publisher to a Subscriber MUST be less than or equal to the total number of elements requested by that Subscriber´s Subscription at all times.
39+
40+
**Comment: Minor spelling update.**
41+
42+
## Publisher Rule 2
43+
44+
**1.0.0:** A Publisher MAY signal less onNext than requested and terminate the Subscription by calling onComplete or onError.
45+
46+
**1.0.1:** A Publisher MAY signal fewer onNext than requested and terminate the Subscription by calling onComplete or onError.
47+
48+
**Comment: Minor spelling update.**
49+
50+
## Publisher Rule 3
51+
52+
**1.0.0:** onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled sequentially (no concurrent notifications).
53+
54+
**1.0.1:** onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled in a thread-safe manner—and if performed by multiple threads—use external synchronization.
55+
56+
**Comment: Reworded the part about sequential signal and its implications, for clarity.**
57+
58+
## Subscriber Rule 6
59+
60+
**1.0.0:** A Subscriber MUST call Subscription.cancel() if it is no longer valid to the Publisher without the Publisher having signaled onError or onComplete.
61+
62+
**1.0.1:** A Subscriber MUST call Subscription.cancel() if the Subscription is no longer needed.
63+
64+
**Comment: Rule could be reworded since it now has an intent section describing desired effect.**
65+
66+
## Subscriber Rule 11
67+
68+
**1.0.0:** A Subscriber MUST make sure that all calls on its onXXX methods happen-before [1] the processing of the respective signals. I.e. the Subscriber must take care of properly publishing the signal to its processing logic.
69+
70+
**1.0.1:** A Subscriber MUST make sure that all calls on its signal methods happen-before the processing of the respective signals. I.e. the Subscriber must take care of properly publishing the signal to its processing logic.
71+
72+
**Comment: Rule slightly reworded to use the glossary for `signal` instead of the more *ad-hoc* name "onXXX methods". Footnote was reworked into the Intent-section of the rule.**
73+
74+
## Subscription Rule 1
75+
76+
**1.0.0:** Subscription.request and Subscription.cancel MUST only be called inside of its Subscriber context. A Subscription represents the unique relationship between a Subscriber and a Publisher [see 2.12].
77+
78+
**1.0.1:** Subscription.request and Subscription.cancel MUST only be called inside of its Subscriber context.
79+
80+
**Comment: Second part of rule moved into the Intent-section of the rule.**
81+
82+
## Subscription Rule 3
83+
84+
**1.0.0:** Subscription.request MUST place an upper bound on possible synchronous recursion between Publisher and Subscriber[1].
85+
86+
**1.0.1:** Subscription.request MUST place an upper bound on possible synchronous recursion between Publisher and Subscriber.
87+
88+
**Comment: Footnote reworked into the Intent-section of the rule.**
89+
90+
## Subscription Rule 4
91+
92+
**1.0.0:** Subscription.request SHOULD respect the responsivity of its caller by returning in a timely manner[2].
93+
94+
**1.0.1:** Subscription.request SHOULD respect the responsivity of its caller by returning in a timely manner.
95+
96+
**Comment: Footnote reworked into the Intent-section of the rule.**
97+
98+
## Subscription Rule 5
99+
100+
**1.0.0:** Subscription.cancel MUST respect the responsivity of its caller by returning in a timely manner[2], MUST be idempotent and MUST be thread-safe.
101+
102+
**1.0.1:** Subscription.cancel MUST respect the responsivity of its caller by returning in a timely manner, MUST be idempotent and MUST be thread-safe.
103+
104+
**Comment: Footnote reworked into the Intent-section of the rule.**
105+
106+
## Subscription Rule 9
107+
108+
**1.0.0:** While the Subscription is not cancelled, Subscription.request(long n) MUST signal onError with a java.lang.IllegalArgumentException if the argument is <= 0. The cause message MUST include a reference to this rule and/or quote the full rule.
109+
110+
**1.0.1:** While the Subscription is not cancelled, Subscription.request(long n) MUST signal onError with a java.lang.IllegalArgumentException if the argument is <= 0. The cause message SHOULD explain that non-positive request signals are illegal.
111+
112+
**Comment: The MUST requirement to include a reference to the rule in the exception message has been dropped, in favor of that the exception message SHOULD explain that non-positive requests are illegal.**
113+
114+
## Subscription Rule 13
115+
116+
**1.0.0:** While the Subscription is not cancelled, Subscription.cancel() MUST request the Publisher to eventually drop any references to the corresponding subscriber. Re-subscribing with the same Subscriber object is discouraged [see 2.12], but this specification does not mandate that it is disallowed since that would mean having to store previously cancelled subscriptions indefinitely.
117+
118+
**1.0.1:** While the Subscription is not cancelled, Subscription.cancel() MUST request the Publisher to eventually drop any references to the corresponding subscriber.
119+
120+
**Comment: Second part of rule reworked into the Intent-section of the rule.**
121+
122+
## Subscription Rule 15
123+
124+
**1.0.0:** Calling Subscription.cancel MUST return normally. The only legal way to signal failure to a Subscriber is via the onError method.
125+
126+
**1.0.1:** Calling Subscription.cancel MUST return normally.
127+
128+
**Comment: Replaced second part of rule with a definition for `return normally` in the glossary.**
129+
130+
## Subscription Rule 16
131+
132+
**1.0.0:** Calling Subscription.request MUST return normally. The only legal way to signal failure to a Subscriber is via the onError method.
133+
134+
**1.0.1:** Calling Subscription.request MUST return normally.
135+
136+
**Comment: Replaced second part of rule with a definition for `return normally` in the glossary.**
137+
138+
## Subscription Rule 17
139+
140+
**1.0.0:** A Subscription MUST support an unbounded number of calls to request and MUST support a demand (sum requested - sum delivered) up to 2^63-1 (java.lang.Long.MAX_VALUE). A demand equal or greater than 2^63-1 (java.lang.Long.MAX_VALUE) MAY be considered by the Publisher as “effectively unbounded”[3].
141+
142+
**1.0.1:** A Subscription MUST support an unbounded number of calls to request and MUST support a demand up to 2^63-1 (java.lang.Long.MAX_VALUE). A demand equal or greater than 2^63-1 (java.lang.Long.MAX_VALUE) MAY be considered by the Publisher as “effectively unbounded”.
143+
144+
**Comment: Rule simplified by defining `demand` in the glossary, and footnote was reworked into the Intent-section of the rule.**
145+
146+
---
147+
148+
## TCK alterations
149+
150+
- Fixed potential resource leaks in partially consuming Publisher tests ([#375](https://github.com/reactive-streams/reactive-streams-jvm/issues/375))
151+
- Fixed potential resource leaks in partially emitting Subscriber tests ([#372](https://github.com/reactive-streams/reactive-streams-jvm/issues/372), [#373](https://github.com/reactive-streams/reactive-streams-jvm/issues/373))
152+
- Renamed `untested_spec305_cancelMustNotSynchronouslyPerformHeavyCompuatation` to `untested_spec305_cancelMustNotSynchronouslyPerformHeavyComputation` ([#306](https://github.com/reactive-streams/reactive-streams-jvm/issues/306))
153+
- Allow configuring separate timeout for "no events during N time", allowing for more aggressive timeouts in the rest of the test suite if required ([#314](https://github.com/reactive-streams/reactive-streams-jvm/issues/314))
154+
- New test verifying Rule 2.10, in which subscriber must be prepared to receive onError signal without having signaled request before ([#374](https://github.com/reactive-streams/reactive-streams-jvm/issues/374))
155+
- The verification of Rule 3.9 has been split up into 2 different tests, one to verify that an IllegalArgumentException is sent, and the other an optional check to verify that the exception message informs that non-positive request signals are illegal.
156+
---
157+
158+
## Contributors
159+
+ Roland Kuhn [(@rkuhn)](https://github.com/rkuhn)
160+
+ Ben Christensen [(@benjchristensen)](https://github.com/benjchristensen)
161+
+ Viktor Klang [(@viktorklang)](https://github.com/viktorklang)
162+
+ Stephane Maldini [(@smaldini)](https://github.com/smaldini)
163+
+ Stanislav Savulchik [(@savulchik)](https://github.com/savulchik)
164+
+ Konrad Malawski [(@ktoso)](https://github.com/ktoso)
165+
+ Slim Ouertani [(@ouertani)](https://github.com/ouertani)
166+
+ Martynas Mickevičius [(@2m)](https://github.com/2m)
167+
+ Luke Daley [(@ldaley)](https://github.com/ldaley)
168+
+ Colin Godsey [(@colinrgodsey)](https://github.com/colinrgodsey)
169+
+ David Moten [(@davidmoten)](https://github.com/davidmoten)
170+
+ (new) Brian Topping [(@briantopping)](https://github.com/briantopping)
171+
+ (new) Rossen Stoyanchev [(@rstoyanchev)](https://github.com/rstoyanchev)
172+
+ (new) Björn Hamels [(@BjornHamels)](https://github.com/BjornHamels)
173+
+ (new) Jake Wharton [(@JakeWharton)](https://github.com/JakeWharton)
174+
+ (new) Anthony Vanelverdinghe[(@anthonyvdotbe)](https://github.com/anthonyvdotbe)
175+
+ (new) Kazuhiro Sera [(@seratch)](https://github.com/seratch)
176+
+ (new) Dávid Karnok [(@akarnokd)](https://github.com/akarnokd)
177+
+ (new) Evgeniy Getman [(@egetman)](https://github.com/egetman)
178+
+ (new) Ángel Sanz [(@angelsanz)](https://github.com/angelsanz)

0 commit comments

Comments
 (0)
Please sign in to comment.