flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Márton Balassi <balassi.mar...@gmail.com>
Subject Re: Question about Commit Policy
Date Wed, 07 Jan 2015 13:34:43 GMT
+1 for the guide, thanks for clarifying the issue

On Wed, Jan 7, 2015 at 2:30 PM, Till Rohrmann <trohrmann@apache.org> wrote:

> +1
>
> On Wed, Jan 7, 2015 at 12:41 PM, Aljoscha Krettek <aljoscha@apache.org>
> wrote:
>
> > Yes, we should have a guide like that somewhere.
> >
> >
> > On Wed, Jan 7, 2015 at 12:33 PM, Stephan Ewen <sewen@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 <aljoscha@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
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message