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 > > >
