+1
This was much needed :)
2015.01.07. 18:10 ezt írta ("Max Michels" ):
> Nice.
>
>
> On Wed, Jan 7, 2015 at 5:51 PM, Ufuk Celebi wrote:
> > +1
> >
> > @Stephan: thanks! :-)
> >
> > On Wed, Jan 7, 2015 at 4:44 PM, Stephan Ewen wrote:
> >
> >> Hi all!
> >>
> >> Since the feedback was positive, I
Nice.
On Wed, Jan 7, 2015 at 5:51 PM, Ufuk Celebi wrote:
> +1
>
> @Stephan: thanks! :-)
>
> On Wed, Jan 7, 2015 at 4:44 PM, Stephan Ewen wrote:
>
>> Hi all!
>>
>> Since the feedback was positive, I added the guidelines to the wiki, with a
>> disclaimer that this is being refined.
>>
>>
>> https
+1
@Stephan: thanks! :-)
On Wed, Jan 7, 2015 at 4:44 PM, Stephan Ewen wrote:
> Hi all!
>
> Since the feedback was positive, I added the guidelines to the wiki, with a
> disclaimer that this is being refined.
>
>
> https://cwiki.apache.org/confluence/display/FLINK/Apache+Flink+development+guidel
Hi all!
Since the feedback was positive, I added the guidelines to the wiki, with a
disclaimer that this is being refined.
https://cwiki.apache.org/confluence/display/FLINK/Apache+Flink+development+guidelines
Stephan
On Wed, Jan 7, 2015 at 4:13 PM, Kostas Tzoumas wrote:
> +1
>
> Let's encour
+1
Let's encourage the use of component tags, I don't see the need for
enforcing it. For commits that affect one component, I expect people will
use it.
On Wed, Jan 7, 2015 at 3:40 PM, Fabian Hueske wrote:
> +1 for the guide and JIRA references.
>
> I'd keep the component tags optional though.
+1 for the guide and JIRA references.
I'd keep the component tags optional though.
As Max said, there is less space to display a meaning message if a commit
addresses several components. Separating changes into commits by components
sounds not very practical to me.
Also without a clear definition
I personally like the tags very much. I think the streaming component was
the first to introduce it and it stuck me as a very good idea.
+1 to stick with them
On Wed, Jan 7, 2015 at 3:03 PM, Márton Balassi
wrote:
> I prefer component declarations, the current best practice comes in handy
> when
I prefer component declarations, the current best practice comes in handy
when searching through commits. Answering a "when did key selection change
for streaming?" type question I just had to answer would have been a bit
more difficult without it - manageable though.
In case of streaming it does
I would only start a vote if somebody objects.
How about adding this rule to our website, to make it even more official. I
would like to establish a document that contains all the rules we agreed on.
Similarly to the coding guidelines (
http://flink.apache.org/coding_guidelines.html) we could esta
Should we put that to an official vote, or wait for people to comment and
(if nobody objects) consider it as agreed on through lazy consensus?
On Wed, Jan 7, 2015 at 2:34 PM, Márton Balassi
wrote:
> +1 for the guide, thanks for clarifying the issue
>
> On Wed, Jan 7, 2015 at 2:30 PM, Till Rohrma
+1
Perhaps declaring the component should be optional because it leaves
less space for the actual commit message. We should definitely add
this guide to the wiki.
On Wed, Jan 7, 2015 at 2:34 PM, Márton Balassi wrote:
> +1 for the guide, thanks for clarifying the issue
>
> On Wed, Jan 7, 2015 at
+1 for the guide, thanks for clarifying the issue
On Wed, Jan 7, 2015 at 2:30 PM, Till Rohrmann wrote:
> +1
>
> On Wed, Jan 7, 2015 at 12:41 PM, Aljoscha Krettek
> wrote:
>
> > Yes, we should have a guide like that somewhere.
> >
> >
> > On Wed, Jan 7, 2015 at 12:33 PM, Stephan Ewen wrote:
> >
+1
On Wed, Jan 7, 2015 at 12:41 PM, Aljoscha Krettek
wrote:
> Yes, we should have a guide like that somewhere.
>
>
> On Wed, Jan 7, 2015 at 12:33 PM, Stephan Ewen wrote:
>
> > We have not exactly defined this so far, but it is a good point to do so.
> >
> > I personally find it good to have cha
Yes, we should have a guide like that somewhere.
On Wed, Jan 7, 2015 at 12:33 PM, Stephan Ewen wrote:
> We have not exactly defined this so far, but it is a good point to do so.
>
> I personally find it good to have changes associated with an issue, because
> it allows you to trace back why the
We have not exactly defined this so far, but it is a good point to do so.
I personally find it good to have changes associated with an issue, because
it allows you to trace back why the change was done.
To make sure we do not overdo this and impose totally unnecessary overhead,
I would suggest the
Hi,
I feel we never really talked about this. So, should we open Jira issues
even for very small fixes and then add the ticket number to the commit? Or
should we just commit those small fixes. Right now, I have two small fixes
(one is 4 lines, the other one is two lines) for the ValueTypeInfo and
T
16 matches
Mail list logo
