+1 for slight addition from Max.
Travis exist for helping to run all tests not in your local dev.
On Friday, February 19, 2016, Fabian Hueske wrote:
> Max, you're right.
> Not necessarily a local build, but a least "some" build to verify that the
> code compiles and most tests pass.
> I said lo
Max, you're right.
Not necessarily a local build, but a least "some" build to verify that the
code compiles and most tests pass.
I said local builds because this is the easiest way to check for somebody
not familiar with our setup.
I think it is a good idea to explicitly state the command to run:
+1 for the documentation check box.
Are we requiring local builds? Travis builds are fine, right? So what
about "Builds locally or on Travis"?
Could we add more subpoints from the How to Contribute guide?
[X] General
- JIRA issue associated
- Single PR per change
- Meaningful commit messag
Thanks Martin!
can you add two more fields?
- Builds locally (mvn clean verify)
- Documentation updated or not updates necessary
Best, Fabian
2016-02-19 9:35 GMT+01:00 Martin Liesenberg :
> Cool, if no one objects, I'll create a JIRA ticket and open a corresponding
> PR during the weekend.
>
>
Cool, if no one objects, I'll create a JIRA ticket and open a corresponding
PR during the weekend.
Best regards
Martin
On Thu, 18 Feb 2016, 17:36 Maximilian Michels wrote:
> Hi Martin,
>
> Sounds like a good idea to me to create a checklist like this. It
> would be a nice reminder for people wh
Hi Martin,
Sounds like a good idea to me to create a checklist like this. It
would be a nice reminder for people who didn't read the
how-to-contribute section of the README :)
Cheers,
Max
On Thu, Feb 18, 2016 at 9:31 AM, Martin Liesenberg
wrote:
> Hi,
>
> GitHub just introduced a way to supply
Hi,
GitHub just introduced a way to supply PR templates. [1]
To support the changes discussed here, we could add a simple template with
check boxes like:
[ ] did you add tests
[ ] did you check against the coding guidelines
[ ] is there a jira supporting the PR
Let me know what you think. The la
Thanks for leading the effort Fabian!
On Fri, Oct 9, 2015 at 10:07 AM, Maximilian Michels wrote:
> Very nice work, Fabian. I think we'll have to send around a reminder
> from time to time and, perhaps, evaluate the new guidelines after some
> period of time. It's great to have these documents no
Very nice work, Fabian. I think we'll have to send around a reminder
from time to time and, perhaps, evaluate the new guidelines after some
period of time. It's great to have these documents now as a reference.
On Thu, Oct 8, 2015 at 5:36 PM, Stephan Ewen wrote:
> Great, thanks Fabian!
>
> On Thu
Great, thanks Fabian!
On Thu, Oct 8, 2015 at 5:28 PM, Henry Saputra
wrote:
> Thanks again for leading this effort, Fabian
>
> - Henry
>
> On Thursday, October 8, 2015, Fabian Hueske wrote:
>
> > Hi everybody,
> >
> > I merged our new contribution guidelines a few minutes ago.
> >
> > I'd like t
Thanks again for leading this effort, Fabian
- Henry
On Thursday, October 8, 2015, Fabian Hueske wrote:
> Hi everybody,
>
> I merged our new contribution guidelines a few minutes ago.
>
> I'd like to emphasize that these rules do not have any effect, if nobody
> follows them.
> So please follow
+1
Great!
On 10/08/2015 01:14 PM, Fabian Hueske wrote:
> Hi everybody,
>
> I merged our new contribution guidelines a few minutes ago.
>
> I'd like to emphasize that these rules do not have any effect, if nobody
> follows them.
> So please follow our contribution rules and make others aware of
Hi everybody,
I merged our new contribution guidelines a few minutes ago.
I'd like to emphasize that these rules do not have any effect, if nobody
follows them.
So please follow our contribution rules and make others aware of them as
well.
Specifically
- pay attention that all PRs are backed by
Thanks for the feedback everybody.
I updated the PR and would like to merge it later today if there are no
more comments.
Cheers, Fabian
2015-10-05 14:09 GMT+02:00 Fabian Hueske :
> Hi,
>
> I opened a PR with the discussed changes [1].
> Please review, give feedback, and suggest changes.
>
> Ch
I would like to extend the coding guidelines to make new tests (or
extending existing once) for fixed bugs mandatory; ie, write a test that
fails before the fix, but passes after the fix.
Right now, the guideline dictates that **Tests for new features are
required** which is not broad enough, IMHO
Hi,
I opened a PR with the discussed changes [1].
Please review, give feedback, and suggest changes.
Cheers, Fabian
[1] https://github.com/apache/flink-web/pull/11
2015-09-28 18:02 GMT+02:00 Fabian Hueske :
> @Chiwan, sure. Will do that. Thanks for pointing it out :-)
>
> 2015-09-28 18:00 GMT
@Chiwan, sure. Will do that. Thanks for pointing it out :-)
2015-09-28 18:00 GMT+02:00 Chiwan Park :
> @Fabian, Could you cover FLINK-2712 in your pull request? I think that it
> would be better than split pull request.
>
> Regards,
> Chiwan Park
>
> > On Sep 28, 2015, at 4:51 PM, Fabian Hueske
@Fabian, Could you cover FLINK-2712 in your pull request? I think that it would
be better than split pull request.
Regards,
Chiwan Park
> On Sep 28, 2015, at 4:51 PM, Fabian Hueske wrote:
>
> Thanks everybody for the discussion.
> I'll prepare a pull request to update the "How to contribute" a
Thanks everybody for the discussion.
I'll prepare a pull request to update the "How to contribute" and "Coding
Guidelines".
Thanks,
Fabian
2015-09-26 9:06 GMT+02:00 Maximilian Michels :
> Hi Fabian,
>
> This is a very important topic. Thanks for starting the discussion.
>
> 1) JIRA discussion
>
Hi Fabian,
This is a very important topic. Thanks for starting the discussion.
1) JIRA discussion
Absolutely. No new feature should be introduced without a discussion.
Frankly, I see the problem that sometimes discussions only come up
when the pull request has been opened. However, this can be o
Thanks everybody for feedback and comments.
Regarding 1) and 2):
I like the idea of keeping the discussion of new features and improvements
in JIRA as Kostas proposed.
Our coding guidelines [1] already request a JIRA issue for each pull
request.
How about we highlight this requirement more promi
Thanks Fabian for starting the discussion.
+1 for overall approach.
About (1), expressing that consensus must be required for new feature in “How
to contribute” page is very nice. Some pull requests were sent without
consensus. The contributors had to rewrote their pull requests.
Agree with (2
Thanks again, Fabian for starting the discussions.
For (1) and (2) I think it is good idea and will help people to
understand and follow the author thought process.
Following up with Stephan's reply, some new features solutions could
be explained thoroughly in the PR descriptions but some requires
Thanks, Fabian for driving this!
I agree with your points.
Concerning Vasia's comment to not raise the bar too high:
That is true, the requirements should be reasonable. We can definitely tag
issues as "simple" which means they do not require a design document. That
should be more for new feature
Hi,
I agree with you Fabian. Clarifying these issues in the "How to Contribute"
guide will save lots of time both to reviewers and contributors. It is a
really disappointing situation when someone spends time implementing
something and their PR ends up being rejected because either the feature
was
Big +1.
For (1), a discussion in JIRA would also be an option IMO
For (2), let us come up with few examples on what constitutes a feature
that needs a design doc, and what should be in the doc (IMO
architecture/general approach, components touched, interfaces changed)
On Wed, Sep 23, 2015 at 2
Hi everybody,
I guess we all have noticed that the Flink community is quickly growing and
more and more contributions are coming in. Recently, a few contributions
proposed new features without being discussed on the mailing list. Some of
these contributions were not accepted in the end. In other c
27 matches
Mail list logo
