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 not yield much to omit the component declaration, most of the time then we would need to add it to the commit message itself, e.g. : "[streaming] Join API rework", could be e.g. rewritten as "Join API rework for streaming". I do prefer the former one, because it is not only more straight-forward to understand, but a bit shorter as well. Of course there are counter-examples, like "[streaming] DataStream refactor" -> "DataStream refactor". I can accept optional, but would like to keep it strongly recommended for streaming. I also find the [docs] tag helpful. On Wed, Jan 7, 2015 at 2:43 PM, Stephan Ewen <se...@apache.org> wrote: > 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 <balassi.mar...@gmail.com> > wrote: > > > +1 for the guide, thanks for clarifying the issue > > > > On Wed, Jan 7, 2015 at 2:30 PM, Till Rohrmann <trohrm...@apache.org> > > wrote: > > > > > +1 > > > > > > On Wed, Jan 7, 2015 at 12:41 PM, Aljoscha Krettek <aljos...@apache.org > > > > > wrote: > > > > > > > Yes, we should have a guide like that somewhere. > > > > > > > > > > > > On Wed, Jan 7, 2015 at 12:33 PM, Stephan Ewen <se...@apache.org> > > 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 change was done. > > > > > To make sure we do not overdo this and impose totally unnecessary > > > > overhead, > > > > > I would suggest the following: > > > > > > > > > > *No issue is required for* > > > > > > > > > > - Small fixes like typos, simple warnings, adding/improving a > > comment > > > > > > > > > > - Adding and improving existing pages of the documentation > > > > > > > > > > - Simple improvements of style / elegance / efficiency (simple > > > > rewriting > > > > > a loop / condition / method interaction) if no behavior is changed > > > > > > > > > > ==> Basically anything that does not change or add functionality > > > > > > > > > > > > > > > *An issue is required for* > > > > > > > > > > Everything else, in particular: > > > > > > > > > > - Anything that changes functionality or behavior relevant to > users > > > > > > > > > > - Anything that changes functionality or behavior relevant to > other > > > > > components > > > > > > > > > > - Anything that adds a feature > > > > > > > > > > > > > > > I would vote to allow coarse issues and have multiple commits that > > > > > reference it > > > > > > > > > > [FLINK-1234] [runtime] Runtime support some cool new thing > > > > > [FLINK-1234] [java api] Add hook for cool thing to java api > > > > > [FLINK-1234] [scala api] Add hook for that thing to scala api > > > > > [FLINK-1234] [optimizer] Make optimizer aware that it can exploit > > this > > > > > thing > > > > > > > > > > > > > > > ------------------------- > > > > > > > > > > The guide lines for pull-requests for committers are as follows: > > > > > > > > > > *A pull request with comments/additional signoff is required for > > > anything > > > > > that* > > > > > > > > > > - breaks the public APIs > > > > > > > > > > - adds methods to the public APIs (that will need to be kept > stable > > > > from > > > > > them on) > > > > > > > > > > - alters user-facing behavior (e.g., mutability of types, null > > value > > > > > handling, window semantics, ...) > > > > > > > > > > - adds user-facing knobs (switches, config parameters, execution > > > option > > > > > on the execution environment) > > > > > > > > > > - adds additional maven dependencies > > > > > > > > > > - changes the way components interact > > > > > > > > > > - touches highly sensitive and performance critical parts, such > > > memory > > > > > management or network stack > > > > > > > > > > ==> Changes that come with a pull request should have one or more > > > issues > > > > > associated with them. > > > > > > > > > > > > > > > Anyone that wants to have comments or some additional pairs of eyes > > in > > > > the > > > > > code should make a pull request as well. > > > > > > > > > > ------------------------- > > > > > > > > > > *Naming scheme for commits* > > > > > > > > > > [issue] [component] Message > > > > > > > > > > For fixes without an issue, the issue can be dropped. > > > > > > > > > > > > > > > > > > > > > > > > > What do you think? Should we put this into the Wiki? > > > > > > > > > > > > > > > Greetings, > > > > > Stephan > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 7, 2015 at 11:48 AM, Aljoscha Krettek < > > aljos...@apache.org > > > > > > > > > wrote: > > > > > > > > > > > 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 > > > > > > TextValueInputFormat. Very obscure stuff, I know. :D > > > > > > > > > > > > Cheers, > > > > > > Aljoscha > > > > > > > > > > > > > > > > > > > > >
