You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@nifi.apache.org by Tony Kurc <tr...@gmail.com> on 2014/11/26 17:35:36 UTC

git workflow for nifi

I wanted to kick off a discussion about workflow in git. There are a lot of
techniques in git for working effectively as a team, managing several
product versions at once, and for branching and merging code back in. It
looks like several other apache projects have guides for their team
conventions, such as Deltaspike [1] and Accumulo [2], I think it would be
prudent to work on some conventions for NiFi. I've used several styles, one
of which works well for other projects I've worked on is called gitflow
[3]. I like the concepts of gitflow, but I really don't like depending on
maven plugins to execute the conventions. I'd be in favor of something like
gitflow, not sure if others had opinions.

Tony

[1]https://deltaspike.apache.org/suggested-git-workflows.html
[2] https://accumulo.apache.org/git.html
[3]
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/

Re: git workflow for nifi

Posted by Billie Rinaldi <bi...@apache.org>.

I've enjoyed using gitflow in the Slider podling.  It would also be good to
have documentation of how to create patches (for contributors) and how to
apply those patches (for committers).  DeltaSpike and Accumulo both seem to
use the git format-patch / git am method, with Accumulo also using
--signoff (which is probably better).  My understanding is this is
preferable to just applying the patch and committing it with a note
indicating the original contributor, as some other projects do, because it
makes contribution tracking easier.

On Wed, Nov 26, 2014 at 8:35 AM, Tony Kurc <tr...@gmail.com> wrote:

> I wanted to kick off a discussion about workflow in git. There are a lot of
> techniques in git for working effectively as a team, managing several
> product versions at once, and for branching and merging code back in. It
> looks like several other apache projects have guides for their team
> conventions, such as Deltaspike [1] and Accumulo [2], I think it would be
> prudent to work on some conventions for NiFi. I've used several styles, one
> of which works well for other projects I've worked on is called gitflow
> [3]. I like the concepts of gitflow, but I really don't like depending on
> maven plugins to execute the conventions. I'd be in favor of something like
> gitflow, not sure if others had opinions.
>
> Tony
>
> [1]https://deltaspike.apache.org/suggested-git-workflows.html
> [2] https://accumulo.apache.org/git.html
> [3]
>
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/
>

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

Thanks Matt.  We'll get this figured out over time.

By the way i built and can confirm 142 and 143 are good to go!

Thanks
Joe

On Tue, Dec 9, 2014 at 10:41 AM, Matt Gilman <ma...@gmail.com>
wrote:

> Sounds good. FWIW,
>
> https://issues.apache.org/jira/browse/NIFI-142
> https://issues.apache.org/jira/browse/NIFI-143
>
> were addressed without their own branch. Going forward all tickets will be
> done on their own branches and pushed back into central repo (develop) when
> complete.
>
> Thanks.
>
> On Tue, Dec 9, 2014 at 10:34 AM, Joe Witt <jo...@gmail.com> wrote:
>
> > Matt
> >
> > Yes i think even for the most trivial of updates it is possibly
> > worthwhile.  It seems that it will provide a nice traceability to a 'unit
> > of work/ticket'.  Since branching/merging is so cheap/natural this also
> has
> > the really nice side effect of being able to selectively
> > include/revert/etc..
> >
> > Wondering though if these branches should be pushed to this central repo.
> > I assume so.
> >
> > In all these cases I am making this up based on my own limited Git
> > experience and knowledge so look forward to other views.
> >
> > Thanks
> > Joe
> >
> > On Tue, Dec 9, 2014 at 10:28 AM, Matt Gilman <ma...@gmail.com>
> > wrote:
> >
> > > We definitely need to discuss what the expectations are here as this is
> > my
> > > first time working in this model. I've now addressed two minor isolated
> > > issues without 'feature' branching. This work was performed and pushed
> > back
> > > to the develop branch. Do we really want to require branching off of
> > > develop when the issue is something as simple as adding a dependency
> to a
> > > pom (which was the case for one of the issues)?
> > >
> > > Thanks.
> > >
> > > On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com> wrote:
> > >
> > > > Hello
> > > >
> > > > So a question on gitflow given that commits are now underway.  When
> > > working
> > > > on a feature in a local repo which is a branch off the develop
> > > branch...do
> > > > you push the feature branch to the central repo?  This then can be
> > merged
> > > > by someone else as a sort of code review/pull process?
> > > >
> > > > Thanks
> > > > Joe
> > > >
> > > > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
> wrote:
> > > >
> > > > > All,
> > > > >
> > > > > Now that we have our code up it is important to establish a process
> > > > around
> > > > > git in particular.  A general consensus in the thread appears to be
> > > that
> > > > > gitflow workflow is a reasonable option.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> > > > >
> > > > > To that end I've added a develop branch off of master from which
> > > features
> > > > > can be built.  As we converge toward a release then we'll
> > > > address/introduce
> > > > > some of the other aspects of gitflow.
> > > > >
> > > > > Please discuss/comment if there are views that we should be taking
> > > > another
> > > > > path.
> > > > >
> > > > > Thanks
> > > > > Joe
> > > > >
> > > > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> > > bimargulies@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> > wikier@apache.org>
> > > > >> wrote:
> > > > >> > Hi Adam,
> > > > >> >
> > > > >> > one remarks about this:
> > > > >> >
> > > > >> > On 28/11/14 18:07, Adam Taft wrote:
> > > > >> >>
> > > > >> >> Knowing how we work today, if it were me, I would suggest using
> > the
> > > > >> above
> > > > >> >> workflow combined with the "forking workflow" to guard access
> to
> > > the
> > > > >> >> production release (master) branches.  A very small subset of
> the
> > > > >> >> incubator's commiters should have the ability to merge the
> > > "develop"
> > > > >> >> branch
> > > > >> >> down to a master "release" branch.
> > > > >> >
> > > > >> >
> > > > >> > Suck workflow is not in place in ASF. On the one hand, the
> current
> > > git
> > > > >> > infrastructure does not provide such branches' management, like
> > > > >> > bitbucket/stash do for instance. On the other hand, and more
> > > > important,
> > > > >> a
> > > > >> > project is not hierarchical organization, but a a meritocratic
> > one.
> > > > >> >
> > > > >> > I recommend you this blog post in case you want to read a bit
> > more:
> > > > >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> > > > >> >
> > > > >> > If someone has permissions to do (i.e., he is a committer), he
> can
> > > do
> > > > >> it,
> > > > >> > simple The tool provide you instruments to revert those changes
> in
> > > > case
> > > > >> on
> > > > >> > involuntary errors.
> > > > >> >
> > > > >> >>  It would be ideal to have someone who
> > > > >> >> is NOT performing the majority of changes on the "develop"
> branch
> > > > take
> > > > >> >> this
> > > > >> >> role to coordinate releases, ensure minimal coding standards,
> run
> > > > >> through
> > > > >> >> unit and integration tests, before signing off on the release
> and
> > > > >> issuing
> > > > >> >> the release artifacts.
> > > > >>
> > > > >> You seem to be imagining an individual with a job which is shared
> in
> > > > >> by the community. In healthy communities, a release happens when
> > > > >> there's a consensus to have a release. There is no person who
> > 'ensures
> > > > >> minimal coding standards', that's everyone watching commits.
> There's
> > > > >> no one 'running unit and integration tests' because (a) every
> > > > >> committer does this before every commit, (b) Jenkins does it, (c)
> > the
> > > > >> release process does it. (d) there's no signing off on a release.
> > The
> > > > >> RM puts it up for a vote, and PMC members vote.
> > > > >>
> > > > >>
> > > > >> >
> > > > >> >
> > > > >> > Release comes after that. The release manager is responsible on
> > > > >> creating a
> > > > >> > proper release, which must include a code release and should
> > include
> > > > >> > binaries too. Each artifact release must be signed. Demonstrate
> > your
> > > > >> ability
> > > > >> > as a project to produce releases is one of the goals of the
> > > > incubation.
> > > > >> But
> > > > >> > we are not yet there, step by step.
> > > > >> >
> > > > >> > Hope that helps.
> > > > >> >
> > > > >> > Cheers,
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Sergio Fernández
> > > > >> > Partner Technology Manager
> > > > >> > Redlink GmbH
> > > > >> > m: +43 660 2747 925
> > > > >> > e: sergio.fernandez@redlink.co
> > > > >> > w: http://redlink.co
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: git workflow for nifi

Posted by Matt Gilman <ma...@gmail.com>.

Sounds good. FWIW,

https://issues.apache.org/jira/browse/NIFI-142
https://issues.apache.org/jira/browse/NIFI-143

were addressed without their own branch. Going forward all tickets will be
done on their own branches and pushed back into central repo (develop) when
complete.

Thanks.

On Tue, Dec 9, 2014 at 10:34 AM, Joe Witt <jo...@gmail.com> wrote:

> Matt
>
> Yes i think even for the most trivial of updates it is possibly
> worthwhile.  It seems that it will provide a nice traceability to a 'unit
> of work/ticket'.  Since branching/merging is so cheap/natural this also has
> the really nice side effect of being able to selectively
> include/revert/etc..
>
> Wondering though if these branches should be pushed to this central repo.
> I assume so.
>
> In all these cases I am making this up based on my own limited Git
> experience and knowledge so look forward to other views.
>
> Thanks
> Joe
>
> On Tue, Dec 9, 2014 at 10:28 AM, Matt Gilman <ma...@gmail.com>
> wrote:
>
> > We definitely need to discuss what the expectations are here as this is
> my
> > first time working in this model. I've now addressed two minor isolated
> > issues without 'feature' branching. This work was performed and pushed
> back
> > to the develop branch. Do we really want to require branching off of
> > develop when the issue is something as simple as adding a dependency to a
> > pom (which was the case for one of the issues)?
> >
> > Thanks.
> >
> > On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com> wrote:
> >
> > > Hello
> > >
> > > So a question on gitflow given that commits are now underway.  When
> > working
> > > on a feature in a local repo which is a branch off the develop
> > branch...do
> > > you push the feature branch to the central repo?  This then can be
> merged
> > > by someone else as a sort of code review/pull process?
> > >
> > > Thanks
> > > Joe
> > >
> > > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com> wrote:
> > >
> > > > All,
> > > >
> > > > Now that we have our code up it is important to establish a process
> > > around
> > > > git in particular.  A general consensus in the thread appears to be
> > that
> > > > gitflow workflow is a reasonable option.
> > > >
> > > >
> > > >
> > >
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> > > >
> > > > To that end I've added a develop branch off of master from which
> > features
> > > > can be built.  As we converge toward a release then we'll
> > > address/introduce
> > > > some of the other aspects of gitflow.
> > > >
> > > > Please discuss/comment if there are views that we should be taking
> > > another
> > > > path.
> > > >
> > > > Thanks
> > > > Joe
> > > >
> > > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> > bimargulies@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> wikier@apache.org>
> > > >> wrote:
> > > >> > Hi Adam,
> > > >> >
> > > >> > one remarks about this:
> > > >> >
> > > >> > On 28/11/14 18:07, Adam Taft wrote:
> > > >> >>
> > > >> >> Knowing how we work today, if it were me, I would suggest using
> the
> > > >> above
> > > >> >> workflow combined with the "forking workflow" to guard access to
> > the
> > > >> >> production release (master) branches.  A very small subset of the
> > > >> >> incubator's commiters should have the ability to merge the
> > "develop"
> > > >> >> branch
> > > >> >> down to a master "release" branch.
> > > >> >
> > > >> >
> > > >> > Suck workflow is not in place in ASF. On the one hand, the current
> > git
> > > >> > infrastructure does not provide such branches' management, like
> > > >> > bitbucket/stash do for instance. On the other hand, and more
> > > important,
> > > >> a
> > > >> > project is not hierarchical organization, but a a meritocratic
> one.
> > > >> >
> > > >> > I recommend you this blog post in case you want to read a bit
> more:
> > > >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> > > >> >
> > > >> > If someone has permissions to do (i.e., he is a committer), he can
> > do
> > > >> it,
> > > >> > simple The tool provide you instruments to revert those changes in
> > > case
> > > >> on
> > > >> > involuntary errors.
> > > >> >
> > > >> >>  It would be ideal to have someone who
> > > >> >> is NOT performing the majority of changes on the "develop" branch
> > > take
> > > >> >> this
> > > >> >> role to coordinate releases, ensure minimal coding standards, run
> > > >> through
> > > >> >> unit and integration tests, before signing off on the release and
> > > >> issuing
> > > >> >> the release artifacts.
> > > >>
> > > >> You seem to be imagining an individual with a job which is shared in
> > > >> by the community. In healthy communities, a release happens when
> > > >> there's a consensus to have a release. There is no person who
> 'ensures
> > > >> minimal coding standards', that's everyone watching commits. There's
> > > >> no one 'running unit and integration tests' because (a) every
> > > >> committer does this before every commit, (b) Jenkins does it, (c)
> the
> > > >> release process does it. (d) there's no signing off on a release.
> The
> > > >> RM puts it up for a vote, and PMC members vote.
> > > >>
> > > >>
> > > >> >
> > > >> >
> > > >> > Release comes after that. The release manager is responsible on
> > > >> creating a
> > > >> > proper release, which must include a code release and should
> include
> > > >> > binaries too. Each artifact release must be signed. Demonstrate
> your
> > > >> ability
> > > >> > as a project to produce releases is one of the goals of the
> > > incubation.
> > > >> But
> > > >> > we are not yet there, step by step.
> > > >> >
> > > >> > Hope that helps.
> > > >> >
> > > >> > Cheers,
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Sergio Fernández
> > > >> > Partner Technology Manager
> > > >> > Redlink GmbH
> > > >> > m: +43 660 2747 925
> > > >> > e: sergio.fernandez@redlink.co
> > > >> > w: http://redlink.co
> > > >>
> > > >
> > > >
> > >
> >
>

Re: git workflow for nifi

Posted by Billie Rinaldi <bi...@apache.org>.

If you just use git-flow, it will do the correct thing when merging
features into the develop branch -- if there haven't been any changes in
develop, it will not appear as a separate branch.  In my opinion, smaller
feature branches can just be finished locally and those branches do not
need to be pushed.  For larger features that take longer to complete, it
can be useful to push the feature branch so others can see the commits and
possibly give feedback.

Are we planning to use CTR?

On Tue, Dec 9, 2014 at 7:34 AM, Joe Witt <jo...@gmail.com> wrote:

> Matt
>
> Yes i think even for the most trivial of updates it is possibly
> worthwhile.  It seems that it will provide a nice traceability to a 'unit
> of work/ticket'.  Since branching/merging is so cheap/natural this also has
> the really nice side effect of being able to selectively
> include/revert/etc..
>
> Wondering though if these branches should be pushed to this central repo.
> I assume so.
>
> In all these cases I am making this up based on my own limited Git
> experience and knowledge so look forward to other views.
>
> Thanks
> Joe
>
> On Tue, Dec 9, 2014 at 10:28 AM, Matt Gilman <ma...@gmail.com>
> wrote:
>
> > We definitely need to discuss what the expectations are here as this is
> my
> > first time working in this model. I've now addressed two minor isolated
> > issues without 'feature' branching. This work was performed and pushed
> back
> > to the develop branch. Do we really want to require branching off of
> > develop when the issue is something as simple as adding a dependency to a
> > pom (which was the case for one of the issues)?
> >
> > Thanks.
> >
> > On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com> wrote:
> >
> > > Hello
> > >
> > > So a question on gitflow given that commits are now underway.  When
> > working
> > > on a feature in a local repo which is a branch off the develop
> > branch...do
> > > you push the feature branch to the central repo?  This then can be
> merged
> > > by someone else as a sort of code review/pull process?
> > >
> > > Thanks
> > > Joe
> > >
> > > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com> wrote:
> > >
> > > > All,
> > > >
> > > > Now that we have our code up it is important to establish a process
> > > around
> > > > git in particular.  A general consensus in the thread appears to be
> > that
> > > > gitflow workflow is a reasonable option.
> > > >
> > > >
> > > >
> > >
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> > > >
> > > > To that end I've added a develop branch off of master from which
> > features
> > > > can be built.  As we converge toward a release then we'll
> > > address/introduce
> > > > some of the other aspects of gitflow.
> > > >
> > > > Please discuss/comment if there are views that we should be taking
> > > another
> > > > path.
> > > >
> > > > Thanks
> > > > Joe
> > > >
> > > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> > bimargulies@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> wikier@apache.org>
> > > >> wrote:
> > > >> > Hi Adam,
> > > >> >
> > > >> > one remarks about this:
> > > >> >
> > > >> > On 28/11/14 18:07, Adam Taft wrote:
> > > >> >>
> > > >> >> Knowing how we work today, if it were me, I would suggest using
> the
> > > >> above
> > > >> >> workflow combined with the "forking workflow" to guard access to
> > the
> > > >> >> production release (master) branches.  A very small subset of the
> > > >> >> incubator's commiters should have the ability to merge the
> > "develop"
> > > >> >> branch
> > > >> >> down to a master "release" branch.
> > > >> >
> > > >> >
> > > >> > Suck workflow is not in place in ASF. On the one hand, the current
> > git
> > > >> > infrastructure does not provide such branches' management, like
> > > >> > bitbucket/stash do for instance. On the other hand, and more
> > > important,
> > > >> a
> > > >> > project is not hierarchical organization, but a a meritocratic
> one.
> > > >> >
> > > >> > I recommend you this blog post in case you want to read a bit
> more:
> > > >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> > > >> >
> > > >> > If someone has permissions to do (i.e., he is a committer), he can
> > do
> > > >> it,
> > > >> > simple The tool provide you instruments to revert those changes in
> > > case
> > > >> on
> > > >> > involuntary errors.
> > > >> >
> > > >> >>  It would be ideal to have someone who
> > > >> >> is NOT performing the majority of changes on the "develop" branch
> > > take
> > > >> >> this
> > > >> >> role to coordinate releases, ensure minimal coding standards, run
> > > >> through
> > > >> >> unit and integration tests, before signing off on the release and
> > > >> issuing
> > > >> >> the release artifacts.
> > > >>
> > > >> You seem to be imagining an individual with a job which is shared in
> > > >> by the community. In healthy communities, a release happens when
> > > >> there's a consensus to have a release. There is no person who
> 'ensures
> > > >> minimal coding standards', that's everyone watching commits. There's
> > > >> no one 'running unit and integration tests' because (a) every
> > > >> committer does this before every commit, (b) Jenkins does it, (c)
> the
> > > >> release process does it. (d) there's no signing off on a release.
> The
> > > >> RM puts it up for a vote, and PMC members vote.
> > > >>
> > > >>
> > > >> >
> > > >> >
> > > >> > Release comes after that. The release manager is responsible on
> > > >> creating a
> > > >> > proper release, which must include a code release and should
> include
> > > >> > binaries too. Each artifact release must be signed. Demonstrate
> your
> > > >> ability
> > > >> > as a project to produce releases is one of the goals of the
> > > incubation.
> > > >> But
> > > >> > we are not yet there, step by step.
> > > >> >
> > > >> > Hope that helps.
> > > >> >
> > > >> > Cheers,
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Sergio Fernández
> > > >> > Partner Technology Manager
> > > >> > Redlink GmbH
> > > >> > m: +43 660 2747 925
> > > >> > e: sergio.fernandez@redlink.co
> > > >> > w: http://redlink.co
> > > >>
> > > >
> > > >
> > >
> >
>

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

Matt

Yes i think even for the most trivial of updates it is possibly
worthwhile.  It seems that it will provide a nice traceability to a 'unit
of work/ticket'.  Since branching/merging is so cheap/natural this also has
the really nice side effect of being able to selectively
include/revert/etc..

Wondering though if these branches should be pushed to this central repo.
I assume so.

In all these cases I am making this up based on my own limited Git
experience and knowledge so look forward to other views.

Thanks
Joe

On Tue, Dec 9, 2014 at 10:28 AM, Matt Gilman <ma...@gmail.com>
wrote:

> We definitely need to discuss what the expectations are here as this is my
> first time working in this model. I've now addressed two minor isolated
> issues without 'feature' branching. This work was performed and pushed back
> to the develop branch. Do we really want to require branching off of
> develop when the issue is something as simple as adding a dependency to a
> pom (which was the case for one of the issues)?
>
> Thanks.
>
> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com> wrote:
>
> > Hello
> >
> > So a question on gitflow given that commits are now underway.  When
> working
> > on a feature in a local repo which is a branch off the develop
> branch...do
> > you push the feature branch to the central repo?  This then can be merged
> > by someone else as a sort of code review/pull process?
> >
> > Thanks
> > Joe
> >
> > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com> wrote:
> >
> > > All,
> > >
> > > Now that we have our code up it is important to establish a process
> > around
> > > git in particular.  A general consensus in the thread appears to be
> that
> > > gitflow workflow is a reasonable option.
> > >
> > >
> > >
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> > >
> > > To that end I've added a develop branch off of master from which
> features
> > > can be built.  As we converge toward a release then we'll
> > address/introduce
> > > some of the other aspects of gitflow.
> > >
> > > Please discuss/comment if there are views that we should be taking
> > another
> > > path.
> > >
> > > Thanks
> > > Joe
> > >
> > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> bimargulies@gmail.com
> > >
> > > wrote:
> > >
> > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <wi...@apache.org>
> > >> wrote:
> > >> > Hi Adam,
> > >> >
> > >> > one remarks about this:
> > >> >
> > >> > On 28/11/14 18:07, Adam Taft wrote:
> > >> >>
> > >> >> Knowing how we work today, if it were me, I would suggest using the
> > >> above
> > >> >> workflow combined with the "forking workflow" to guard access to
> the
> > >> >> production release (master) branches.  A very small subset of the
> > >> >> incubator's commiters should have the ability to merge the
> "develop"
> > >> >> branch
> > >> >> down to a master "release" branch.
> > >> >
> > >> >
> > >> > Suck workflow is not in place in ASF. On the one hand, the current
> git
> > >> > infrastructure does not provide such branches' management, like
> > >> > bitbucket/stash do for instance. On the other hand, and more
> > important,
> > >> a
> > >> > project is not hierarchical organization, but a a meritocratic one.
> > >> >
> > >> > I recommend you this blog post in case you want to read a bit more:
> > >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> > >> >
> > >> > If someone has permissions to do (i.e., he is a committer), he can
> do
> > >> it,
> > >> > simple The tool provide you instruments to revert those changes in
> > case
> > >> on
> > >> > involuntary errors.
> > >> >
> > >> >>  It would be ideal to have someone who
> > >> >> is NOT performing the majority of changes on the "develop" branch
> > take
> > >> >> this
> > >> >> role to coordinate releases, ensure minimal coding standards, run
> > >> through
> > >> >> unit and integration tests, before signing off on the release and
> > >> issuing
> > >> >> the release artifacts.
> > >>
> > >> You seem to be imagining an individual with a job which is shared in
> > >> by the community. In healthy communities, a release happens when
> > >> there's a consensus to have a release. There is no person who 'ensures
> > >> minimal coding standards', that's everyone watching commits. There's
> > >> no one 'running unit and integration tests' because (a) every
> > >> committer does this before every commit, (b) Jenkins does it, (c) the
> > >> release process does it. (d) there's no signing off on a release. The
> > >> RM puts it up for a vote, and PMC members vote.
> > >>
> > >>
> > >> >
> > >> >
> > >> > Release comes after that. The release manager is responsible on
> > >> creating a
> > >> > proper release, which must include a code release and should include
> > >> > binaries too. Each artifact release must be signed. Demonstrate your
> > >> ability
> > >> > as a project to produce releases is one of the goals of the
> > incubation.
> > >> But
> > >> > we are not yet there, step by step.
> > >> >
> > >> > Hope that helps.
> > >> >
> > >> > Cheers,
> > >> >
> > >> >
> > >> > --
> > >> > Sergio Fernández
> > >> > Partner Technology Manager
> > >> > Redlink GmbH
> > >> > m: +43 660 2747 925
> > >> > e: sergio.fernandez@redlink.co
> > >> > w: http://redlink.co
> > >>
> > >
> > >
> >
>

Re: git workflow for nifi

Posted by Matt Gilman <ma...@gmail.com>.

We definitely need to discuss what the expectations are here as this is my
first time working in this model. I've now addressed two minor isolated
issues without 'feature' branching. This work was performed and pushed back
to the develop branch. Do we really want to require branching off of
develop when the issue is something as simple as adding a dependency to a
pom (which was the case for one of the issues)?

Thanks.

On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com> wrote:

> Hello
>
> So a question on gitflow given that commits are now underway.  When working
> on a feature in a local repo which is a branch off the develop branch...do
> you push the feature branch to the central repo?  This then can be merged
> by someone else as a sort of code review/pull process?
>
> Thanks
> Joe
>
> On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com> wrote:
>
> > All,
> >
> > Now that we have our code up it is important to establish a process
> around
> > git in particular.  A general consensus in the thread appears to be that
> > gitflow workflow is a reasonable option.
> >
> >
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> >
> > To that end I've added a develop branch off of master from which features
> > can be built.  As we converge toward a release then we'll
> address/introduce
> > some of the other aspects of gitflow.
> >
> > Please discuss/comment if there are views that we should be taking
> another
> > path.
> >
> > Thanks
> > Joe
> >
> > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <bimargulies@gmail.com
> >
> > wrote:
> >
> >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <wi...@apache.org>
> >> wrote:
> >> > Hi Adam,
> >> >
> >> > one remarks about this:
> >> >
> >> > On 28/11/14 18:07, Adam Taft wrote:
> >> >>
> >> >> Knowing how we work today, if it were me, I would suggest using the
> >> above
> >> >> workflow combined with the "forking workflow" to guard access to the
> >> >> production release (master) branches.  A very small subset of the
> >> >> incubator's commiters should have the ability to merge the "develop"
> >> >> branch
> >> >> down to a master "release" branch.
> >> >
> >> >
> >> > Suck workflow is not in place in ASF. On the one hand, the current git
> >> > infrastructure does not provide such branches' management, like
> >> > bitbucket/stash do for instance. On the other hand, and more
> important,
> >> a
> >> > project is not hierarchical organization, but a a meritocratic one.
> >> >
> >> > I recommend you this blog post in case you want to read a bit more:
> >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> >> >
> >> > If someone has permissions to do (i.e., he is a committer), he can do
> >> it,
> >> > simple The tool provide you instruments to revert those changes in
> case
> >> on
> >> > involuntary errors.
> >> >
> >> >>  It would be ideal to have someone who
> >> >> is NOT performing the majority of changes on the "develop" branch
> take
> >> >> this
> >> >> role to coordinate releases, ensure minimal coding standards, run
> >> through
> >> >> unit and integration tests, before signing off on the release and
> >> issuing
> >> >> the release artifacts.
> >>
> >> You seem to be imagining an individual with a job which is shared in
> >> by the community. In healthy communities, a release happens when
> >> there's a consensus to have a release. There is no person who 'ensures
> >> minimal coding standards', that's everyone watching commits. There's
> >> no one 'running unit and integration tests' because (a) every
> >> committer does this before every commit, (b) Jenkins does it, (c) the
> >> release process does it. (d) there's no signing off on a release. The
> >> RM puts it up for a vote, and PMC members vote.
> >>
> >>
> >> >
> >> >
> >> > Release comes after that. The release manager is responsible on
> >> creating a
> >> > proper release, which must include a code release and should include
> >> > binaries too. Each artifact release must be signed. Demonstrate your
> >> ability
> >> > as a project to produce releases is one of the goals of the
> incubation.
> >> But
> >> > we are not yet there, step by step.
> >> >
> >> > Hope that helps.
> >> >
> >> > Cheers,
> >> >
> >> >
> >> > --
> >> > Sergio Fernández
> >> > Partner Technology Manager
> >> > Redlink GmbH
> >> > m: +43 660 2747 925
> >> > e: sergio.fernandez@redlink.co
> >> > w: http://redlink.co
> >>
> >
> >
>

Re: git workflow for nifi

Posted by Sean Busbey <bu...@cloudera.com>.

On Wed, Dec 10, 2014 at 8:42 PM, Joe Witt <jo...@gmail.com> wrote:

>
> That said I do believe we can afford to give up speed if we can trade it
> for even higher quality and if we can operate in a manner that is more
> conducive to growing a community.  Both of which are things we want.  For
> new features we want folks to have a chance to understand them and provide
> alternative views.  I also think some of our sense of speed is us tricking
> ourselves that fixing bugs quickly means we're fast.  It often does just
> mean we make bugs fast and as a result we have to fix the fast which on net
> is slow...if that makes sense.  The more I think about this the more I like
> RTC provided we can define the 'review' reasonably.  I would like to see a
> 'review' be a 'committer' other than yourself independently reviews the
> code to ensure it is consistent with the overall design of the application
> and so on and flags it as such on the ticket or using a nicely integrated
> Jira tool, etc..
>

This is what all of the RtC ASF projects I've been exposed to use. The only
time something more formal is needed is the situation Joey mentioned, where
there is an unreconcilable -1. Those are (and should be) extremely rare
because a contributor should be actively seeking compromise positions.

Some projects will use a more relaxed standard for "trivial fixes", but
that usually ends up being very subjective. For example, fixing a simple
NPE might miss adding a test to make sure a regression doesn't happen
later. In an active community a +1 for simple changes are usually very
quick when everything is lined up nicely.

One tool that might ease going RtC is the review tool Gerrit. It can be
configured to automatically push to a git repo once a configurable number
of binding parties have flagged a change +1, which can help ease the burden
of reviewing. I know I've seen other ASF projects consider it, but I don't
know if anyone has followed through to see if infra will set things up.
Wether Gerrit is available or not, the ASF ReviewBoard works well enough
for most cases.

-- 
Sean

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

Mark,

I agree that the most important question for RTC then is what constitutes a
valid review.

That said I do believe we can afford to give up speed if we can trade it
for even higher quality and if we can operate in a manner that is more
conducive to growing a community.  Both of which are things we want.  For
new features we want folks to have a chance to understand them and provide
alternative views.  I also think some of our sense of speed is us tricking
ourselves that fixing bugs quickly means we're fast.  It often does just
mean we make bugs fast and as a result we have to fix the fast which on net
is slow...if that makes sense.  The more I think about this the more I like
RTC provided we can define the 'review' reasonably.  I would like to see a
'review' be a 'committer' other than yourself independently reviews the
code to ensure it is consistent with the overall design of the application
and so on and flags it as such on the ticket or using a nicely integrated
Jira tool, etc..

Thanks
Joe

On Wed, Dec 10, 2014 at 9:34 PM, Mark Payne <ma...@hotmail.com> wrote:

> I think the big question, which you brought up, is "what constitutes a
> review?" If another committer looking over the code and signing off is
> sufficient then I'm not horribly opposed, though I think it will VERY MUCH
> impede the speed at which any new features / bug fixes can be accomplished.
>
> If we are talking about waiting for several people to vote, then I think
> it's an absolute non-starter and destroys any hope of moving even at a
> fraction of the rate we are used to. This is especially concerning if we
> are waiting for a consensus for something like a trivial bug fix like an
> NPE.
>
> Thanks
> -Mark
>
> > On Dec 10, 2014, at 9:20 PM, Joe Witt <jo...@gmail.com> wrote:
> >
> > NiFi grew up in a CT[R] environment where the review was very rare and so
> > really we ended up with CTDTFSOR - Commit then deploy then feel sense of
> > regret.
> >
> > So the bad side: We ended up with a lot of avoidable defects where by
> > avoidable I mean they could have likely been detected in a decent review
> > effort.
> >
> > The good side: We were fast.  Very fast.  New features got out quick and
> if
> > something was funky we fixed it very fast.  For the vast majority of
> > mistakes the problem was highly isolated (thanks to our base design
> > construct of FBP) and rarely caused extremely stressful days.
> >
> > On balance though and given the benefits it has to community growth I
> > personally am very supportive of us adopting RTC immediately provided we
> > can sort out some key questions:
> >
> > - What constitutes a valid review?
> > This page
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > suggests that a review is a consensus approval.  I am very concerned by
> > that definition if we're talking every commit means we need a vote.  For
> > the vast majority of commits this just seems to onerous and too time
> > consuming and frankly to me takes some of the fun out of developing.  If
> > for us a review is simply that a 'committer' has reviewed the code then I
> > am perfectly happy with this and I am thinking this is in-line with the
> > model Benson described for his dayjob "'make branch, submit pr, get
> review,
> > merge'"
> >
> > - What is the best tooling/process around this to actually
> conduct/document
> > the review?
> > I think
> >
> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
> > does a good job of describing the mechanics of a review/submission
> > process.  And I'd just assume a patch is as good as a pull request.  I
> > think even as a good starting point having the JIRA ticket commented on
> by
> > the reviewer would be good.
> >
> > - What are some key things a reviewer should be checking for and helping
> to
> > enforce?  What are some out of bounds things?
> >
> >
> >
> > This seems like a really important discussion and something that we
> should
> > center on sooner than later.  There are ways to nuance this such as RTC
> for
> > the core and CTR for extensions and so on but I think that just leads to
> > more confusion.  We should likely pick our poison. I see strong benefits
> in
> > both directions and so I can deal either way personally.  I see a couple
> > strong arguments here in this thread already for RTC .
> >
> > Anyone willing to argue for CTR?
> >
> > Thanks
> > Joe
> >
> >
> > On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <bimargulies@gmail.com
> >
> > wrote:
> >
> >> It seems to me, and this is purely opinion, that RTC has a lot to be
> said
> >> for a new project, in terms of getting more people involved, more
> eyeballs,
> >> and more of a community feeling. My dayjob workflow is 'make branch,
> submit
> >> pr, get review, merge' and that seems pretty applicable. However, I am
> not
> >> wearing any magic mentor hat-o-authority.
> >>
> >>> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org>
> wrote:
> >>>
> >>>> On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
> >>>>
> >>>> Benson - thanks for the headsup on the maven plugin.  Seems like using
> >>> them
> >>>> to their fullest capability and then manually merging to master is
> >>>> perfectly fine to me.
> >>>>
> >>>> Billie
> >>>> As for CTR i don't think i have a good enough appreciation for the
> >>>> process/value proposition here.  Curious of other folks views.
> >>>
> >>> Both CTR and RTC have their own advantages, so either would be fine (
> >>> http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
> >>> retrospect I see my question could be viewed as leaning towards CTR,
> but
> >> it
> >>> was just based on an observation that people already seemed to be
> making
> >>> commits without review.
> >>>
> >>>
> >>>>
> >>>> It seems reasonable to keep the feature branch relaxed and in that
> >> sense
> >>>> what Gilman did today seems fine.  We can get bettter at those
> >> judgement
> >>>> calls and documenting the criteria as we go along.
> >>>>
> >>>> Thanks
> >>>> Joe
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
> >> bimargulies@gmail.com
> >>>>
> >>>> wrote:
> >>>>
> >>>>> PR's are certainly convenient. There's no much difference, for a
> >>>> committer,
> >>>>> between pushing a branch to the official repo and pushing a branch to
> >>>> some
> >>>>> personal repo on github. The same integration workflow can be used
> >>> either
> >>>>> way to close out the PR upon merge.
> >>>>>
> >>>>> However, in a CTR project, it seems perhaps excessive to _require_
> >>>> feature
> >>>>> branches for small fixes as opposed to just committing them directly
> >> to
> >>>>> develop. At day job we do mostly do branch-per-jira, but some people
> >>>> might
> >>>>> find that onerous.
> >>>>>
> >>>>> Pushing to the official repo leaves more history that someone might
> >>> find
> >>>>> interesting some day. Also more clutter; some people are very
> >> concerned
> >>>>> about repacking before merging to develop.
> >>>>>
> >>>>> Another issue with gitflow is the master branch. The master branch is
> >>>>> supposed to get merged to for releases. The maven-release-plugin
> >> won't
> >>> do
> >>>>> that, and the jgitflow plugin is unsafe. So one option is to 'use
> >>>> gitflow'
> >>>>> but not bother with the master versus develop distinction, the other
> >> is
> >>>> to
> >>>>> do manual merges to master at release points.
> >>>>>
> >>>>>
> >>>>> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
> >> wrote:
> >>>>>
> >>>>>> Hello
> >>>>>>
> >>>>>> So a question on gitflow given that commits are now underway.  When
> >>>>> working
> >>>>>> on a feature in a local repo which is a branch off the develop
> >>>>> branch...do
> >>>>>> you push the feature branch to the central repo?  This then can be
> >>>> merged
> >>>>>> by someone else as a sort of code review/pull process?
> >>>>>>
> >>>>>> Thanks
> >>>>>> Joe
> >>>>>>
> >>>>>> On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>>> All,
> >>>>>>>
> >>>>>>> Now that we have our code up it is important to establish a
> >> process
> >>>>>> around
> >>>>>>> git in particular.  A general consensus in the thread appears to
> >> be
> >>>>> that
> >>>>>>> gitflow workflow is a reasonable option.
> >>
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> >>>>>>>
> >>>>>>> To that end I've added a develop branch off of master from which
> >>>>> features
> >>>>>>> can be built.  As we converge toward a release then we'll
> >>>>>> address/introduce
> >>>>>>> some of the other aspects of gitflow.
> >>>>>>>
> >>>>>>> Please discuss/comment if there are views that we should be
> >> taking
> >>>>>> another
> >>>>>>> path.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Joe
> >>>>>>>
> >>>>>>> On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> >>>>> bimargulies@gmail.com
> >>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> >>>> wikier@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>> Hi Adam,
> >>>>>>>>>
> >>>>>>>>> one remarks about this:
> >>>>>>>>>
> >>>>>>>>>> On 28/11/14 18:07, Adam Taft wrote:
> >>>>>>>>>>
> >>>>>>>>>> Knowing how we work today, if it were me, I would suggest
> >> using
> >>>> the
> >>>>>>>> above
> >>>>>>>>>> workflow combined with the "forking workflow" to guard access
> >>> to
> >>>>> the
> >>>>>>>>>> production release (master) branches.  A very small subset of
> >>> the
> >>>>>>>>>> incubator's commiters should have the ability to merge the
> >>>>> "develop"
> >>>>>>>>>> branch
> >>>>>>>>>> down to a master "release" branch.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Suck workflow is not in place in ASF. On the one hand, the
> >>> current
> >>>>> git
> >>>>>>>>> infrastructure does not provide such branches' management,
> >> like
> >>>>>>>>> bitbucket/stash do for instance. On the other hand, and more
> >>>>>> important,
> >>>>>>>> a
> >>>>>>>>> project is not hierarchical organization, but a a meritocratic
> >>>> one.
> >>>>>>>>>
> >>>>>>>>> I recommend you this blog post in case you want to read a bit
> >>>> more:
> >> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> >>>>>>>>>
> >>>>>>>>> If someone has permissions to do (i.e., he is a committer), he
> >>> can
> >>>>> do
> >>>>>>>> it,
> >>>>>>>>> simple The tool provide you instruments to revert those
> >> changes
> >>> in
> >>>>>> case
> >>>>>>>> on
> >>>>>>>>> involuntary errors.
> >>>>>>>>>
> >>>>>>>>>> It would be ideal to have someone who
> >>>>>>>>>> is NOT performing the majority of changes on the "develop"
> >>> branch
> >>>>>> take
> >>>>>>>>>> this
> >>>>>>>>>> role to coordinate releases, ensure minimal coding standards,
> >>> run
> >>>>>>>> through
> >>>>>>>>>> unit and integration tests, before signing off on the release
> >>> and
> >>>>>>>> issuing
> >>>>>>>>>> the release artifacts.
> >>>>>>>>
> >>>>>>>> You seem to be imagining an individual with a job which is
> >> shared
> >>> in
> >>>>>>>> by the community. In healthy communities, a release happens when
> >>>>>>>> there's a consensus to have a release. There is no person who
> >>>> 'ensures
> >>>>>>>> minimal coding standards', that's everyone watching commits.
> >>> There's
> >>>>>>>> no one 'running unit and integration tests' because (a) every
> >>>>>>>> committer does this before every commit, (b) Jenkins does it,
> >> (c)
> >>>> the
> >>>>>>>> release process does it. (d) there's no signing off on a
> >> release.
> >>>> The
> >>>>>>>> RM puts it up for a vote, and PMC members vote.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Release comes after that. The release manager is responsible
> >> on
> >>>>>>>> creating a
> >>>>>>>>> proper release, which must include a code release and should
> >>>> include
> >>>>>>>>> binaries too. Each artifact release must be signed.
> >> Demonstrate
> >>>> your
> >>>>>>>> ability
> >>>>>>>>> as a project to produce releases is one of the goals of the
> >>>>>> incubation.
> >>>>>>>> But
> >>>>>>>>> we are not yet there, step by step.
> >>>>>>>>>
> >>>>>>>>> Hope that helps.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Sergio Fernández
> >>>>>>>>> Partner Technology Manager
> >>>>>>>>> Redlink GmbH
> >>>>>>>>> m: +43 660 2747 925
> >>>>>>>>> e: sergio.fernandez@redlink.co
> >>>>>>>>> w: http://redlink.co
> >>
>

Re: git workflow for nifi

Posted by Andrew Purtell <ap...@apache.org>.

I'd also like to concur with this opinion. In the early days of a project
incubated with an established code base, everyone knows each other well and
there's been a prior process of vetting contributors. Going forward you may
well vote in committers who later don't pan out as well as the project
might have hoped. (This does happen.) RTC gives the project an opportunity
to audit for this case before substantial issues develop, while CTR would
not.


On Wed, Dec 10, 2014 at 6:42 PM, Joey Echeverria <jo...@cloudera.com> wrote:

> > though I think it will VERY MUCH impede the speed at which any new
> features / bug fixes can be accomplished.
>
> I don't agree, at least not in the long run. Also, I think a review is
> only required before checking into the main development branch. If
> we're using gitflow, then commits to feature branches should be
> handled by who ever is managing that feature. That can mean doing
> reviews as they come in or waiting until the feature is done and
> reviewing it all at once. But having code reviews saves a lot of time
> in the long run.
>
> Another thing to consider is that over time, committers should be
> spending less time working on new features/fixing bugs and more time
> on growing the community and providing quality code reviews is one of
> the best ways to do that.
>
> On Wed, Dec 10, 2014 at 6:34 PM, Mark Payne <ma...@hotmail.com> wrote:
> > I think the big question, which you brought up, is "what constitutes a
> review?" If another committer looking over the code and signing off is
> sufficient then I'm not horribly opposed, though I think it will VERY MUCH
> impede the speed at which any new features / bug fixes can be accomplished.
> >
> > If we are talking about waiting for several people to vote, then I think
> it's an absolute non-starter and destroys any hope of moving even at a
> fraction of the rate we are used to. This is especially concerning if we
> are waiting for a consensus for something like a trivial bug fix like an
> NPE.
> >
> > Thanks
> > -Mark
> >
> >> On Dec 10, 2014, at 9:20 PM, Joe Witt <jo...@gmail.com> wrote:
> >>
> >> NiFi grew up in a CT[R] environment where the review was very rare and
> so
> >> really we ended up with CTDTFSOR - Commit then deploy then feel sense of
> >> regret.
> >>
> >> So the bad side: We ended up with a lot of avoidable defects where by
> >> avoidable I mean they could have likely been detected in a decent review
> >> effort.
> >>
> >> The good side: We were fast.  Very fast.  New features got out quick
> and if
> >> something was funky we fixed it very fast.  For the vast majority of
> >> mistakes the problem was highly isolated (thanks to our base design
> >> construct of FBP) and rarely caused extremely stressful days.
> >>
> >> On balance though and given the benefits it has to community growth I
> >> personally am very supportive of us adopting RTC immediately provided we
> >> can sort out some key questions:
> >>
> >> - What constitutes a valid review?
> >> This page
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> >> suggests that a review is a consensus approval.  I am very concerned by
> >> that definition if we're talking every commit means we need a vote.  For
> >> the vast majority of commits this just seems to onerous and too time
> >> consuming and frankly to me takes some of the fun out of developing.  If
> >> for us a review is simply that a 'committer' has reviewed the code then
> I
> >> am perfectly happy with this and I am thinking this is in-line with the
> >> model Benson described for his dayjob "'make branch, submit pr, get
> review,
> >> merge'"
> >>
> >> - What is the best tooling/process around this to actually
> conduct/document
> >> the review?
> >> I think
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
> >> does a good job of describing the mechanics of a review/submission
> >> process.  And I'd just assume a patch is as good as a pull request.  I
> >> think even as a good starting point having the JIRA ticket commented on
> by
> >> the reviewer would be good.
> >>
> >> - What are some key things a reviewer should be checking for and
> helping to
> >> enforce?  What are some out of bounds things?
> >>
> >>
> >>
> >> This seems like a really important discussion and something that we
> should
> >> center on sooner than later.  There are ways to nuance this such as RTC
> for
> >> the core and CTR for extensions and so on but I think that just leads to
> >> more confusion.  We should likely pick our poison. I see strong
> benefits in
> >> both directions and so I can deal either way personally.  I see a couple
> >> strong arguments here in this thread already for RTC .
> >>
> >> Anyone willing to argue for CTR?
> >>
> >> Thanks
> >> Joe
> >>
> >>
> >> On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <
> bimargulies@gmail.com>
> >> wrote:
> >>
> >>> It seems to me, and this is purely opinion, that RTC has a lot to be
> said
> >>> for a new project, in terms of getting more people involved, more
> eyeballs,
> >>> and more of a community feeling. My dayjob workflow is 'make branch,
> submit
> >>> pr, get review, merge' and that seems pretty applicable. However, I am
> not
> >>> wearing any magic mentor hat-o-authority.
> >>>
> >>>> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org>
> wrote:
> >>>>
> >>>>> On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
> >>>>>
> >>>>> Benson - thanks for the headsup on the maven plugin.  Seems like
> using
> >>>> them
> >>>>> to their fullest capability and then manually merging to master is
> >>>>> perfectly fine to me.
> >>>>>
> >>>>> Billie
> >>>>> As for CTR i don't think i have a good enough appreciation for the
> >>>>> process/value proposition here.  Curious of other folks views.
> >>>>
> >>>> Both CTR and RTC have their own advantages, so either would be fine (
> >>>> http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
> >>>> retrospect I see my question could be viewed as leaning towards CTR,
> but
> >>> it
> >>>> was just based on an observation that people already seemed to be
> making
> >>>> commits without review.
> >>>>
> >>>>
> >>>>>
> >>>>> It seems reasonable to keep the feature branch relaxed and in that
> >>> sense
> >>>>> what Gilman did today seems fine.  We can get bettter at those
> >>> judgement
> >>>>> calls and documenting the criteria as we go along.
> >>>>>
> >>>>> Thanks
> >>>>> Joe
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
> >>> bimargulies@gmail.com
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> PR's are certainly convenient. There's no much difference, for a
> >>>>> committer,
> >>>>>> between pushing a branch to the official repo and pushing a branch
> to
> >>>>> some
> >>>>>> personal repo on github. The same integration workflow can be used
> >>>> either
> >>>>>> way to close out the PR upon merge.
> >>>>>>
> >>>>>> However, in a CTR project, it seems perhaps excessive to _require_
> >>>>> feature
> >>>>>> branches for small fixes as opposed to just committing them directly
> >>> to
> >>>>>> develop. At day job we do mostly do branch-per-jira, but some people
> >>>>> might
> >>>>>> find that onerous.
> >>>>>>
> >>>>>> Pushing to the official repo leaves more history that someone might
> >>>> find
> >>>>>> interesting some day. Also more clutter; some people are very
> >>> concerned
> >>>>>> about repacking before merging to develop.
> >>>>>>
> >>>>>> Another issue with gitflow is the master branch. The master branch
> is
> >>>>>> supposed to get merged to for releases. The maven-release-plugin
> >>> won't
> >>>> do
> >>>>>> that, and the jgitflow plugin is unsafe. So one option is to 'use
> >>>>> gitflow'
> >>>>>> but not bother with the master versus develop distinction, the other
> >>> is
> >>>>> to
> >>>>>> do manual merges to master at release points.
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>>> Hello
> >>>>>>>
> >>>>>>> So a question on gitflow given that commits are now underway.  When
> >>>>>> working
> >>>>>>> on a feature in a local repo which is a branch off the develop
> >>>>>> branch...do
> >>>>>>> you push the feature branch to the central repo?  This then can be
> >>>>> merged
> >>>>>>> by someone else as a sort of code review/pull process?
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Joe
> >>>>>>>
> >>>>>>> On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> All,
> >>>>>>>>
> >>>>>>>> Now that we have our code up it is important to establish a
> >>> process
> >>>>>>> around
> >>>>>>>> git in particular.  A general consensus in the thread appears to
> >>> be
> >>>>>> that
> >>>>>>>> gitflow workflow is a reasonable option.
> >>>
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> >>>>>>>>
> >>>>>>>> To that end I've added a develop branch off of master from which
> >>>>>> features
> >>>>>>>> can be built.  As we converge toward a release then we'll
> >>>>>>> address/introduce
> >>>>>>>> some of the other aspects of gitflow.
> >>>>>>>>
> >>>>>>>> Please discuss/comment if there are views that we should be
> >>> taking
> >>>>>>> another
> >>>>>>>> path.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Joe
> >>>>>>>>
> >>>>>>>> On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> >>>>>> bimargulies@gmail.com
> >>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> >>>>> wikier@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>> Hi Adam,
> >>>>>>>>>>
> >>>>>>>>>> one remarks about this:
> >>>>>>>>>>
> >>>>>>>>>>> On 28/11/14 18:07, Adam Taft wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Knowing how we work today, if it were me, I would suggest
> >>> using
> >>>>> the
> >>>>>>>>> above
> >>>>>>>>>>> workflow combined with the "forking workflow" to guard access
> >>>> to
> >>>>>> the
> >>>>>>>>>>> production release (master) branches.  A very small subset of
> >>>> the
> >>>>>>>>>>> incubator's commiters should have the ability to merge the
> >>>>>> "develop"
> >>>>>>>>>>> branch
> >>>>>>>>>>> down to a master "release" branch.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Suck workflow is not in place in ASF. On the one hand, the
> >>>> current
> >>>>>> git
> >>>>>>>>>> infrastructure does not provide such branches' management,
> >>> like
> >>>>>>>>>> bitbucket/stash do for instance. On the other hand, and more
> >>>>>>> important,
> >>>>>>>>> a
> >>>>>>>>>> project is not hierarchical organization, but a a meritocratic
> >>>>> one.
> >>>>>>>>>>
> >>>>>>>>>> I recommend you this blog post in case you want to read a bit
> >>>>> more:
> >>> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> >>>>>>>>>>
> >>>>>>>>>> If someone has permissions to do (i.e., he is a committer), he
> >>>> can
> >>>>>> do
> >>>>>>>>> it,
> >>>>>>>>>> simple The tool provide you instruments to revert those
> >>> changes
> >>>> in
> >>>>>>> case
> >>>>>>>>> on
> >>>>>>>>>> involuntary errors.
> >>>>>>>>>>
> >>>>>>>>>>> It would be ideal to have someone who
> >>>>>>>>>>> is NOT performing the majority of changes on the "develop"
> >>>> branch
> >>>>>>> take
> >>>>>>>>>>> this
> >>>>>>>>>>> role to coordinate releases, ensure minimal coding standards,
> >>>> run
> >>>>>>>>> through
> >>>>>>>>>>> unit and integration tests, before signing off on the release
> >>>> and
> >>>>>>>>> issuing
> >>>>>>>>>>> the release artifacts.
> >>>>>>>>>
> >>>>>>>>> You seem to be imagining an individual with a job which is
> >>> shared
> >>>> in
> >>>>>>>>> by the community. In healthy communities, a release happens when
> >>>>>>>>> there's a consensus to have a release. There is no person who
> >>>>> 'ensures
> >>>>>>>>> minimal coding standards', that's everyone watching commits.
> >>>> There's
> >>>>>>>>> no one 'running unit and integration tests' because (a) every
> >>>>>>>>> committer does this before every commit, (b) Jenkins does it,
> >>> (c)
> >>>>> the
> >>>>>>>>> release process does it. (d) there's no signing off on a
> >>> release.
> >>>>> The
> >>>>>>>>> RM puts it up for a vote, and PMC members vote.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Release comes after that. The release manager is responsible
> >>> on
> >>>>>>>>> creating a
> >>>>>>>>>> proper release, which must include a code release and should
> >>>>> include
> >>>>>>>>>> binaries too. Each artifact release must be signed.
> >>> Demonstrate
> >>>>> your
> >>>>>>>>> ability
> >>>>>>>>>> as a project to produce releases is one of the goals of the
> >>>>>>> incubation.
> >>>>>>>>> But
> >>>>>>>>>> we are not yet there, step by step.
> >>>>>>>>>>
> >>>>>>>>>> Hope that helps.
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Sergio Fernández
> >>>>>>>>>> Partner Technology Manager
> >>>>>>>>>> Redlink GmbH
> >>>>>>>>>> m: +43 660 2747 925
> >>>>>>>>>> e: sergio.fernandez@redlink.co
> >>>>>>>>>> w: http://redlink.co
> >>>
>
>
>
> --
> Joey Echeverria
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: git workflow for nifi

Posted by Tony Kurc <tr...@gmail.com>.

> I don't agree, at least not in the long run.

I'm with Joey. Also, CTR doesn't imply "no review". I actually think it
makes things messier if changes need to be backed out.




On Wed, Dec 10, 2014 at 9:42 PM, Joey Echeverria <jo...@cloudera.com> wrote:

> > though I think it will VERY MUCH impede the speed at which any new
> features / bug fixes can be accomplished.
>
> I don't agree, at least not in the long run. Also, I think a review is
> only required before checking into the main development branch. If
> we're using gitflow, then commits to feature branches should be
> handled by who ever is managing that feature. That can mean doing
> reviews as they come in or waiting until the feature is done and
> reviewing it all at once. But having code reviews saves a lot of time
> in the long run.
>
> Another thing to consider is that over time, committers should be
> spending less time working on new features/fixing bugs and more time
> on growing the community and providing quality code reviews is one of
> the best ways to do that.
>
> On Wed, Dec 10, 2014 at 6:34 PM, Mark Payne <ma...@hotmail.com> wrote:
> > I think the big question, which you brought up, is "what constitutes a
> review?" If another committer looking over the code and signing off is
> sufficient then I'm not horribly opposed, though I think it will VERY MUCH
> impede the speed at which any new features / bug fixes can be accomplished.
> >
> > If we are talking about waiting for several people to vote, then I think
> it's an absolute non-starter and destroys any hope of moving even at a
> fraction of the rate we are used to. This is especially concerning if we
> are waiting for a consensus for something like a trivial bug fix like an
> NPE.
> >
> > Thanks
> > -Mark
> >
> >> On Dec 10, 2014, at 9:20 PM, Joe Witt <jo...@gmail.com> wrote:
> >>
> >> NiFi grew up in a CT[R] environment where the review was very rare and
> so
> >> really we ended up with CTDTFSOR - Commit then deploy then feel sense of
> >> regret.
> >>
> >> So the bad side: We ended up with a lot of avoidable defects where by
> >> avoidable I mean they could have likely been detected in a decent review
> >> effort.
> >>
> >> The good side: We were fast.  Very fast.  New features got out quick
> and if
> >> something was funky we fixed it very fast.  For the vast majority of
> >> mistakes the problem was highly isolated (thanks to our base design
> >> construct of FBP) and rarely caused extremely stressful days.
> >>
> >> On balance though and given the benefits it has to community growth I
> >> personally am very supportive of us adopting RTC immediately provided we
> >> can sort out some key questions:
> >>
> >> - What constitutes a valid review?
> >> This page
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> >> suggests that a review is a consensus approval.  I am very concerned by
> >> that definition if we're talking every commit means we need a vote.  For
> >> the vast majority of commits this just seems to onerous and too time
> >> consuming and frankly to me takes some of the fun out of developing.  If
> >> for us a review is simply that a 'committer' has reviewed the code then
> I
> >> am perfectly happy with this and I am thinking this is in-line with the
> >> model Benson described for his dayjob "'make branch, submit pr, get
> review,
> >> merge'"
> >>
> >> - What is the best tooling/process around this to actually
> conduct/document
> >> the review?
> >> I think
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
> >> does a good job of describing the mechanics of a review/submission
> >> process.  And I'd just assume a patch is as good as a pull request.  I
> >> think even as a good starting point having the JIRA ticket commented on
> by
> >> the reviewer would be good.
> >>
> >> - What are some key things a reviewer should be checking for and
> helping to
> >> enforce?  What are some out of bounds things?
> >>
> >>
> >>
> >> This seems like a really important discussion and something that we
> should
> >> center on sooner than later.  There are ways to nuance this such as RTC
> for
> >> the core and CTR for extensions and so on but I think that just leads to
> >> more confusion.  We should likely pick our poison. I see strong
> benefits in
> >> both directions and so I can deal either way personally.  I see a couple
> >> strong arguments here in this thread already for RTC .
> >>
> >> Anyone willing to argue for CTR?
> >>
> >> Thanks
> >> Joe
> >>
> >>
> >> On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <
> bimargulies@gmail.com>
> >> wrote:
> >>
> >>> It seems to me, and this is purely opinion, that RTC has a lot to be
> said
> >>> for a new project, in terms of getting more people involved, more
> eyeballs,
> >>> and more of a community feeling. My dayjob workflow is 'make branch,
> submit
> >>> pr, get review, merge' and that seems pretty applicable. However, I am
> not
> >>> wearing any magic mentor hat-o-authority.
> >>>
> >>>> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org>
> wrote:
> >>>>
> >>>>> On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
> >>>>>
> >>>>> Benson - thanks for the headsup on the maven plugin.  Seems like
> using
> >>>> them
> >>>>> to their fullest capability and then manually merging to master is
> >>>>> perfectly fine to me.
> >>>>>
> >>>>> Billie
> >>>>> As for CTR i don't think i have a good enough appreciation for the
> >>>>> process/value proposition here.  Curious of other folks views.
> >>>>
> >>>> Both CTR and RTC have their own advantages, so either would be fine (
> >>>> http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
> >>>> retrospect I see my question could be viewed as leaning towards CTR,
> but
> >>> it
> >>>> was just based on an observation that people already seemed to be
> making
> >>>> commits without review.
> >>>>
> >>>>
> >>>>>
> >>>>> It seems reasonable to keep the feature branch relaxed and in that
> >>> sense
> >>>>> what Gilman did today seems fine.  We can get bettter at those
> >>> judgement
> >>>>> calls and documenting the criteria as we go along.
> >>>>>
> >>>>> Thanks
> >>>>> Joe
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
> >>> bimargulies@gmail.com
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> PR's are certainly convenient. There's no much difference, for a
> >>>>> committer,
> >>>>>> between pushing a branch to the official repo and pushing a branch
> to
> >>>>> some
> >>>>>> personal repo on github. The same integration workflow can be used
> >>>> either
> >>>>>> way to close out the PR upon merge.
> >>>>>>
> >>>>>> However, in a CTR project, it seems perhaps excessive to _require_
> >>>>> feature
> >>>>>> branches for small fixes as opposed to just committing them directly
> >>> to
> >>>>>> develop. At day job we do mostly do branch-per-jira, but some people
> >>>>> might
> >>>>>> find that onerous.
> >>>>>>
> >>>>>> Pushing to the official repo leaves more history that someone might
> >>>> find
> >>>>>> interesting some day. Also more clutter; some people are very
> >>> concerned
> >>>>>> about repacking before merging to develop.
> >>>>>>
> >>>>>> Another issue with gitflow is the master branch. The master branch
> is
> >>>>>> supposed to get merged to for releases. The maven-release-plugin
> >>> won't
> >>>> do
> >>>>>> that, and the jgitflow plugin is unsafe. So one option is to 'use
> >>>>> gitflow'
> >>>>>> but not bother with the master versus develop distinction, the other
> >>> is
> >>>>> to
> >>>>>> do manual merges to master at release points.
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>>> Hello
> >>>>>>>
> >>>>>>> So a question on gitflow given that commits are now underway.  When
> >>>>>> working
> >>>>>>> on a feature in a local repo which is a branch off the develop
> >>>>>> branch...do
> >>>>>>> you push the feature branch to the central repo?  This then can be
> >>>>> merged
> >>>>>>> by someone else as a sort of code review/pull process?
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Joe
> >>>>>>>
> >>>>>>> On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> All,
> >>>>>>>>
> >>>>>>>> Now that we have our code up it is important to establish a
> >>> process
> >>>>>>> around
> >>>>>>>> git in particular.  A general consensus in the thread appears to
> >>> be
> >>>>>> that
> >>>>>>>> gitflow workflow is a reasonable option.
> >>>
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> >>>>>>>>
> >>>>>>>> To that end I've added a develop branch off of master from which
> >>>>>> features
> >>>>>>>> can be built.  As we converge toward a release then we'll
> >>>>>>> address/introduce
> >>>>>>>> some of the other aspects of gitflow.
> >>>>>>>>
> >>>>>>>> Please discuss/comment if there are views that we should be
> >>> taking
> >>>>>>> another
> >>>>>>>> path.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Joe
> >>>>>>>>
> >>>>>>>> On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> >>>>>> bimargulies@gmail.com
> >>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> >>>>> wikier@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>> Hi Adam,
> >>>>>>>>>>
> >>>>>>>>>> one remarks about this:
> >>>>>>>>>>
> >>>>>>>>>>> On 28/11/14 18:07, Adam Taft wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Knowing how we work today, if it were me, I would suggest
> >>> using
> >>>>> the
> >>>>>>>>> above
> >>>>>>>>>>> workflow combined with the "forking workflow" to guard access
> >>>> to
> >>>>>> the
> >>>>>>>>>>> production release (master) branches.  A very small subset of
> >>>> the
> >>>>>>>>>>> incubator's commiters should have the ability to merge the
> >>>>>> "develop"
> >>>>>>>>>>> branch
> >>>>>>>>>>> down to a master "release" branch.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Suck workflow is not in place in ASF. On the one hand, the
> >>>> current
> >>>>>> git
> >>>>>>>>>> infrastructure does not provide such branches' management,
> >>> like
> >>>>>>>>>> bitbucket/stash do for instance. On the other hand, and more
> >>>>>>> important,
> >>>>>>>>> a
> >>>>>>>>>> project is not hierarchical organization, but a a meritocratic
> >>>>> one.
> >>>>>>>>>>
> >>>>>>>>>> I recommend you this blog post in case you want to read a bit
> >>>>> more:
> >>> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> >>>>>>>>>>
> >>>>>>>>>> If someone has permissions to do (i.e., he is a committer), he
> >>>> can
> >>>>>> do
> >>>>>>>>> it,
> >>>>>>>>>> simple The tool provide you instruments to revert those
> >>> changes
> >>>> in
> >>>>>>> case
> >>>>>>>>> on
> >>>>>>>>>> involuntary errors.
> >>>>>>>>>>
> >>>>>>>>>>> It would be ideal to have someone who
> >>>>>>>>>>> is NOT performing the majority of changes on the "develop"
> >>>> branch
> >>>>>>> take
> >>>>>>>>>>> this
> >>>>>>>>>>> role to coordinate releases, ensure minimal coding standards,
> >>>> run
> >>>>>>>>> through
> >>>>>>>>>>> unit and integration tests, before signing off on the release
> >>>> and
> >>>>>>>>> issuing
> >>>>>>>>>>> the release artifacts.
> >>>>>>>>>
> >>>>>>>>> You seem to be imagining an individual with a job which is
> >>> shared
> >>>> in
> >>>>>>>>> by the community. In healthy communities, a release happens when
> >>>>>>>>> there's a consensus to have a release. There is no person who
> >>>>> 'ensures
> >>>>>>>>> minimal coding standards', that's everyone watching commits.
> >>>> There's
> >>>>>>>>> no one 'running unit and integration tests' because (a) every
> >>>>>>>>> committer does this before every commit, (b) Jenkins does it,
> >>> (c)
> >>>>> the
> >>>>>>>>> release process does it. (d) there's no signing off on a
> >>> release.
> >>>>> The
> >>>>>>>>> RM puts it up for a vote, and PMC members vote.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Release comes after that. The release manager is responsible
> >>> on
> >>>>>>>>> creating a
> >>>>>>>>>> proper release, which must include a code release and should
> >>>>> include
> >>>>>>>>>> binaries too. Each artifact release must be signed.
> >>> Demonstrate
> >>>>> your
> >>>>>>>>> ability
> >>>>>>>>>> as a project to produce releases is one of the goals of the
> >>>>>>> incubation.
> >>>>>>>>> But
> >>>>>>>>>> we are not yet there, step by step.
> >>>>>>>>>>
> >>>>>>>>>> Hope that helps.
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Sergio Fernández
> >>>>>>>>>> Partner Technology Manager
> >>>>>>>>>> Redlink GmbH
> >>>>>>>>>> m: +43 660 2747 925
> >>>>>>>>>> e: sergio.fernandez@redlink.co
> >>>>>>>>>> w: http://redlink.co
> >>>
>
>
>
> --
> Joey Echeverria
>

Re: git workflow for nifi

Posted by Sean Busbey <bu...@cloudera.com>.

On Wed, Dec 10, 2014 at 8:42 PM, Joey Echeverria <jo...@cloudera.com> wrote:

> > though I think it will VERY MUCH impede the speed at which any new
> features / bug fixes can be accomplished.
>
> I don't agree, at least not in the long run. Also, I think a review is
> only required before checking into the main development branch. If
> we're using gitflow, then commits to feature branches should be
> handled by who ever is managing that feature. That can mean doing
> reviews as they come in or waiting until the feature is done and
> reviewing it all at once. But having code reviews saves a lot of time
> in the long run.
>
>
Joey's sentiment lines up very well with my experience to date. CtR "feels"
faster, but in the long run RtC results in better throughput for stable
releases because code quality converges much faster. That quality means
less time spent on support and fixes later. When combined with robust
automated testing it makes it very easy to maintain rigor on a release
cycle.

> Another thing to consider is that over time, committers should be
> spending less time working on new features/fixing bugs and more time
> on growing the community and providing quality code reviews is one of
> the best ways to do that.
>
>
This is also an advantage that often is under appreciated about RtC. Having
regular reviews means everyone gets more practiced at both giving and
receiving them. That also makes the community better at recognizing review
quality and gives you valuable information about how well a contributor
interacts with the overall community.  It really helps to distinguish among
contributors who make good contributors because they are scratching itches
they have and those that will make good committers because they're thinking
in terms of the overall project.

As a future PMC your two big jobs will be ensuring regular quality software
releases and a healthy community. Hopefully the above makes it obvious that
I think RtC helps both of those endeavors.

A while back there was a thread about PMC vs committer status. My apologies
for not having kept up on that discussion. I believe the last bit I saw was
Joe stating that his intuition was to keep them separate. I think that's a
very good idea, both because it gives the community more information about
people's fit for the role and it provides a more distinguished advancement
path in the project. Having the rigor of RtC also provides more information
about PMC suitability since you can see how a committer focuses over time
on strategic issues like community vs tactical issues like a specific patch.

-- 
Sean

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

Folks,

So it appears as though folks are either neutral or in favor of RTC and
Gitflow.  Lets just go ahead and ensure we start making it happen then.
Perhaps for now a simple approach of before pushing to the develop branch
you have another committer review your code.  A pull request or patch or
some agreed upon approach should be fine.  The reviewer can simply comment
or +1 on the relevant Jira ticket.  Either the reviewer or the contributor
depending on the circumstance then can ensure the code gets merged.  As we
mature and feel our way through this we can establish a more documented
review process.  It would be good for folks to document the things to look
for in a review.  That will walk us toward code style issues/preferences if
we have them and so on.  Key thing is not to forget what some folks have
mentioned here which is the review process is about mentoring and building
up others just as much as it is about ensuring code quality.

Thanks for all the great comments and feedback.  It is really exciting to
see the initial seeds of community growth.

Thanks
Joe

On Thu, Dec 11, 2014 at 8:19 AM, Joe Witt <jo...@gmail.com> wrote:

> Mark,
>
> I can appreciate your skepticism and view here and am glad you're willing
> to consider this as being able to make either work.
>
> One thing to remember (and this is me talking to all of us more than it is
> at - you)....
>
> The reviews will be by committers and pmc members and will be of any
> contribution regardless of standing in the project.  This creates a level
> playing field of contribution but a healthy model of curating contributions
> to a high level of quality while at the same time helping to both train and
> identify new committers.  That is fantastic.  If we have folks without any
> experience doing reviews then we as a community/project have done something
> fundamentally wrong.  Now, there are perhaps parts of the application which
> require a certain level of subject matter expertise such that an in-depth
> peer review may be tough to come by.  Those will be slower.  But then
> again...those are likely then the most critical to build depth on.
>
> If CTR and RTC are a spectrum where CTR is -1 and RTC is +1 I really hope
> we end up at  0.5.
>
> Thanks
> Joe
>
>
>
> On Thu, Dec 11, 2014 at 8:02 AM, Mark Payne <ma...@hotmail.com> wrote:
>
>> So I'll admit that my experience in this area has been terrible is may be
>> very different from what I will experience here. "Code Review" in my world
>> has often meant "let this new developer without any experience review your
>> code and then you can spend 3 days explaining each line to him." And this
>> will absolutely cripple us. I don't think this is what we're talking about
>> here, so I'll retract that statement :)
>> So I'll remain with Tony in the middle and give no +1 to RTC or CTR.
>> Thanks-Mark
>>
>> > Date: Wed, 10 Dec 2014 18:42:22 -0800
>> > Subject: Re: git workflow for nifi
>> > From: joey@cloudera.com
>> > To: dev@nifi.incubator.apache.org
>> >
>> > > though I think it will VERY MUCH impede the speed at which any new
>> features / bug fixes can be accomplished.
>> >
>> > I don't agree, at least not in the long run. Also, I think a review is
>> > only required before checking into the main development branch. If
>> > we're using gitflow, then commits to feature branches should be
>> > handled by who ever is managing that feature. That can mean doing
>> > reviews as they come in or waiting until the feature is done and
>> > reviewing it all at once. But having code reviews saves a lot of time
>> > in the long run.
>> >
>> > Another thing to consider is that over time, committers should be
>> > spending less time working on new features/fixing bugs and more time
>> > on growing the community and providing quality code reviews is one of
>> > the best ways to do that.
>> >
>> > On Wed, Dec 10, 2014 at 6:34 PM, Mark Payne <ma...@hotmail.com>
>> wrote:
>> > > I think the big question, which you brought up, is "what constitutes
>> a review?" If another committer looking over the code and signing off is
>> sufficient then I'm not horribly opposed, though I think it will VERY MUCH
>> impede the speed at which any new features / bug fixes can be accomplished.
>> > >
>> > > If we are talking about waiting for several people to vote, then I
>> think it's an absolute non-starter and destroys any hope of moving even at
>> a fraction of the rate we are used to. This is especially concerning if we
>> are waiting for a consensus for something like a trivial bug fix like an
>> NPE.
>> > >
>> > > Thanks
>> > > -Mark
>> > >
>> > >> On Dec 10, 2014, at 9:20 PM, Joe Witt <jo...@gmail.com> wrote:
>> > >>
>> > >> NiFi grew up in a CT[R] environment where the review was very rare
>> and so
>> > >> really we ended up with CTDTFSOR - Commit then deploy then feel
>> sense of
>> > >> regret.
>> > >>
>> > >> So the bad side: We ended up with a lot of avoidable defects where by
>> > >> avoidable I mean they could have likely been detected in a decent
>> review
>> > >> effort.
>> > >>
>> > >> The good side: We were fast.  Very fast.  New features got out quick
>> and if
>> > >> something was funky we fixed it very fast.  For the vast majority of
>> > >> mistakes the problem was highly isolated (thanks to our base design
>> > >> construct of FBP) and rarely caused extremely stressful days.
>> > >>
>> > >> On balance though and given the benefits it has to community growth I
>> > >> personally am very supportive of us adopting RTC immediately
>> provided we
>> > >> can sort out some key questions:
>> > >>
>> > >> - What constitutes a valid review?
>> > >> This page
>> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
>> > >> suggests that a review is a consensus approval.  I am very concerned
>> by
>> > >> that definition if we're talking every commit means we need a vote.
>> For
>> > >> the vast majority of commits this just seems to onerous and too time
>> > >> consuming and frankly to me takes some of the fun out of
>> developing.  If
>> > >> for us a review is simply that a 'committer' has reviewed the code
>> then I
>> > >> am perfectly happy with this and I am thinking this is in-line with
>> the
>> > >> model Benson described for his dayjob "'make branch, submit pr, get
>> review,
>> > >> merge'"
>> > >>
>> > >> - What is the best tooling/process around this to actually
>> conduct/document
>> > >> the review?
>> > >> I think
>> > >>
>> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
>> > >> does a good job of describing the mechanics of a review/submission
>> > >> process.  And I'd just assume a patch is as good as a pull request.
>> I
>> > >> think even as a good starting point having the JIRA ticket commented
>> on by
>> > >> the reviewer would be good.
>> > >>
>> > >> - What are some key things a reviewer should be checking for and
>> helping to
>> > >> enforce?  What are some out of bounds things?
>> > >>
>> > >>
>> > >>
>> > >> This seems like a really important discussion and something that we
>> should
>> > >> center on sooner than later.  There are ways to nuance this such as
>> RTC for
>> > >> the core and CTR for extensions and so on but I think that just
>> leads to
>> > >> more confusion.  We should likely pick our poison. I see strong
>> benefits in
>> > >> both directions and so I can deal either way personally.  I see a
>> couple
>> > >> strong arguments here in this thread already for RTC .
>> > >>
>> > >> Anyone willing to argue for CTR?
>> > >>
>> > >> Thanks
>> > >> Joe
>> > >>
>> > >>
>> > >> On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <
>> bimargulies@gmail.com>
>> > >> wrote:
>> > >>
>> > >>> It seems to me, and this is purely opinion, that RTC has a lot to
>> be said
>> > >>> for a new project, in terms of getting more people involved, more
>> eyeballs,
>> > >>> and more of a community feeling. My dayjob workflow is 'make
>> branch, submit
>> > >>> pr, get review, merge' and that seems pretty applicable. However, I
>> am not
>> > >>> wearing any magic mentor hat-o-authority.
>> > >>>
>> > >>>> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org>
>> wrote:
>> > >>>>
>> > >>>>> On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com>
>> wrote:
>> > >>>>>
>> > >>>>> Benson - thanks for the headsup on the maven plugin.  Seems like
>> using
>> > >>>> them
>> > >>>>> to their fullest capability and then manually merging to master is
>> > >>>>> perfectly fine to me.
>> > >>>>>
>> > >>>>> Billie
>> > >>>>> As for CTR i don't think i have a good enough appreciation for the
>> > >>>>> process/value proposition here.  Curious of other folks views.
>> > >>>>
>> > >>>> Both CTR and RTC have their own advantages, so either would be
>> fine (
>> > >>>> http://www.apache.org/foundation/glossary.html#CommitThenReview).
>> In
>> > >>>> retrospect I see my question could be viewed as leaning towards
>> CTR, but
>> > >>> it
>> > >>>> was just based on an observation that people already seemed to be
>> making
>> > >>>> commits without review.
>> > >>>>
>> > >>>>
>> > >>>>>
>> > >>>>> It seems reasonable to keep the feature branch relaxed and in that
>> > >>> sense
>> > >>>>> what Gilman did today seems fine.  We can get bettter at those
>> > >>> judgement
>> > >>>>> calls and documenting the criteria as we go along.
>> > >>>>>
>> > >>>>> Thanks
>> > >>>>> Joe
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
>> > >>> bimargulies@gmail.com
>> > >>>>>
>> > >>>>> wrote:
>> > >>>>>
>> > >>>>>> PR's are certainly convenient. There's no much difference, for a
>> > >>>>> committer,
>> > >>>>>> between pushing a branch to the official repo and pushing a
>> branch to
>> > >>>>> some
>> > >>>>>> personal repo on github. The same integration workflow can be
>> used
>> > >>>> either
>> > >>>>>> way to close out the PR upon merge.
>> > >>>>>>
>> > >>>>>> However, in a CTR project, it seems perhaps excessive to
>> _require_
>> > >>>>> feature
>> > >>>>>> branches for small fixes as opposed to just committing them
>> directly
>> > >>> to
>> > >>>>>> develop. At day job we do mostly do branch-per-jira, but some
>> people
>> > >>>>> might
>> > >>>>>> find that onerous.
>> > >>>>>>
>> > >>>>>> Pushing to the official repo leaves more history that someone
>> might
>> > >>>> find
>> > >>>>>> interesting some day. Also more clutter; some people are very
>> > >>> concerned
>> > >>>>>> about repacking before merging to develop.
>> > >>>>>>
>> > >>>>>> Another issue with gitflow is the master branch. The master
>> branch is
>> > >>>>>> supposed to get merged to for releases. The maven-release-plugin
>> > >>> won't
>> > >>>> do
>> > >>>>>> that, and the jgitflow plugin is unsafe. So one option is to 'use
>> > >>>>> gitflow'
>> > >>>>>> but not bother with the master versus develop distinction, the
>> other
>> > >>> is
>> > >>>>> to
>> > >>>>>> do manual merges to master at release points.
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
>> > >>> wrote:
>> > >>>>>>
>> > >>>>>>> Hello
>> > >>>>>>>
>> > >>>>>>> So a question on gitflow given that commits are now underway.
>> When
>> > >>>>>> working
>> > >>>>>>> on a feature in a local repo which is a branch off the develop
>> > >>>>>> branch...do
>> > >>>>>>> you push the feature branch to the central repo?  This then can
>> be
>> > >>>>> merged
>> > >>>>>>> by someone else as a sort of code review/pull process?
>> > >>>>>>>
>> > >>>>>>> Thanks
>> > >>>>>>> Joe
>> > >>>>>>>
>> > >>>>>>> On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
>> > >>>> wrote:
>> > >>>>>>>
>> > >>>>>>>> All,
>> > >>>>>>>>
>> > >>>>>>>> Now that we have our code up it is important to establish a
>> > >>> process
>> > >>>>>>> around
>> > >>>>>>>> git in particular.  A general consensus in the thread appears
>> to
>> > >>> be
>> > >>>>>> that
>> > >>>>>>>> gitflow workflow is a reasonable option.
>> > >>>
>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>> > >>>>>>>>
>> > >>>>>>>> To that end I've added a develop branch off of master from
>> which
>> > >>>>>> features
>> > >>>>>>>> can be built.  As we converge toward a release then we'll
>> > >>>>>>> address/introduce
>> > >>>>>>>> some of the other aspects of gitflow.
>> > >>>>>>>>
>> > >>>>>>>> Please discuss/comment if there are views that we should be
>> > >>> taking
>> > >>>>>>> another
>> > >>>>>>>> path.
>> > >>>>>>>>
>> > >>>>>>>> Thanks
>> > >>>>>>>> Joe
>> > >>>>>>>>
>> > >>>>>>>> On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
>> > >>>>>> bimargulies@gmail.com
>> > >>>>>>>>
>> > >>>>>>>> wrote:
>> > >>>>>>>>
>> > >>>>>>>>> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
>> > >>>>> wikier@apache.org>
>> > >>>>>>>>> wrote:
>> > >>>>>>>>>> Hi Adam,
>> > >>>>>>>>>>
>> > >>>>>>>>>> one remarks about this:
>> > >>>>>>>>>>
>> > >>>>>>>>>>> On 28/11/14 18:07, Adam Taft wrote:
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Knowing how we work today, if it were me, I would suggest
>> > >>> using
>> > >>>>> the
>> > >>>>>>>>> above
>> > >>>>>>>>>>> workflow combined with the "forking workflow" to guard
>> access
>> > >>>> to
>> > >>>>>> the
>> > >>>>>>>>>>> production release (master) branches.  A very small subset
>> of
>> > >>>> the
>> > >>>>>>>>>>> incubator's commiters should have the ability to merge the
>> > >>>>>> "develop"
>> > >>>>>>>>>>> branch
>> > >>>>>>>>>>> down to a master "release" branch.
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> Suck workflow is not in place in ASF. On the one hand, the
>> > >>>> current
>> > >>>>>> git
>> > >>>>>>>>>> infrastructure does not provide such branches' management,
>> > >>> like
>> > >>>>>>>>>> bitbucket/stash do for instance. On the other hand, and more
>> > >>>>>>> important,
>> > >>>>>>>>> a
>> > >>>>>>>>>> project is not hierarchical organization, but a a
>> meritocratic
>> > >>>>> one.
>> > >>>>>>>>>>
>> > >>>>>>>>>> I recommend you this blog post in case you want to read a bit
>> > >>>>> more:
>> > >>> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
>> > >>>>>>>>>>
>> > >>>>>>>>>> If someone has permissions to do (i.e., he is a committer),
>> he
>> > >>>> can
>> > >>>>>> do
>> > >>>>>>>>> it,
>> > >>>>>>>>>> simple The tool provide you instruments to revert those
>> > >>> changes
>> > >>>> in
>> > >>>>>>> case
>> > >>>>>>>>> on
>> > >>>>>>>>>> involuntary errors.
>> > >>>>>>>>>>
>> > >>>>>>>>>>> It would be ideal to have someone who
>> > >>>>>>>>>>> is NOT performing the majority of changes on the "develop"
>> > >>>> branch
>> > >>>>>>> take
>> > >>>>>>>>>>> this
>> > >>>>>>>>>>> role to coordinate releases, ensure minimal coding
>> standards,
>> > >>>> run
>> > >>>>>>>>> through
>> > >>>>>>>>>>> unit and integration tests, before signing off on the
>> release
>> > >>>> and
>> > >>>>>>>>> issuing
>> > >>>>>>>>>>> the release artifacts.
>> > >>>>>>>>>
>> > >>>>>>>>> You seem to be imagining an individual with a job which is
>> > >>> shared
>> > >>>> in
>> > >>>>>>>>> by the community. In healthy communities, a release happens
>> when
>> > >>>>>>>>> there's a consensus to have a release. There is no person who
>> > >>>>> 'ensures
>> > >>>>>>>>> minimal coding standards', that's everyone watching commits.
>> > >>>> There's
>> > >>>>>>>>> no one 'running unit and integration tests' because (a) every
>> > >>>>>>>>> committer does this before every commit, (b) Jenkins does it,
>> > >>> (c)
>> > >>>>> the
>> > >>>>>>>>> release process does it. (d) there's no signing off on a
>> > >>> release.
>> > >>>>> The
>> > >>>>>>>>> RM puts it up for a vote, and PMC members vote.
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> Release comes after that. The release manager is responsible
>> > >>> on
>> > >>>>>>>>> creating a
>> > >>>>>>>>>> proper release, which must include a code release and should
>> > >>>>> include
>> > >>>>>>>>>> binaries too. Each artifact release must be signed.
>> > >>> Demonstrate
>> > >>>>> your
>> > >>>>>>>>> ability
>> > >>>>>>>>>> as a project to produce releases is one of the goals of the
>> > >>>>>>> incubation.
>> > >>>>>>>>> But
>> > >>>>>>>>>> we are not yet there, step by step.
>> > >>>>>>>>>>
>> > >>>>>>>>>> Hope that helps.
>> > >>>>>>>>>>
>> > >>>>>>>>>> Cheers,
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> --
>> > >>>>>>>>>> Sergio Fernández
>> > >>>>>>>>>> Partner Technology Manager
>> > >>>>>>>>>> Redlink GmbH
>> > >>>>>>>>>> m: +43 660 2747 925
>> > >>>>>>>>>> e: sergio.fernandez@redlink.co
>> > >>>>>>>>>> w: http://redlink.co
>> > >>>
>> >
>> >
>> >
>> > --
>> > Joey Echeverria
>>
>>
>
>

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

Mark,

I can appreciate your skepticism and view here and am glad you're willing
to consider this as being able to make either work.

One thing to remember (and this is me talking to all of us more than it is
at - you)....

The reviews will be by committers and pmc members and will be of any
contribution regardless of standing in the project.  This creates a level
playing field of contribution but a healthy model of curating contributions
to a high level of quality while at the same time helping to both train and
identify new committers.  That is fantastic.  If we have folks without any
experience doing reviews then we as a community/project have done something
fundamentally wrong.  Now, there are perhaps parts of the application which
require a certain level of subject matter expertise such that an in-depth
peer review may be tough to come by.  Those will be slower.  But then
again...those are likely then the most critical to build depth on.

If CTR and RTC are a spectrum where CTR is -1 and RTC is +1 I really hope
we end up at  0.5.

Thanks
Joe



On Thu, Dec 11, 2014 at 8:02 AM, Mark Payne <ma...@hotmail.com> wrote:

> So I'll admit that my experience in this area has been terrible is may be
> very different from what I will experience here. "Code Review" in my world
> has often meant "let this new developer without any experience review your
> code and then you can spend 3 days explaining each line to him." And this
> will absolutely cripple us. I don't think this is what we're talking about
> here, so I'll retract that statement :)
> So I'll remain with Tony in the middle and give no +1 to RTC or CTR.
> Thanks-Mark
>
> > Date: Wed, 10 Dec 2014 18:42:22 -0800
> > Subject: Re: git workflow for nifi
> > From: joey@cloudera.com
> > To: dev@nifi.incubator.apache.org
> >
> > > though I think it will VERY MUCH impede the speed at which any new
> features / bug fixes can be accomplished.
> >
> > I don't agree, at least not in the long run. Also, I think a review is
> > only required before checking into the main development branch. If
> > we're using gitflow, then commits to feature branches should be
> > handled by who ever is managing that feature. That can mean doing
> > reviews as they come in or waiting until the feature is done and
> > reviewing it all at once. But having code reviews saves a lot of time
> > in the long run.
> >
> > Another thing to consider is that over time, committers should be
> > spending less time working on new features/fixing bugs and more time
> > on growing the community and providing quality code reviews is one of
> > the best ways to do that.
> >
> > On Wed, Dec 10, 2014 at 6:34 PM, Mark Payne <ma...@hotmail.com>
> wrote:
> > > I think the big question, which you brought up, is "what constitutes a
> review?" If another committer looking over the code and signing off is
> sufficient then I'm not horribly opposed, though I think it will VERY MUCH
> impede the speed at which any new features / bug fixes can be accomplished.
> > >
> > > If we are talking about waiting for several people to vote, then I
> think it's an absolute non-starter and destroys any hope of moving even at
> a fraction of the rate we are used to. This is especially concerning if we
> are waiting for a consensus for something like a trivial bug fix like an
> NPE.
> > >
> > > Thanks
> > > -Mark
> > >
> > >> On Dec 10, 2014, at 9:20 PM, Joe Witt <jo...@gmail.com> wrote:
> > >>
> > >> NiFi grew up in a CT[R] environment where the review was very rare
> and so
> > >> really we ended up with CTDTFSOR - Commit then deploy then feel sense
> of
> > >> regret.
> > >>
> > >> So the bad side: We ended up with a lot of avoidable defects where by
> > >> avoidable I mean they could have likely been detected in a decent
> review
> > >> effort.
> > >>
> > >> The good side: We were fast.  Very fast.  New features got out quick
> and if
> > >> something was funky we fixed it very fast.  For the vast majority of
> > >> mistakes the problem was highly isolated (thanks to our base design
> > >> construct of FBP) and rarely caused extremely stressful days.
> > >>
> > >> On balance though and given the benefits it has to community growth I
> > >> personally am very supportive of us adopting RTC immediately provided
> we
> > >> can sort out some key questions:
> > >>
> > >> - What constitutes a valid review?
> > >> This page
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > >> suggests that a review is a consensus approval.  I am very concerned
> by
> > >> that definition if we're talking every commit means we need a vote.
> For
> > >> the vast majority of commits this just seems to onerous and too time
> > >> consuming and frankly to me takes some of the fun out of developing.
> If
> > >> for us a review is simply that a 'committer' has reviewed the code
> then I
> > >> am perfectly happy with this and I am thinking this is in-line with
> the
> > >> model Benson described for his dayjob "'make branch, submit pr, get
> review,
> > >> merge'"
> > >>
> > >> - What is the best tooling/process around this to actually
> conduct/document
> > >> the review?
> > >> I think
> > >>
> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
> > >> does a good job of describing the mechanics of a review/submission
> > >> process.  And I'd just assume a patch is as good as a pull request.  I
> > >> think even as a good starting point having the JIRA ticket commented
> on by
> > >> the reviewer would be good.
> > >>
> > >> - What are some key things a reviewer should be checking for and
> helping to
> > >> enforce?  What are some out of bounds things?
> > >>
> > >>
> > >>
> > >> This seems like a really important discussion and something that we
> should
> > >> center on sooner than later.  There are ways to nuance this such as
> RTC for
> > >> the core and CTR for extensions and so on but I think that just leads
> to
> > >> more confusion.  We should likely pick our poison. I see strong
> benefits in
> > >> both directions and so I can deal either way personally.  I see a
> couple
> > >> strong arguments here in this thread already for RTC .
> > >>
> > >> Anyone willing to argue for CTR?
> > >>
> > >> Thanks
> > >> Joe
> > >>
> > >>
> > >> On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <
> bimargulies@gmail.com>
> > >> wrote:
> > >>
> > >>> It seems to me, and this is purely opinion, that RTC has a lot to be
> said
> > >>> for a new project, in terms of getting more people involved, more
> eyeballs,
> > >>> and more of a community feeling. My dayjob workflow is 'make branch,
> submit
> > >>> pr, get review, merge' and that seems pretty applicable. However, I
> am not
> > >>> wearing any magic mentor hat-o-authority.
> > >>>
> > >>>> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org>
> wrote:
> > >>>>
> > >>>>> On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com>
> wrote:
> > >>>>>
> > >>>>> Benson - thanks for the headsup on the maven plugin.  Seems like
> using
> > >>>> them
> > >>>>> to their fullest capability and then manually merging to master is
> > >>>>> perfectly fine to me.
> > >>>>>
> > >>>>> Billie
> > >>>>> As for CTR i don't think i have a good enough appreciation for the
> > >>>>> process/value proposition here.  Curious of other folks views.
> > >>>>
> > >>>> Both CTR and RTC have their own advantages, so either would be fine
> (
> > >>>> http://www.apache.org/foundation/glossary.html#CommitThenReview).
> In
> > >>>> retrospect I see my question could be viewed as leaning towards
> CTR, but
> > >>> it
> > >>>> was just based on an observation that people already seemed to be
> making
> > >>>> commits without review.
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> It seems reasonable to keep the feature branch relaxed and in that
> > >>> sense
> > >>>>> what Gilman did today seems fine.  We can get bettter at those
> > >>> judgement
> > >>>>> calls and documenting the criteria as we go along.
> > >>>>>
> > >>>>> Thanks
> > >>>>> Joe
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
> > >>> bimargulies@gmail.com
> > >>>>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> PR's are certainly convenient. There's no much difference, for a
> > >>>>> committer,
> > >>>>>> between pushing a branch to the official repo and pushing a
> branch to
> > >>>>> some
> > >>>>>> personal repo on github. The same integration workflow can be used
> > >>>> either
> > >>>>>> way to close out the PR upon merge.
> > >>>>>>
> > >>>>>> However, in a CTR project, it seems perhaps excessive to _require_
> > >>>>> feature
> > >>>>>> branches for small fixes as opposed to just committing them
> directly
> > >>> to
> > >>>>>> develop. At day job we do mostly do branch-per-jira, but some
> people
> > >>>>> might
> > >>>>>> find that onerous.
> > >>>>>>
> > >>>>>> Pushing to the official repo leaves more history that someone
> might
> > >>>> find
> > >>>>>> interesting some day. Also more clutter; some people are very
> > >>> concerned
> > >>>>>> about repacking before merging to develop.
> > >>>>>>
> > >>>>>> Another issue with gitflow is the master branch. The master
> branch is
> > >>>>>> supposed to get merged to for releases. The maven-release-plugin
> > >>> won't
> > >>>> do
> > >>>>>> that, and the jgitflow plugin is unsafe. So one option is to 'use
> > >>>>> gitflow'
> > >>>>>> but not bother with the master versus develop distinction, the
> other
> > >>> is
> > >>>>> to
> > >>>>>> do manual merges to master at release points.
> > >>>>>>
> > >>>>>>
> > >>>>>> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
> > >>> wrote:
> > >>>>>>
> > >>>>>>> Hello
> > >>>>>>>
> > >>>>>>> So a question on gitflow given that commits are now underway.
> When
> > >>>>>> working
> > >>>>>>> on a feature in a local repo which is a branch off the develop
> > >>>>>> branch...do
> > >>>>>>> you push the feature branch to the central repo?  This then can
> be
> > >>>>> merged
> > >>>>>>> by someone else as a sort of code review/pull process?
> > >>>>>>>
> > >>>>>>> Thanks
> > >>>>>>> Joe
> > >>>>>>>
> > >>>>>>> On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
> > >>>> wrote:
> > >>>>>>>
> > >>>>>>>> All,
> > >>>>>>>>
> > >>>>>>>> Now that we have our code up it is important to establish a
> > >>> process
> > >>>>>>> around
> > >>>>>>>> git in particular.  A general consensus in the thread appears to
> > >>> be
> > >>>>>> that
> > >>>>>>>> gitflow workflow is a reasonable option.
> > >>>
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> > >>>>>>>>
> > >>>>>>>> To that end I've added a develop branch off of master from which
> > >>>>>> features
> > >>>>>>>> can be built.  As we converge toward a release then we'll
> > >>>>>>> address/introduce
> > >>>>>>>> some of the other aspects of gitflow.
> > >>>>>>>>
> > >>>>>>>> Please discuss/comment if there are views that we should be
> > >>> taking
> > >>>>>>> another
> > >>>>>>>> path.
> > >>>>>>>>
> > >>>>>>>> Thanks
> > >>>>>>>> Joe
> > >>>>>>>>
> > >>>>>>>> On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> > >>>>>> bimargulies@gmail.com
> > >>>>>>>>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> > >>>>> wikier@apache.org>
> > >>>>>>>>> wrote:
> > >>>>>>>>>> Hi Adam,
> > >>>>>>>>>>
> > >>>>>>>>>> one remarks about this:
> > >>>>>>>>>>
> > >>>>>>>>>>> On 28/11/14 18:07, Adam Taft wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> Knowing how we work today, if it were me, I would suggest
> > >>> using
> > >>>>> the
> > >>>>>>>>> above
> > >>>>>>>>>>> workflow combined with the "forking workflow" to guard access
> > >>>> to
> > >>>>>> the
> > >>>>>>>>>>> production release (master) branches.  A very small subset of
> > >>>> the
> > >>>>>>>>>>> incubator's commiters should have the ability to merge the
> > >>>>>> "develop"
> > >>>>>>>>>>> branch
> > >>>>>>>>>>> down to a master "release" branch.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Suck workflow is not in place in ASF. On the one hand, the
> > >>>> current
> > >>>>>> git
> > >>>>>>>>>> infrastructure does not provide such branches' management,
> > >>> like
> > >>>>>>>>>> bitbucket/stash do for instance. On the other hand, and more
> > >>>>>>> important,
> > >>>>>>>>> a
> > >>>>>>>>>> project is not hierarchical organization, but a a meritocratic
> > >>>>> one.
> > >>>>>>>>>>
> > >>>>>>>>>> I recommend you this blog post in case you want to read a bit
> > >>>>> more:
> > >>> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> > >>>>>>>>>>
> > >>>>>>>>>> If someone has permissions to do (i.e., he is a committer), he
> > >>>> can
> > >>>>>> do
> > >>>>>>>>> it,
> > >>>>>>>>>> simple The tool provide you instruments to revert those
> > >>> changes
> > >>>> in
> > >>>>>>> case
> > >>>>>>>>> on
> > >>>>>>>>>> involuntary errors.
> > >>>>>>>>>>
> > >>>>>>>>>>> It would be ideal to have someone who
> > >>>>>>>>>>> is NOT performing the majority of changes on the "develop"
> > >>>> branch
> > >>>>>>> take
> > >>>>>>>>>>> this
> > >>>>>>>>>>> role to coordinate releases, ensure minimal coding standards,
> > >>>> run
> > >>>>>>>>> through
> > >>>>>>>>>>> unit and integration tests, before signing off on the release
> > >>>> and
> > >>>>>>>>> issuing
> > >>>>>>>>>>> the release artifacts.
> > >>>>>>>>>
> > >>>>>>>>> You seem to be imagining an individual with a job which is
> > >>> shared
> > >>>> in
> > >>>>>>>>> by the community. In healthy communities, a release happens
> when
> > >>>>>>>>> there's a consensus to have a release. There is no person who
> > >>>>> 'ensures
> > >>>>>>>>> minimal coding standards', that's everyone watching commits.
> > >>>> There's
> > >>>>>>>>> no one 'running unit and integration tests' because (a) every
> > >>>>>>>>> committer does this before every commit, (b) Jenkins does it,
> > >>> (c)
> > >>>>> the
> > >>>>>>>>> release process does it. (d) there's no signing off on a
> > >>> release.
> > >>>>> The
> > >>>>>>>>> RM puts it up for a vote, and PMC members vote.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Release comes after that. The release manager is responsible
> > >>> on
> > >>>>>>>>> creating a
> > >>>>>>>>>> proper release, which must include a code release and should
> > >>>>> include
> > >>>>>>>>>> binaries too. Each artifact release must be signed.
> > >>> Demonstrate
> > >>>>> your
> > >>>>>>>>> ability
> > >>>>>>>>>> as a project to produce releases is one of the goals of the
> > >>>>>>> incubation.
> > >>>>>>>>> But
> > >>>>>>>>>> we are not yet there, step by step.
> > >>>>>>>>>>
> > >>>>>>>>>> Hope that helps.
> > >>>>>>>>>>
> > >>>>>>>>>> Cheers,
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>> Sergio Fernández
> > >>>>>>>>>> Partner Technology Manager
> > >>>>>>>>>> Redlink GmbH
> > >>>>>>>>>> m: +43 660 2747 925
> > >>>>>>>>>> e: sergio.fernandez@redlink.co
> > >>>>>>>>>> w: http://redlink.co
> > >>>
> >
> >
> >
> > --
> > Joey Echeverria
>
>

RE: git workflow for nifi

Posted by Mark Payne <ma...@hotmail.com>.

So I'll admit that my experience in this area has been terrible is may be very different from what I will experience here. "Code Review" in my world has often meant "let this new developer without any experience review your code and then you can spend 3 days explaining each line to him." And this will absolutely cripple us. I don't think this is what we're talking about here, so I'll retract that statement :)
So I'll remain with Tony in the middle and give no +1 to RTC or CTR.
Thanks-Mark

> Date: Wed, 10 Dec 2014 18:42:22 -0800
> Subject: Re: git workflow for nifi
> From: joey@cloudera.com
> To: dev@nifi.incubator.apache.org
> 
> > though I think it will VERY MUCH impede the speed at which any new features / bug fixes can be accomplished.
> 
> I don't agree, at least not in the long run. Also, I think a review is
> only required before checking into the main development branch. If
> we're using gitflow, then commits to feature branches should be
> handled by who ever is managing that feature. That can mean doing
> reviews as they come in or waiting until the feature is done and
> reviewing it all at once. But having code reviews saves a lot of time
> in the long run.
> 
> Another thing to consider is that over time, committers should be
> spending less time working on new features/fixing bugs and more time
> on growing the community and providing quality code reviews is one of
> the best ways to do that.
> 
> On Wed, Dec 10, 2014 at 6:34 PM, Mark Payne <ma...@hotmail.com> wrote:
> > I think the big question, which you brought up, is "what constitutes a review?" If another committer looking over the code and signing off is sufficient then I'm not horribly opposed, though I think it will VERY MUCH impede the speed at which any new features / bug fixes can be accomplished.
> >
> > If we are talking about waiting for several people to vote, then I think it's an absolute non-starter and destroys any hope of moving even at a fraction of the rate we are used to. This is especially concerning if we are waiting for a consensus for something like a trivial bug fix like an NPE.
> >
> > Thanks
> > -Mark
> >
> >> On Dec 10, 2014, at 9:20 PM, Joe Witt <jo...@gmail.com> wrote:
> >>
> >> NiFi grew up in a CT[R] environment where the review was very rare and so
> >> really we ended up with CTDTFSOR - Commit then deploy then feel sense of
> >> regret.
> >>
> >> So the bad side: We ended up with a lot of avoidable defects where by
> >> avoidable I mean they could have likely been detected in a decent review
> >> effort.
> >>
> >> The good side: We were fast.  Very fast.  New features got out quick and if
> >> something was funky we fixed it very fast.  For the vast majority of
> >> mistakes the problem was highly isolated (thanks to our base design
> >> construct of FBP) and rarely caused extremely stressful days.
> >>
> >> On balance though and given the benefits it has to community growth I
> >> personally am very supportive of us adopting RTC immediately provided we
> >> can sort out some key questions:
> >>
> >> - What constitutes a valid review?
> >> This page http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> >> suggests that a review is a consensus approval.  I am very concerned by
> >> that definition if we're talking every commit means we need a vote.  For
> >> the vast majority of commits this just seems to onerous and too time
> >> consuming and frankly to me takes some of the fun out of developing.  If
> >> for us a review is simply that a 'committer' has reviewed the code then I
> >> am perfectly happy with this and I am thinking this is in-line with the
> >> model Benson described for his dayjob "'make branch, submit pr, get review,
> >> merge'"
> >>
> >> - What is the best tooling/process around this to actually conduct/document
> >> the review?
> >> I think
> >> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
> >> does a good job of describing the mechanics of a review/submission
> >> process.  And I'd just assume a patch is as good as a pull request.  I
> >> think even as a good starting point having the JIRA ticket commented on by
> >> the reviewer would be good.
> >>
> >> - What are some key things a reviewer should be checking for and helping to
> >> enforce?  What are some out of bounds things?
> >>
> >>
> >>
> >> This seems like a really important discussion and something that we should
> >> center on sooner than later.  There are ways to nuance this such as RTC for
> >> the core and CTR for extensions and so on but I think that just leads to
> >> more confusion.  We should likely pick our poison. I see strong benefits in
> >> both directions and so I can deal either way personally.  I see a couple
> >> strong arguments here in this thread already for RTC .
> >>
> >> Anyone willing to argue for CTR?
> >>
> >> Thanks
> >> Joe
> >>
> >>
> >> On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <bi...@gmail.com>
> >> wrote:
> >>
> >>> It seems to me, and this is purely opinion, that RTC has a lot to be said
> >>> for a new project, in terms of getting more people involved, more eyeballs,
> >>> and more of a community feeling. My dayjob workflow is 'make branch, submit
> >>> pr, get review, merge' and that seems pretty applicable. However, I am not
> >>> wearing any magic mentor hat-o-authority.
> >>>
> >>>> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org> wrote:
> >>>>
> >>>>> On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
> >>>>>
> >>>>> Benson - thanks for the headsup on the maven plugin.  Seems like using
> >>>> them
> >>>>> to their fullest capability and then manually merging to master is
> >>>>> perfectly fine to me.
> >>>>>
> >>>>> Billie
> >>>>> As for CTR i don't think i have a good enough appreciation for the
> >>>>> process/value proposition here.  Curious of other folks views.
> >>>>
> >>>> Both CTR and RTC have their own advantages, so either would be fine (
> >>>> http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
> >>>> retrospect I see my question could be viewed as leaning towards CTR, but
> >>> it
> >>>> was just based on an observation that people already seemed to be making
> >>>> commits without review.
> >>>>
> >>>>
> >>>>>
> >>>>> It seems reasonable to keep the feature branch relaxed and in that
> >>> sense
> >>>>> what Gilman did today seems fine.  We can get bettter at those
> >>> judgement
> >>>>> calls and documenting the criteria as we go along.
> >>>>>
> >>>>> Thanks
> >>>>> Joe
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
> >>> bimargulies@gmail.com
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> PR's are certainly convenient. There's no much difference, for a
> >>>>> committer,
> >>>>>> between pushing a branch to the official repo and pushing a branch to
> >>>>> some
> >>>>>> personal repo on github. The same integration workflow can be used
> >>>> either
> >>>>>> way to close out the PR upon merge.
> >>>>>>
> >>>>>> However, in a CTR project, it seems perhaps excessive to _require_
> >>>>> feature
> >>>>>> branches for small fixes as opposed to just committing them directly
> >>> to
> >>>>>> develop. At day job we do mostly do branch-per-jira, but some people
> >>>>> might
> >>>>>> find that onerous.
> >>>>>>
> >>>>>> Pushing to the official repo leaves more history that someone might
> >>>> find
> >>>>>> interesting some day. Also more clutter; some people are very
> >>> concerned
> >>>>>> about repacking before merging to develop.
> >>>>>>
> >>>>>> Another issue with gitflow is the master branch. The master branch is
> >>>>>> supposed to get merged to for releases. The maven-release-plugin
> >>> won't
> >>>> do
> >>>>>> that, and the jgitflow plugin is unsafe. So one option is to 'use
> >>>>> gitflow'
> >>>>>> but not bother with the master versus develop distinction, the other
> >>> is
> >>>>> to
> >>>>>> do manual merges to master at release points.
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>>> Hello
> >>>>>>>
> >>>>>>> So a question on gitflow given that commits are now underway.  When
> >>>>>> working
> >>>>>>> on a feature in a local repo which is a branch off the develop
> >>>>>> branch...do
> >>>>>>> you push the feature branch to the central repo?  This then can be
> >>>>> merged
> >>>>>>> by someone else as a sort of code review/pull process?
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Joe
> >>>>>>>
> >>>>>>> On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> All,
> >>>>>>>>
> >>>>>>>> Now that we have our code up it is important to establish a
> >>> process
> >>>>>>> around
> >>>>>>>> git in particular.  A general consensus in the thread appears to
> >>> be
> >>>>>> that
> >>>>>>>> gitflow workflow is a reasonable option.
> >>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> >>>>>>>>
> >>>>>>>> To that end I've added a develop branch off of master from which
> >>>>>> features
> >>>>>>>> can be built.  As we converge toward a release then we'll
> >>>>>>> address/introduce
> >>>>>>>> some of the other aspects of gitflow.
> >>>>>>>>
> >>>>>>>> Please discuss/comment if there are views that we should be
> >>> taking
> >>>>>>> another
> >>>>>>>> path.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Joe
> >>>>>>>>
> >>>>>>>> On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> >>>>>> bimargulies@gmail.com
> >>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> >>>>> wikier@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>> Hi Adam,
> >>>>>>>>>>
> >>>>>>>>>> one remarks about this:
> >>>>>>>>>>
> >>>>>>>>>>> On 28/11/14 18:07, Adam Taft wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Knowing how we work today, if it were me, I would suggest
> >>> using
> >>>>> the
> >>>>>>>>> above
> >>>>>>>>>>> workflow combined with the "forking workflow" to guard access
> >>>> to
> >>>>>> the
> >>>>>>>>>>> production release (master) branches.  A very small subset of
> >>>> the
> >>>>>>>>>>> incubator's commiters should have the ability to merge the
> >>>>>> "develop"
> >>>>>>>>>>> branch
> >>>>>>>>>>> down to a master "release" branch.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Suck workflow is not in place in ASF. On the one hand, the
> >>>> current
> >>>>>> git
> >>>>>>>>>> infrastructure does not provide such branches' management,
> >>> like
> >>>>>>>>>> bitbucket/stash do for instance. On the other hand, and more
> >>>>>>> important,
> >>>>>>>>> a
> >>>>>>>>>> project is not hierarchical organization, but a a meritocratic
> >>>>> one.
> >>>>>>>>>>
> >>>>>>>>>> I recommend you this blog post in case you want to read a bit
> >>>>> more:
> >>> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> >>>>>>>>>>
> >>>>>>>>>> If someone has permissions to do (i.e., he is a committer), he
> >>>> can
> >>>>>> do
> >>>>>>>>> it,
> >>>>>>>>>> simple The tool provide you instruments to revert those
> >>> changes
> >>>> in
> >>>>>>> case
> >>>>>>>>> on
> >>>>>>>>>> involuntary errors.
> >>>>>>>>>>
> >>>>>>>>>>> It would be ideal to have someone who
> >>>>>>>>>>> is NOT performing the majority of changes on the "develop"
> >>>> branch
> >>>>>>> take
> >>>>>>>>>>> this
> >>>>>>>>>>> role to coordinate releases, ensure minimal coding standards,
> >>>> run
> >>>>>>>>> through
> >>>>>>>>>>> unit and integration tests, before signing off on the release
> >>>> and
> >>>>>>>>> issuing
> >>>>>>>>>>> the release artifacts.
> >>>>>>>>>
> >>>>>>>>> You seem to be imagining an individual with a job which is
> >>> shared
> >>>> in
> >>>>>>>>> by the community. In healthy communities, a release happens when
> >>>>>>>>> there's a consensus to have a release. There is no person who
> >>>>> 'ensures
> >>>>>>>>> minimal coding standards', that's everyone watching commits.
> >>>> There's
> >>>>>>>>> no one 'running unit and integration tests' because (a) every
> >>>>>>>>> committer does this before every commit, (b) Jenkins does it,
> >>> (c)
> >>>>> the
> >>>>>>>>> release process does it. (d) there's no signing off on a
> >>> release.
> >>>>> The
> >>>>>>>>> RM puts it up for a vote, and PMC members vote.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Release comes after that. The release manager is responsible
> >>> on
> >>>>>>>>> creating a
> >>>>>>>>>> proper release, which must include a code release and should
> >>>>> include
> >>>>>>>>>> binaries too. Each artifact release must be signed.
> >>> Demonstrate
> >>>>> your
> >>>>>>>>> ability
> >>>>>>>>>> as a project to produce releases is one of the goals of the
> >>>>>>> incubation.
> >>>>>>>>> But
> >>>>>>>>>> we are not yet there, step by step.
> >>>>>>>>>>
> >>>>>>>>>> Hope that helps.
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Sergio Fernández
> >>>>>>>>>> Partner Technology Manager
> >>>>>>>>>> Redlink GmbH
> >>>>>>>>>> m: +43 660 2747 925
> >>>>>>>>>> e: sergio.fernandez@redlink.co
> >>>>>>>>>> w: http://redlink.co
> >>>
> 
> 
> 
> -- 
> Joey Echeverria

Re: git workflow for nifi

Posted by Joey Echeverria <jo...@cloudera.com>.

> though I think it will VERY MUCH impede the speed at which any new features / bug fixes can be accomplished.

I don't agree, at least not in the long run. Also, I think a review is
only required before checking into the main development branch. If
we're using gitflow, then commits to feature branches should be
handled by who ever is managing that feature. That can mean doing
reviews as they come in or waiting until the feature is done and
reviewing it all at once. But having code reviews saves a lot of time
in the long run.

Another thing to consider is that over time, committers should be
spending less time working on new features/fixing bugs and more time
on growing the community and providing quality code reviews is one of
the best ways to do that.

On Wed, Dec 10, 2014 at 6:34 PM, Mark Payne <ma...@hotmail.com> wrote:
> I think the big question, which you brought up, is "what constitutes a review?" If another committer looking over the code and signing off is sufficient then I'm not horribly opposed, though I think it will VERY MUCH impede the speed at which any new features / bug fixes can be accomplished.
>
> If we are talking about waiting for several people to vote, then I think it's an absolute non-starter and destroys any hope of moving even at a fraction of the rate we are used to. This is especially concerning if we are waiting for a consensus for something like a trivial bug fix like an NPE.
>
> Thanks
> -Mark
>
>> On Dec 10, 2014, at 9:20 PM, Joe Witt <jo...@gmail.com> wrote:
>>
>> NiFi grew up in a CT[R] environment where the review was very rare and so
>> really we ended up with CTDTFSOR - Commit then deploy then feel sense of
>> regret.
>>
>> So the bad side: We ended up with a lot of avoidable defects where by
>> avoidable I mean they could have likely been detected in a decent review
>> effort.
>>
>> The good side: We were fast.  Very fast.  New features got out quick and if
>> something was funky we fixed it very fast.  For the vast majority of
>> mistakes the problem was highly isolated (thanks to our base design
>> construct of FBP) and rarely caused extremely stressful days.
>>
>> On balance though and given the benefits it has to community growth I
>> personally am very supportive of us adopting RTC immediately provided we
>> can sort out some key questions:
>>
>> - What constitutes a valid review?
>> This page http://www.apache.org/foundation/glossary.html#ReviewThenCommit
>> suggests that a review is a consensus approval.  I am very concerned by
>> that definition if we're talking every commit means we need a vote.  For
>> the vast majority of commits this just seems to onerous and too time
>> consuming and frankly to me takes some of the fun out of developing.  If
>> for us a review is simply that a 'committer' has reviewed the code then I
>> am perfectly happy with this and I am thinking this is in-line with the
>> model Benson described for his dayjob "'make branch, submit pr, get review,
>> merge'"
>>
>> - What is the best tooling/process around this to actually conduct/document
>> the review?
>> I think
>> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
>> does a good job of describing the mechanics of a review/submission
>> process.  And I'd just assume a patch is as good as a pull request.  I
>> think even as a good starting point having the JIRA ticket commented on by
>> the reviewer would be good.
>>
>> - What are some key things a reviewer should be checking for and helping to
>> enforce?  What are some out of bounds things?
>>
>>
>>
>> This seems like a really important discussion and something that we should
>> center on sooner than later.  There are ways to nuance this such as RTC for
>> the core and CTR for extensions and so on but I think that just leads to
>> more confusion.  We should likely pick our poison. I see strong benefits in
>> both directions and so I can deal either way personally.  I see a couple
>> strong arguments here in this thread already for RTC .
>>
>> Anyone willing to argue for CTR?
>>
>> Thanks
>> Joe
>>
>>
>> On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <bi...@gmail.com>
>> wrote:
>>
>>> It seems to me, and this is purely opinion, that RTC has a lot to be said
>>> for a new project, in terms of getting more people involved, more eyeballs,
>>> and more of a community feeling. My dayjob workflow is 'make branch, submit
>>> pr, get review, merge' and that seems pretty applicable. However, I am not
>>> wearing any magic mentor hat-o-authority.
>>>
>>>> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org> wrote:
>>>>
>>>>> On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
>>>>>
>>>>> Benson - thanks for the headsup on the maven plugin.  Seems like using
>>>> them
>>>>> to their fullest capability and then manually merging to master is
>>>>> perfectly fine to me.
>>>>>
>>>>> Billie
>>>>> As for CTR i don't think i have a good enough appreciation for the
>>>>> process/value proposition here.  Curious of other folks views.
>>>>
>>>> Both CTR and RTC have their own advantages, so either would be fine (
>>>> http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
>>>> retrospect I see my question could be viewed as leaning towards CTR, but
>>> it
>>>> was just based on an observation that people already seemed to be making
>>>> commits without review.
>>>>
>>>>
>>>>>
>>>>> It seems reasonable to keep the feature branch relaxed and in that
>>> sense
>>>>> what Gilman did today seems fine.  We can get bettter at those
>>> judgement
>>>>> calls and documenting the criteria as we go along.
>>>>>
>>>>> Thanks
>>>>> Joe
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
>>> bimargulies@gmail.com
>>>>>
>>>>> wrote:
>>>>>
>>>>>> PR's are certainly convenient. There's no much difference, for a
>>>>> committer,
>>>>>> between pushing a branch to the official repo and pushing a branch to
>>>>> some
>>>>>> personal repo on github. The same integration workflow can be used
>>>> either
>>>>>> way to close out the PR upon merge.
>>>>>>
>>>>>> However, in a CTR project, it seems perhaps excessive to _require_
>>>>> feature
>>>>>> branches for small fixes as opposed to just committing them directly
>>> to
>>>>>> develop. At day job we do mostly do branch-per-jira, but some people
>>>>> might
>>>>>> find that onerous.
>>>>>>
>>>>>> Pushing to the official repo leaves more history that someone might
>>>> find
>>>>>> interesting some day. Also more clutter; some people are very
>>> concerned
>>>>>> about repacking before merging to develop.
>>>>>>
>>>>>> Another issue with gitflow is the master branch. The master branch is
>>>>>> supposed to get merged to for releases. The maven-release-plugin
>>> won't
>>>> do
>>>>>> that, and the jgitflow plugin is unsafe. So one option is to 'use
>>>>> gitflow'
>>>>>> but not bother with the master versus develop distinction, the other
>>> is
>>>>> to
>>>>>> do manual merges to master at release points.
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
>>> wrote:
>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> So a question on gitflow given that commits are now underway.  When
>>>>>> working
>>>>>>> on a feature in a local repo which is a branch off the develop
>>>>>> branch...do
>>>>>>> you push the feature branch to the central repo?  This then can be
>>>>> merged
>>>>>>> by someone else as a sort of code review/pull process?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>>
>>>>>>> On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> Now that we have our code up it is important to establish a
>>> process
>>>>>>> around
>>>>>>>> git in particular.  A general consensus in the thread appears to
>>> be
>>>>>> that
>>>>>>>> gitflow workflow is a reasonable option.
>>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>>>>>>>>
>>>>>>>> To that end I've added a develop branch off of master from which
>>>>>> features
>>>>>>>> can be built.  As we converge toward a release then we'll
>>>>>>> address/introduce
>>>>>>>> some of the other aspects of gitflow.
>>>>>>>>
>>>>>>>> Please discuss/comment if there are views that we should be
>>> taking
>>>>>>> another
>>>>>>>> path.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Joe
>>>>>>>>
>>>>>>>> On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
>>>>>> bimargulies@gmail.com
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
>>>>> wikier@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>> Hi Adam,
>>>>>>>>>>
>>>>>>>>>> one remarks about this:
>>>>>>>>>>
>>>>>>>>>>> On 28/11/14 18:07, Adam Taft wrote:
>>>>>>>>>>>
>>>>>>>>>>> Knowing how we work today, if it were me, I would suggest
>>> using
>>>>> the
>>>>>>>>> above
>>>>>>>>>>> workflow combined with the "forking workflow" to guard access
>>>> to
>>>>>> the
>>>>>>>>>>> production release (master) branches.  A very small subset of
>>>> the
>>>>>>>>>>> incubator's commiters should have the ability to merge the
>>>>>> "develop"
>>>>>>>>>>> branch
>>>>>>>>>>> down to a master "release" branch.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Suck workflow is not in place in ASF. On the one hand, the
>>>> current
>>>>>> git
>>>>>>>>>> infrastructure does not provide such branches' management,
>>> like
>>>>>>>>>> bitbucket/stash do for instance. On the other hand, and more
>>>>>>> important,
>>>>>>>>> a
>>>>>>>>>> project is not hierarchical organization, but a a meritocratic
>>>>> one.
>>>>>>>>>>
>>>>>>>>>> I recommend you this blog post in case you want to read a bit
>>>>> more:
>>> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
>>>>>>>>>>
>>>>>>>>>> If someone has permissions to do (i.e., he is a committer), he
>>>> can
>>>>>> do
>>>>>>>>> it,
>>>>>>>>>> simple The tool provide you instruments to revert those
>>> changes
>>>> in
>>>>>>> case
>>>>>>>>> on
>>>>>>>>>> involuntary errors.
>>>>>>>>>>
>>>>>>>>>>> It would be ideal to have someone who
>>>>>>>>>>> is NOT performing the majority of changes on the "develop"
>>>> branch
>>>>>>> take
>>>>>>>>>>> this
>>>>>>>>>>> role to coordinate releases, ensure minimal coding standards,
>>>> run
>>>>>>>>> through
>>>>>>>>>>> unit and integration tests, before signing off on the release
>>>> and
>>>>>>>>> issuing
>>>>>>>>>>> the release artifacts.
>>>>>>>>>
>>>>>>>>> You seem to be imagining an individual with a job which is
>>> shared
>>>> in
>>>>>>>>> by the community. In healthy communities, a release happens when
>>>>>>>>> there's a consensus to have a release. There is no person who
>>>>> 'ensures
>>>>>>>>> minimal coding standards', that's everyone watching commits.
>>>> There's
>>>>>>>>> no one 'running unit and integration tests' because (a) every
>>>>>>>>> committer does this before every commit, (b) Jenkins does it,
>>> (c)
>>>>> the
>>>>>>>>> release process does it. (d) there's no signing off on a
>>> release.
>>>>> The
>>>>>>>>> RM puts it up for a vote, and PMC members vote.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Release comes after that. The release manager is responsible
>>> on
>>>>>>>>> creating a
>>>>>>>>>> proper release, which must include a code release and should
>>>>> include
>>>>>>>>>> binaries too. Each artifact release must be signed.
>>> Demonstrate
>>>>> your
>>>>>>>>> ability
>>>>>>>>>> as a project to produce releases is one of the goals of the
>>>>>>> incubation.
>>>>>>>>> But
>>>>>>>>>> we are not yet there, step by step.
>>>>>>>>>>
>>>>>>>>>> Hope that helps.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sergio Fernández
>>>>>>>>>> Partner Technology Manager
>>>>>>>>>> Redlink GmbH
>>>>>>>>>> m: +43 660 2747 925
>>>>>>>>>> e: sergio.fernandez@redlink.co
>>>>>>>>>> w: http://redlink.co
>>>



-- 
Joey Echeverria

Re: git workflow for nifi

Posted by Tony Kurc <tr...@gmail.com>.

I'm straight down the middle on this one. I don't object to either. I don't
prefer either of them. I've seen both contribute to quagmire and hurt
feelings, and both work just perfectly well.

On Wed, Dec 10, 2014 at 9:34 PM, Mark Payne <ma...@hotmail.com> wrote:

> I think the big question, which you brought up, is "what constitutes a
> review?" If another committer looking over the code and signing off is
> sufficient then I'm not horribly opposed, though I think it will VERY MUCH
> impede the speed at which any new features / bug fixes can be accomplished.
>
> If we are talking about waiting for several people to vote, then I think
> it's an absolute non-starter and destroys any hope of moving even at a
> fraction of the rate we are used to. This is especially concerning if we
> are waiting for a consensus for something like a trivial bug fix like an
> NPE.
>
> Thanks
> -Mark
>
> > On Dec 10, 2014, at 9:20 PM, Joe Witt <jo...@gmail.com> wrote:
> >
> > NiFi grew up in a CT[R] environment where the review was very rare and so
> > really we ended up with CTDTFSOR - Commit then deploy then feel sense of
> > regret.
> >
> > So the bad side: We ended up with a lot of avoidable defects where by
> > avoidable I mean they could have likely been detected in a decent review
> > effort.
> >
> > The good side: We were fast.  Very fast.  New features got out quick and
> if
> > something was funky we fixed it very fast.  For the vast majority of
> > mistakes the problem was highly isolated (thanks to our base design
> > construct of FBP) and rarely caused extremely stressful days.
> >
> > On balance though and given the benefits it has to community growth I
> > personally am very supportive of us adopting RTC immediately provided we
> > can sort out some key questions:
> >
> > - What constitutes a valid review?
> > This page
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > suggests that a review is a consensus approval.  I am very concerned by
> > that definition if we're talking every commit means we need a vote.  For
> > the vast majority of commits this just seems to onerous and too time
> > consuming and frankly to me takes some of the fun out of developing.  If
> > for us a review is simply that a 'committer' has reviewed the code then I
> > am perfectly happy with this and I am thinking this is in-line with the
> > model Benson described for his dayjob "'make branch, submit pr, get
> review,
> > merge'"
> >
> > - What is the best tooling/process around this to actually
> conduct/document
> > the review?
> > I think
> >
> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
> > does a good job of describing the mechanics of a review/submission
> > process.  And I'd just assume a patch is as good as a pull request.  I
> > think even as a good starting point having the JIRA ticket commented on
> by
> > the reviewer would be good.
> >
> > - What are some key things a reviewer should be checking for and helping
> to
> > enforce?  What are some out of bounds things?
> >
> >
> >
> > This seems like a really important discussion and something that we
> should
> > center on sooner than later.  There are ways to nuance this such as RTC
> for
> > the core and CTR for extensions and so on but I think that just leads to
> > more confusion.  We should likely pick our poison. I see strong benefits
> in
> > both directions and so I can deal either way personally.  I see a couple
> > strong arguments here in this thread already for RTC .
> >
> > Anyone willing to argue for CTR?
> >
> > Thanks
> > Joe
> >
> >
> > On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <bimargulies@gmail.com
> >
> > wrote:
> >
> >> It seems to me, and this is purely opinion, that RTC has a lot to be
> said
> >> for a new project, in terms of getting more people involved, more
> eyeballs,
> >> and more of a community feeling. My dayjob workflow is 'make branch,
> submit
> >> pr, get review, merge' and that seems pretty applicable. However, I am
> not
> >> wearing any magic mentor hat-o-authority.
> >>
> >>> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org>
> wrote:
> >>>
> >>>> On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
> >>>>
> >>>> Benson - thanks for the headsup on the maven plugin.  Seems like using
> >>> them
> >>>> to their fullest capability and then manually merging to master is
> >>>> perfectly fine to me.
> >>>>
> >>>> Billie
> >>>> As for CTR i don't think i have a good enough appreciation for the
> >>>> process/value proposition here.  Curious of other folks views.
> >>>
> >>> Both CTR and RTC have their own advantages, so either would be fine (
> >>> http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
> >>> retrospect I see my question could be viewed as leaning towards CTR,
> but
> >> it
> >>> was just based on an observation that people already seemed to be
> making
> >>> commits without review.
> >>>
> >>>
> >>>>
> >>>> It seems reasonable to keep the feature branch relaxed and in that
> >> sense
> >>>> what Gilman did today seems fine.  We can get bettter at those
> >> judgement
> >>>> calls and documenting the criteria as we go along.
> >>>>
> >>>> Thanks
> >>>> Joe
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
> >> bimargulies@gmail.com
> >>>>
> >>>> wrote:
> >>>>
> >>>>> PR's are certainly convenient. There's no much difference, for a
> >>>> committer,
> >>>>> between pushing a branch to the official repo and pushing a branch to
> >>>> some
> >>>>> personal repo on github. The same integration workflow can be used
> >>> either
> >>>>> way to close out the PR upon merge.
> >>>>>
> >>>>> However, in a CTR project, it seems perhaps excessive to _require_
> >>>> feature
> >>>>> branches for small fixes as opposed to just committing them directly
> >> to
> >>>>> develop. At day job we do mostly do branch-per-jira, but some people
> >>>> might
> >>>>> find that onerous.
> >>>>>
> >>>>> Pushing to the official repo leaves more history that someone might
> >>> find
> >>>>> interesting some day. Also more clutter; some people are very
> >> concerned
> >>>>> about repacking before merging to develop.
> >>>>>
> >>>>> Another issue with gitflow is the master branch. The master branch is
> >>>>> supposed to get merged to for releases. The maven-release-plugin
> >> won't
> >>> do
> >>>>> that, and the jgitflow plugin is unsafe. So one option is to 'use
> >>>> gitflow'
> >>>>> but not bother with the master versus develop distinction, the other
> >> is
> >>>> to
> >>>>> do manual merges to master at release points.
> >>>>>
> >>>>>
> >>>>> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
> >> wrote:
> >>>>>
> >>>>>> Hello
> >>>>>>
> >>>>>> So a question on gitflow given that commits are now underway.  When
> >>>>> working
> >>>>>> on a feature in a local repo which is a branch off the develop
> >>>>> branch...do
> >>>>>> you push the feature branch to the central repo?  This then can be
> >>>> merged
> >>>>>> by someone else as a sort of code review/pull process?
> >>>>>>
> >>>>>> Thanks
> >>>>>> Joe
> >>>>>>
> >>>>>> On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>>> All,
> >>>>>>>
> >>>>>>> Now that we have our code up it is important to establish a
> >> process
> >>>>>> around
> >>>>>>> git in particular.  A general consensus in the thread appears to
> >> be
> >>>>> that
> >>>>>>> gitflow workflow is a reasonable option.
> >>
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> >>>>>>>
> >>>>>>> To that end I've added a develop branch off of master from which
> >>>>> features
> >>>>>>> can be built.  As we converge toward a release then we'll
> >>>>>> address/introduce
> >>>>>>> some of the other aspects of gitflow.
> >>>>>>>
> >>>>>>> Please discuss/comment if there are views that we should be
> >> taking
> >>>>>> another
> >>>>>>> path.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Joe
> >>>>>>>
> >>>>>>> On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> >>>>> bimargulies@gmail.com
> >>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> >>>> wikier@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>> Hi Adam,
> >>>>>>>>>
> >>>>>>>>> one remarks about this:
> >>>>>>>>>
> >>>>>>>>>> On 28/11/14 18:07, Adam Taft wrote:
> >>>>>>>>>>
> >>>>>>>>>> Knowing how we work today, if it were me, I would suggest
> >> using
> >>>> the
> >>>>>>>> above
> >>>>>>>>>> workflow combined with the "forking workflow" to guard access
> >>> to
> >>>>> the
> >>>>>>>>>> production release (master) branches.  A very small subset of
> >>> the
> >>>>>>>>>> incubator's commiters should have the ability to merge the
> >>>>> "develop"
> >>>>>>>>>> branch
> >>>>>>>>>> down to a master "release" branch.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Suck workflow is not in place in ASF. On the one hand, the
> >>> current
> >>>>> git
> >>>>>>>>> infrastructure does not provide such branches' management,
> >> like
> >>>>>>>>> bitbucket/stash do for instance. On the other hand, and more
> >>>>>> important,
> >>>>>>>> a
> >>>>>>>>> project is not hierarchical organization, but a a meritocratic
> >>>> one.
> >>>>>>>>>
> >>>>>>>>> I recommend you this blog post in case you want to read a bit
> >>>> more:
> >> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> >>>>>>>>>
> >>>>>>>>> If someone has permissions to do (i.e., he is a committer), he
> >>> can
> >>>>> do
> >>>>>>>> it,
> >>>>>>>>> simple The tool provide you instruments to revert those
> >> changes
> >>> in
> >>>>>> case
> >>>>>>>> on
> >>>>>>>>> involuntary errors.
> >>>>>>>>>
> >>>>>>>>>> It would be ideal to have someone who
> >>>>>>>>>> is NOT performing the majority of changes on the "develop"
> >>> branch
> >>>>>> take
> >>>>>>>>>> this
> >>>>>>>>>> role to coordinate releases, ensure minimal coding standards,
> >>> run
> >>>>>>>> through
> >>>>>>>>>> unit and integration tests, before signing off on the release
> >>> and
> >>>>>>>> issuing
> >>>>>>>>>> the release artifacts.
> >>>>>>>>
> >>>>>>>> You seem to be imagining an individual with a job which is
> >> shared
> >>> in
> >>>>>>>> by the community. In healthy communities, a release happens when
> >>>>>>>> there's a consensus to have a release. There is no person who
> >>>> 'ensures
> >>>>>>>> minimal coding standards', that's everyone watching commits.
> >>> There's
> >>>>>>>> no one 'running unit and integration tests' because (a) every
> >>>>>>>> committer does this before every commit, (b) Jenkins does it,
> >> (c)
> >>>> the
> >>>>>>>> release process does it. (d) there's no signing off on a
> >> release.
> >>>> The
> >>>>>>>> RM puts it up for a vote, and PMC members vote.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Release comes after that. The release manager is responsible
> >> on
> >>>>>>>> creating a
> >>>>>>>>> proper release, which must include a code release and should
> >>>> include
> >>>>>>>>> binaries too. Each artifact release must be signed.
> >> Demonstrate
> >>>> your
> >>>>>>>> ability
> >>>>>>>>> as a project to produce releases is one of the goals of the
> >>>>>> incubation.
> >>>>>>>> But
> >>>>>>>>> we are not yet there, step by step.
> >>>>>>>>>
> >>>>>>>>> Hope that helps.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Sergio Fernández
> >>>>>>>>> Partner Technology Manager
> >>>>>>>>> Redlink GmbH
> >>>>>>>>> m: +43 660 2747 925
> >>>>>>>>> e: sergio.fernandez@redlink.co
> >>>>>>>>> w: http://redlink.co
> >>
>

Re: git workflow for nifi

Posted by Mark Payne <ma...@hotmail.com>.

I think the big question, which you brought up, is "what constitutes a review?" If another committer looking over the code and signing off is sufficient then I'm not horribly opposed, though I think it will VERY MUCH impede the speed at which any new features / bug fixes can be accomplished. 

If we are talking about waiting for several people to vote, then I think it's an absolute non-starter and destroys any hope of moving even at a fraction of the rate we are used to. This is especially concerning if we are waiting for a consensus for something like a trivial bug fix like an NPE. 

Thanks
-Mark

> On Dec 10, 2014, at 9:20 PM, Joe Witt <jo...@gmail.com> wrote:
> 
> NiFi grew up in a CT[R] environment where the review was very rare and so
> really we ended up with CTDTFSOR - Commit then deploy then feel sense of
> regret.
> 
> So the bad side: We ended up with a lot of avoidable defects where by
> avoidable I mean they could have likely been detected in a decent review
> effort.
> 
> The good side: We were fast.  Very fast.  New features got out quick and if
> something was funky we fixed it very fast.  For the vast majority of
> mistakes the problem was highly isolated (thanks to our base design
> construct of FBP) and rarely caused extremely stressful days.
> 
> On balance though and given the benefits it has to community growth I
> personally am very supportive of us adopting RTC immediately provided we
> can sort out some key questions:
> 
> - What constitutes a valid review?
> This page http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> suggests that a review is a consensus approval.  I am very concerned by
> that definition if we're talking every commit means we need a vote.  For
> the vast majority of commits this just seems to onerous and too time
> consuming and frankly to me takes some of the fun out of developing.  If
> for us a review is simply that a 'committer' has reviewed the code then I
> am perfectly happy with this and I am thinking this is in-line with the
> model Benson described for his dayjob "'make branch, submit pr, get review,
> merge'"
> 
> - What is the best tooling/process around this to actually conduct/document
> the review?
> I think
> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
> does a good job of describing the mechanics of a review/submission
> process.  And I'd just assume a patch is as good as a pull request.  I
> think even as a good starting point having the JIRA ticket commented on by
> the reviewer would be good.
> 
> - What are some key things a reviewer should be checking for and helping to
> enforce?  What are some out of bounds things?
> 
> 
> 
> This seems like a really important discussion and something that we should
> center on sooner than later.  There are ways to nuance this such as RTC for
> the core and CTR for extensions and so on but I think that just leads to
> more confusion.  We should likely pick our poison. I see strong benefits in
> both directions and so I can deal either way personally.  I see a couple
> strong arguments here in this thread already for RTC .
> 
> Anyone willing to argue for CTR?
> 
> Thanks
> Joe
> 
> 
> On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <bi...@gmail.com>
> wrote:
> 
>> It seems to me, and this is purely opinion, that RTC has a lot to be said
>> for a new project, in terms of getting more people involved, more eyeballs,
>> and more of a community feeling. My dayjob workflow is 'make branch, submit
>> pr, get review, merge' and that seems pretty applicable. However, I am not
>> wearing any magic mentor hat-o-authority.
>> 
>>> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org> wrote:
>>> 
>>>> On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
>>>> 
>>>> Benson - thanks for the headsup on the maven plugin.  Seems like using
>>> them
>>>> to their fullest capability and then manually merging to master is
>>>> perfectly fine to me.
>>>> 
>>>> Billie
>>>> As for CTR i don't think i have a good enough appreciation for the
>>>> process/value proposition here.  Curious of other folks views.
>>> 
>>> Both CTR and RTC have their own advantages, so either would be fine (
>>> http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
>>> retrospect I see my question could be viewed as leaning towards CTR, but
>> it
>>> was just based on an observation that people already seemed to be making
>>> commits without review.
>>> 
>>> 
>>>> 
>>>> It seems reasonable to keep the feature branch relaxed and in that
>> sense
>>>> what Gilman did today seems fine.  We can get bettter at those
>> judgement
>>>> calls and documenting the criteria as we go along.
>>>> 
>>>> Thanks
>>>> Joe
>>>> 
>>>> 
>>>> 
>>>> On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
>> bimargulies@gmail.com
>>>> 
>>>> wrote:
>>>> 
>>>>> PR's are certainly convenient. There's no much difference, for a
>>>> committer,
>>>>> between pushing a branch to the official repo and pushing a branch to
>>>> some
>>>>> personal repo on github. The same integration workflow can be used
>>> either
>>>>> way to close out the PR upon merge.
>>>>> 
>>>>> However, in a CTR project, it seems perhaps excessive to _require_
>>>> feature
>>>>> branches for small fixes as opposed to just committing them directly
>> to
>>>>> develop. At day job we do mostly do branch-per-jira, but some people
>>>> might
>>>>> find that onerous.
>>>>> 
>>>>> Pushing to the official repo leaves more history that someone might
>>> find
>>>>> interesting some day. Also more clutter; some people are very
>> concerned
>>>>> about repacking before merging to develop.
>>>>> 
>>>>> Another issue with gitflow is the master branch. The master branch is
>>>>> supposed to get merged to for releases. The maven-release-plugin
>> won't
>>> do
>>>>> that, and the jgitflow plugin is unsafe. So one option is to 'use
>>>> gitflow'
>>>>> but not bother with the master versus develop distinction, the other
>> is
>>>> to
>>>>> do manual merges to master at release points.
>>>>> 
>>>>> 
>>>>> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
>> wrote:
>>>>> 
>>>>>> Hello
>>>>>> 
>>>>>> So a question on gitflow given that commits are now underway.  When
>>>>> working
>>>>>> on a feature in a local repo which is a branch off the develop
>>>>> branch...do
>>>>>> you push the feature branch to the central repo?  This then can be
>>>> merged
>>>>>> by someone else as a sort of code review/pull process?
>>>>>> 
>>>>>> Thanks
>>>>>> Joe
>>>>>> 
>>>>>> On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
>>> wrote:
>>>>>> 
>>>>>>> All,
>>>>>>> 
>>>>>>> Now that we have our code up it is important to establish a
>> process
>>>>>> around
>>>>>>> git in particular.  A general consensus in the thread appears to
>> be
>>>>> that
>>>>>>> gitflow workflow is a reasonable option.
>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>>>>>>> 
>>>>>>> To that end I've added a develop branch off of master from which
>>>>> features
>>>>>>> can be built.  As we converge toward a release then we'll
>>>>>> address/introduce
>>>>>>> some of the other aspects of gitflow.
>>>>>>> 
>>>>>>> Please discuss/comment if there are views that we should be
>> taking
>>>>>> another
>>>>>>> path.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>> 
>>>>>>> On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
>>>>> bimargulies@gmail.com
>>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
>>>> wikier@apache.org>
>>>>>>>> wrote:
>>>>>>>>> Hi Adam,
>>>>>>>>> 
>>>>>>>>> one remarks about this:
>>>>>>>>> 
>>>>>>>>>> On 28/11/14 18:07, Adam Taft wrote:
>>>>>>>>>> 
>>>>>>>>>> Knowing how we work today, if it were me, I would suggest
>> using
>>>> the
>>>>>>>> above
>>>>>>>>>> workflow combined with the "forking workflow" to guard access
>>> to
>>>>> the
>>>>>>>>>> production release (master) branches.  A very small subset of
>>> the
>>>>>>>>>> incubator's commiters should have the ability to merge the
>>>>> "develop"
>>>>>>>>>> branch
>>>>>>>>>> down to a master "release" branch.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Suck workflow is not in place in ASF. On the one hand, the
>>> current
>>>>> git
>>>>>>>>> infrastructure does not provide such branches' management,
>> like
>>>>>>>>> bitbucket/stash do for instance. On the other hand, and more
>>>>>> important,
>>>>>>>> a
>>>>>>>>> project is not hierarchical organization, but a a meritocratic
>>>> one.
>>>>>>>>> 
>>>>>>>>> I recommend you this blog post in case you want to read a bit
>>>> more:
>> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
>>>>>>>>> 
>>>>>>>>> If someone has permissions to do (i.e., he is a committer), he
>>> can
>>>>> do
>>>>>>>> it,
>>>>>>>>> simple The tool provide you instruments to revert those
>> changes
>>> in
>>>>>> case
>>>>>>>> on
>>>>>>>>> involuntary errors.
>>>>>>>>> 
>>>>>>>>>> It would be ideal to have someone who
>>>>>>>>>> is NOT performing the majority of changes on the "develop"
>>> branch
>>>>>> take
>>>>>>>>>> this
>>>>>>>>>> role to coordinate releases, ensure minimal coding standards,
>>> run
>>>>>>>> through
>>>>>>>>>> unit and integration tests, before signing off on the release
>>> and
>>>>>>>> issuing
>>>>>>>>>> the release artifacts.
>>>>>>>> 
>>>>>>>> You seem to be imagining an individual with a job which is
>> shared
>>> in
>>>>>>>> by the community. In healthy communities, a release happens when
>>>>>>>> there's a consensus to have a release. There is no person who
>>>> 'ensures
>>>>>>>> minimal coding standards', that's everyone watching commits.
>>> There's
>>>>>>>> no one 'running unit and integration tests' because (a) every
>>>>>>>> committer does this before every commit, (b) Jenkins does it,
>> (c)
>>>> the
>>>>>>>> release process does it. (d) there's no signing off on a
>> release.
>>>> The
>>>>>>>> RM puts it up for a vote, and PMC members vote.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Release comes after that. The release manager is responsible
>> on
>>>>>>>> creating a
>>>>>>>>> proper release, which must include a code release and should
>>>> include
>>>>>>>>> binaries too. Each artifact release must be signed.
>> Demonstrate
>>>> your
>>>>>>>> ability
>>>>>>>>> as a project to produce releases is one of the goals of the
>>>>>> incubation.
>>>>>>>> But
>>>>>>>>> we are not yet there, step by step.
>>>>>>>>> 
>>>>>>>>> Hope that helps.
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Sergio Fernández
>>>>>>>>> Partner Technology Manager
>>>>>>>>> Redlink GmbH
>>>>>>>>> m: +43 660 2747 925
>>>>>>>>> e: sergio.fernandez@redlink.co
>>>>>>>>> w: http://redlink.co
>>

Re: git workflow for nifi

Posted by Matt Gilman <ma...@gmail.com>.

Based on these comments I would also like to +1 RTC. As Sean pointed out,
it seems like the best approach to promote our two most important
objectives - regular quality software releases and growing a healthy
community.

On Wed, Dec 10, 2014 at 10:47 PM, Sean Busbey <bu...@cloudera.com> wrote:

> On Wed, Dec 10, 2014 at 8:18 PM, Joe Witt <jo...@gmail.com> wrote:
>
> >
> >
> > - What constitutes a valid review?
> > This page
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > suggests that a review is a consensus approval.  I am very concerned by
> > that definition if we're talking every commit means we need a vote.  For
> > the vast majority of commits this just seems to onerous and too time
> > consuming and frankly to me takes some of the fun out of developing.  If
> > for us a review is simply that a 'committer' has reviewed the code then I
> > am perfectly happy with this and I am thinking this is in-line with the
> > model Benson described for his dayjob "'make branch, submit pr, get
> review,
> > merge'"
> >
> >
> One point of clarification here. On the RtC ASF projects I've been on, the
> review votes are called "consensus" because a -1 is a binding veto, not
> because a formal VOTE is needed. The number of binding +1s has varied as
> well. Rather than the ASF defined three +1s, generally only one is needed.
> So long as we agree as a community on the number, it probably is not of
> much consequence long term.
>
> --
> Sean
>

Re: git workflow for nifi

Posted by Sean Busbey <bu...@cloudera.com>.

On Wed, Dec 10, 2014 at 8:18 PM, Joe Witt <jo...@gmail.com> wrote:

>
>
> - What constitutes a valid review?
> This page http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> suggests that a review is a consensus approval.  I am very concerned by
> that definition if we're talking every commit means we need a vote.  For
> the vast majority of commits this just seems to onerous and too time
> consuming and frankly to me takes some of the fun out of developing.  If
> for us a review is simply that a 'committer' has reviewed the code then I
> am perfectly happy with this and I am thinking this is in-line with the
> model Benson described for his dayjob "'make branch, submit pr, get review,
> merge'"
>
>
One point of clarification here. On the RtC ASF projects I've been on, the
review votes are called "consensus" because a -1 is a binding veto, not
because a formal VOTE is needed. The number of binding +1s has varied as
well. Rather than the ASF defined three +1s, generally only one is needed.
So long as we agree as a community on the number, it probably is not of
much consequence long term.

-- 
Sean

Re: git workflow for nifi

Posted by Jason Carey <jc...@gmail.com>.

Basically, echoing the themes.  My experience has been very favorable
when I'm taking part in code reviews prior to a commit to the main
development branch.  Good discussions happen and better code is
ultimately committed.  Velocity of commits may be less, but there is
more control and collective ownership.  With that said, I think
waiting for any type of consensus amongst committers is unreasonable.

A strong +1 for RTC.

Thanks,
Jason

On Wed, Dec 10, 2014 at 6:44 PM, Joe Witt <jo...@gmail.com> wrote:
> If RTC means what Joey just wrote then I am a strong +1 on this.  Though I
> am very curious to see if there are any strong CTR arguments.
>
> On Wed, Dec 10, 2014 at 9:38 PM, Joey Echeverria <jo...@cloudera.com> wrote:
>
>> > - What constitutes a valid review?
>>
>> I think the community will get to decide, but what I've seen in other
>> projects is there has to be a +1 from a committer on the project. The
>> +1 can be a comment in JIRA, clicking the ship it button in Review
>> Board, or any other method where the +1 has been recorded in ASF
>> infrastructure. For something like Hadoop, this has been fairly formal
>> with a +1 needing to happen in JIRA before something can be committed.
>> I know Parquet uses pull requests, but I'm not sure if they allow +1's
>> to just be comments in github or if they need to also be provided in
>> the JIRA.
>>
>> My general belief is that either JIRA or a review tool is fine.
>> Generally, a formal vote isn't required for a review and would only be
>> needed if a committer has vetoed a change and consensus can't be
>> reached through the normal review back and forth.
>>
>>
>> > - What is the best tooling/process around this to actually
>> conduct/document
>> > the review?
>>
>> There are two things you typically want, a standard for how
>> code/patches are submitted. Going down to the what git commands to run
>> to format the patch is very useful as each project is a little
>> different. If we're able to use pull requests, then that's less
>> critical as the pull request will handle those details. The second is
>> where to do the review comments themselves. I really like tools like
>> Review Board or GitHub's pull request review interface. Having a web
>> based way of providing per-line comments makes things flow much more
>> easily than comments in JIRA or mailing list discussions.
>>
>> > - What are some key things a reviewer should be checking for and helping
>> to
>> > enforce?  What are some out of bounds things?
>>
>> There are two things that the reviewer should be focusing on. How will
>> this change improve the project and how can I help mentor the
>> contributor to generally improve the quality of their contributions.
>> That means that anything is in scope, but the focus of the review
>> should always be on how to guide the contributor to make the best
>> improvement to the project. If we want to adopt formal code style
>> guidelines, then we should document those and ideally have automated
>> ways of checking those (checkstyle, etc.) so that contributors can
>> verify for themselves rather than have to wait for review feedback.
>>
>> Generally a veto on a code change requires a "valid technical reason".
>> I think the community has to decide what falls under that definition.
>> In my head it would include things like: introduces a security hole,
>> introduces a major performance regression, or violates or
>> compatibility guidelines for the release that it's targeting.
>>
>> -Joey
>>
>> On Wed, Dec 10, 2014 at 6:18 PM, Joe Witt <jo...@gmail.com> wrote:
>> > NiFi grew up in a CT[R] environment where the review was very rare and so
>> > really we ended up with CTDTFSOR - Commit then deploy then feel sense of
>> > regret.
>> >
>> > So the bad side: We ended up with a lot of avoidable defects where by
>> > avoidable I mean they could have likely been detected in a decent review
>> > effort.
>> >
>> > The good side: We were fast.  Very fast.  New features got out quick and
>> if
>> > something was funky we fixed it very fast.  For the vast majority of
>> > mistakes the problem was highly isolated (thanks to our base design
>> > construct of FBP) and rarely caused extremely stressful days.
>> >
>> > On balance though and given the benefits it has to community growth I
>> > personally am very supportive of us adopting RTC immediately provided we
>> > can sort out some key questions:
>> >
>> > - What constitutes a valid review?
>> > This page
>> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
>> > suggests that a review is a consensus approval.  I am very concerned by
>> > that definition if we're talking every commit means we need a vote.  For
>> > the vast majority of commits this just seems to onerous and too time
>> > consuming and frankly to me takes some of the fun out of developing.  If
>> > for us a review is simply that a 'committer' has reviewed the code then I
>> > am perfectly happy with this and I am thinking this is in-line with the
>> > model Benson described for his dayjob "'make branch, submit pr, get
>> review,
>> > merge'"
>> >
>> > - What is the best tooling/process around this to actually
>> conduct/document
>> > the review?
>> > I think
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
>> > does a good job of describing the mechanics of a review/submission
>> > process.  And I'd just assume a patch is as good as a pull request.  I
>> > think even as a good starting point having the JIRA ticket commented on
>> by
>> > the reviewer would be good.
>> >
>> > - What are some key things a reviewer should be checking for and helping
>> to
>> > enforce?  What are some out of bounds things?
>> >
>> >
>> >
>> > This seems like a really important discussion and something that we
>> should
>> > center on sooner than later.  There are ways to nuance this such as RTC
>> for
>> > the core and CTR for extensions and so on but I think that just leads to
>> > more confusion.  We should likely pick our poison. I see strong benefits
>> in
>> > both directions and so I can deal either way personally.  I see a couple
>> > strong arguments here in this thread already for RTC .
>> >
>> > Anyone willing to argue for CTR?
>> >
>> > Thanks
>> > Joe
>> >
>> >
>> > On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <bimargulies@gmail.com
>> >
>> > wrote:
>> >
>> >> It seems to me, and this is purely opinion, that RTC has a lot to be
>> said
>> >> for a new project, in terms of getting more people involved, more
>> eyeballs,
>> >> and more of a community feeling. My dayjob workflow is 'make branch,
>> submit
>> >> pr, get review, merge' and that seems pretty applicable. However, I am
>> not
>> >> wearing any magic mentor hat-o-authority.
>> >>
>> >> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org>
>> wrote:
>> >>
>> >> > On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
>> >> >
>> >> > > Benson - thanks for the headsup on the maven plugin.  Seems like
>> using
>> >> > them
>> >> > > to their fullest capability and then manually merging to master is
>> >> > > perfectly fine to me.
>> >> > >
>> >> > > Billie
>> >> > > As for CTR i don't think i have a good enough appreciation for the
>> >> > > process/value proposition here.  Curious of other folks views.
>> >> > >
>> >> >
>> >> > Both CTR and RTC have their own advantages, so either would be fine (
>> >> > http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
>> >> > retrospect I see my question could be viewed as leaning towards CTR,
>> but
>> >> it
>> >> > was just based on an observation that people already seemed to be
>> making
>> >> > commits without review.
>> >> >
>> >> >
>> >> > >
>> >> > > It seems reasonable to keep the feature branch relaxed and in that
>> >> sense
>> >> > > what Gilman did today seems fine.  We can get bettter at those
>> >> judgement
>> >> > > calls and documenting the criteria as we go along.
>> >> > >
>> >> > > Thanks
>> >> > > Joe
>> >> > >
>> >> > >
>> >> > >
>> >> > > On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
>> >> bimargulies@gmail.com
>> >> > >
>> >> > > wrote:
>> >> > >
>> >> > > > PR's are certainly convenient. There's no much difference, for a
>> >> > > committer,
>> >> > > > between pushing a branch to the official repo and pushing a
>> branch to
>> >> > > some
>> >> > > > personal repo on github. The same integration workflow can be used
>> >> > either
>> >> > > > way to close out the PR upon merge.
>> >> > > >
>> >> > > > However, in a CTR project, it seems perhaps excessive to _require_
>> >> > > feature
>> >> > > > branches for small fixes as opposed to just committing them
>> directly
>> >> to
>> >> > > > develop. At day job we do mostly do branch-per-jira, but some
>> people
>> >> > > might
>> >> > > > find that onerous.
>> >> > > >
>> >> > > > Pushing to the official repo leaves more history that someone
>> might
>> >> > find
>> >> > > > interesting some day. Also more clutter; some people are very
>> >> concerned
>> >> > > > about repacking before merging to develop.
>> >> > > >
>> >> > > > Another issue with gitflow is the master branch. The master
>> branch is
>> >> > > > supposed to get merged to for releases. The maven-release-plugin
>> >> won't
>> >> > do
>> >> > > > that, and the jgitflow plugin is unsafe. So one option is to 'use
>> >> > > gitflow'
>> >> > > > but not bother with the master versus develop distinction, the
>> other
>> >> is
>> >> > > to
>> >> > > > do manual merges to master at release points.
>> >> > > >
>> >> > > >
>> >> > > > On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
>> >> wrote:
>> >> > > >
>> >> > > > > Hello
>> >> > > > >
>> >> > > > > So a question on gitflow given that commits are now underway.
>> When
>> >> > > > working
>> >> > > > > on a feature in a local repo which is a branch off the develop
>> >> > > > branch...do
>> >> > > > > you push the feature branch to the central repo?  This then can
>> be
>> >> > > merged
>> >> > > > > by someone else as a sort of code review/pull process?
>> >> > > > >
>> >> > > > > Thanks
>> >> > > > > Joe
>> >> > > > >
>> >> > > > > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
>> >> > wrote:
>> >> > > > >
>> >> > > > > > All,
>> >> > > > > >
>> >> > > > > > Now that we have our code up it is important to establish a
>> >> process
>> >> > > > > around
>> >> > > > > > git in particular.  A general consensus in the thread appears
>> to
>> >> be
>> >> > > > that
>> >> > > > > > gitflow workflow is a reasonable option.
>> >> > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>> >> > > > > >
>> >> > > > > > To that end I've added a develop branch off of master from
>> which
>> >> > > > features
>> >> > > > > > can be built.  As we converge toward a release then we'll
>> >> > > > > address/introduce
>> >> > > > > > some of the other aspects of gitflow.
>> >> > > > > >
>> >> > > > > > Please discuss/comment if there are views that we should be
>> >> taking
>> >> > > > > another
>> >> > > > > > path.
>> >> > > > > >
>> >> > > > > > Thanks
>> >> > > > > > Joe
>> >> > > > > >
>> >> > > > > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
>> >> > > > bimargulies@gmail.com
>> >> > > > > >
>> >> > > > > > wrote:
>> >> > > > > >
>> >> > > > > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
>> >> > > wikier@apache.org>
>> >> > > > > >> wrote:
>> >> > > > > >> > Hi Adam,
>> >> > > > > >> >
>> >> > > > > >> > one remarks about this:
>> >> > > > > >> >
>> >> > > > > >> > On 28/11/14 18:07, Adam Taft wrote:
>> >> > > > > >> >>
>> >> > > > > >> >> Knowing how we work today, if it were me, I would suggest
>> >> using
>> >> > > the
>> >> > > > > >> above
>> >> > > > > >> >> workflow combined with the "forking workflow" to guard
>> access
>> >> > to
>> >> > > > the
>> >> > > > > >> >> production release (master) branches.  A very small
>> subset of
>> >> > the
>> >> > > > > >> >> incubator's commiters should have the ability to merge the
>> >> > > > "develop"
>> >> > > > > >> >> branch
>> >> > > > > >> >> down to a master "release" branch.
>> >> > > > > >> >
>> >> > > > > >> >
>> >> > > > > >> > Suck workflow is not in place in ASF. On the one hand, the
>> >> > current
>> >> > > > git
>> >> > > > > >> > infrastructure does not provide such branches' management,
>> >> like
>> >> > > > > >> > bitbucket/stash do for instance. On the other hand, and
>> more
>> >> > > > > important,
>> >> > > > > >> a
>> >> > > > > >> > project is not hierarchical organization, but a a
>> meritocratic
>> >> > > one.
>> >> > > > > >> >
>> >> > > > > >> > I recommend you this blog post in case you want to read a
>> bit
>> >> > > more:
>> >> > > > > >> >
>> >> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
>> >> > > > > >> >
>> >> > > > > >> > If someone has permissions to do (i.e., he is a
>> committer), he
>> >> > can
>> >> > > > do
>> >> > > > > >> it,
>> >> > > > > >> > simple The tool provide you instruments to revert those
>> >> changes
>> >> > in
>> >> > > > > case
>> >> > > > > >> on
>> >> > > > > >> > involuntary errors.
>> >> > > > > >> >
>> >> > > > > >> >>  It would be ideal to have someone who
>> >> > > > > >> >> is NOT performing the majority of changes on the "develop"
>> >> > branch
>> >> > > > > take
>> >> > > > > >> >> this
>> >> > > > > >> >> role to coordinate releases, ensure minimal coding
>> standards,
>> >> > run
>> >> > > > > >> through
>> >> > > > > >> >> unit and integration tests, before signing off on the
>> release
>> >> > and
>> >> > > > > >> issuing
>> >> > > > > >> >> the release artifacts.
>> >> > > > > >>
>> >> > > > > >> You seem to be imagining an individual with a job which is
>> >> shared
>> >> > in
>> >> > > > > >> by the community. In healthy communities, a release happens
>> when
>> >> > > > > >> there's a consensus to have a release. There is no person who
>> >> > > 'ensures
>> >> > > > > >> minimal coding standards', that's everyone watching commits.
>> >> > There's
>> >> > > > > >> no one 'running unit and integration tests' because (a) every
>> >> > > > > >> committer does this before every commit, (b) Jenkins does it,
>> >> (c)
>> >> > > the
>> >> > > > > >> release process does it. (d) there's no signing off on a
>> >> release.
>> >> > > The
>> >> > > > > >> RM puts it up for a vote, and PMC members vote.
>> >> > > > > >>
>> >> > > > > >>
>> >> > > > > >> >
>> >> > > > > >> >
>> >> > > > > >> > Release comes after that. The release manager is
>> responsible
>> >> on
>> >> > > > > >> creating a
>> >> > > > > >> > proper release, which must include a code release and
>> should
>> >> > > include
>> >> > > > > >> > binaries too. Each artifact release must be signed.
>> >> Demonstrate
>> >> > > your
>> >> > > > > >> ability
>> >> > > > > >> > as a project to produce releases is one of the goals of the
>> >> > > > > incubation.
>> >> > > > > >> But
>> >> > > > > >> > we are not yet there, step by step.
>> >> > > > > >> >
>> >> > > > > >> > Hope that helps.
>> >> > > > > >> >
>> >> > > > > >> > Cheers,
>> >> > > > > >> >
>> >> > > > > >> >
>> >> > > > > >> > --
>> >> > > > > >> > Sergio Fernández
>> >> > > > > >> > Partner Technology Manager
>> >> > > > > >> > Redlink GmbH
>> >> > > > > >> > m: +43 660 2747 925
>> >> > > > > >> > e: sergio.fernandez@redlink.co
>> >> > > > > >> > w: http://redlink.co
>> >> > > > > >>
>> >> > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>>
>>
>> --
>> Joey Echeverria
>>

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

If RTC means what Joey just wrote then I am a strong +1 on this.  Though I
am very curious to see if there are any strong CTR arguments.

On Wed, Dec 10, 2014 at 9:38 PM, Joey Echeverria <jo...@cloudera.com> wrote:

> > - What constitutes a valid review?
>
> I think the community will get to decide, but what I've seen in other
> projects is there has to be a +1 from a committer on the project. The
> +1 can be a comment in JIRA, clicking the ship it button in Review
> Board, or any other method where the +1 has been recorded in ASF
> infrastructure. For something like Hadoop, this has been fairly formal
> with a +1 needing to happen in JIRA before something can be committed.
> I know Parquet uses pull requests, but I'm not sure if they allow +1's
> to just be comments in github or if they need to also be provided in
> the JIRA.
>
> My general belief is that either JIRA or a review tool is fine.
> Generally, a formal vote isn't required for a review and would only be
> needed if a committer has vetoed a change and consensus can't be
> reached through the normal review back and forth.
>
>
> > - What is the best tooling/process around this to actually
> conduct/document
> > the review?
>
> There are two things you typically want, a standard for how
> code/patches are submitted. Going down to the what git commands to run
> to format the patch is very useful as each project is a little
> different. If we're able to use pull requests, then that's less
> critical as the pull request will handle those details. The second is
> where to do the review comments themselves. I really like tools like
> Review Board or GitHub's pull request review interface. Having a web
> based way of providing per-line comments makes things flow much more
> easily than comments in JIRA or mailing list discussions.
>
> > - What are some key things a reviewer should be checking for and helping
> to
> > enforce?  What are some out of bounds things?
>
> There are two things that the reviewer should be focusing on. How will
> this change improve the project and how can I help mentor the
> contributor to generally improve the quality of their contributions.
> That means that anything is in scope, but the focus of the review
> should always be on how to guide the contributor to make the best
> improvement to the project. If we want to adopt formal code style
> guidelines, then we should document those and ideally have automated
> ways of checking those (checkstyle, etc.) so that contributors can
> verify for themselves rather than have to wait for review feedback.
>
> Generally a veto on a code change requires a "valid technical reason".
> I think the community has to decide what falls under that definition.
> In my head it would include things like: introduces a security hole,
> introduces a major performance regression, or violates or
> compatibility guidelines for the release that it's targeting.
>
> -Joey
>
> On Wed, Dec 10, 2014 at 6:18 PM, Joe Witt <jo...@gmail.com> wrote:
> > NiFi grew up in a CT[R] environment where the review was very rare and so
> > really we ended up with CTDTFSOR - Commit then deploy then feel sense of
> > regret.
> >
> > So the bad side: We ended up with a lot of avoidable defects where by
> > avoidable I mean they could have likely been detected in a decent review
> > effort.
> >
> > The good side: We were fast.  Very fast.  New features got out quick and
> if
> > something was funky we fixed it very fast.  For the vast majority of
> > mistakes the problem was highly isolated (thanks to our base design
> > construct of FBP) and rarely caused extremely stressful days.
> >
> > On balance though and given the benefits it has to community growth I
> > personally am very supportive of us adopting RTC immediately provided we
> > can sort out some key questions:
> >
> > - What constitutes a valid review?
> > This page
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > suggests that a review is a consensus approval.  I am very concerned by
> > that definition if we're talking every commit means we need a vote.  For
> > the vast majority of commits this just seems to onerous and too time
> > consuming and frankly to me takes some of the fun out of developing.  If
> > for us a review is simply that a 'committer' has reviewed the code then I
> > am perfectly happy with this and I am thinking this is in-line with the
> > model Benson described for his dayjob "'make branch, submit pr, get
> review,
> > merge'"
> >
> > - What is the best tooling/process around this to actually
> conduct/document
> > the review?
> > I think
> >
> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
> > does a good job of describing the mechanics of a review/submission
> > process.  And I'd just assume a patch is as good as a pull request.  I
> > think even as a good starting point having the JIRA ticket commented on
> by
> > the reviewer would be good.
> >
> > - What are some key things a reviewer should be checking for and helping
> to
> > enforce?  What are some out of bounds things?
> >
> >
> >
> > This seems like a really important discussion and something that we
> should
> > center on sooner than later.  There are ways to nuance this such as RTC
> for
> > the core and CTR for extensions and so on but I think that just leads to
> > more confusion.  We should likely pick our poison. I see strong benefits
> in
> > both directions and so I can deal either way personally.  I see a couple
> > strong arguments here in this thread already for RTC .
> >
> > Anyone willing to argue for CTR?
> >
> > Thanks
> > Joe
> >
> >
> > On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <bimargulies@gmail.com
> >
> > wrote:
> >
> >> It seems to me, and this is purely opinion, that RTC has a lot to be
> said
> >> for a new project, in terms of getting more people involved, more
> eyeballs,
> >> and more of a community feeling. My dayjob workflow is 'make branch,
> submit
> >> pr, get review, merge' and that seems pretty applicable. However, I am
> not
> >> wearing any magic mentor hat-o-authority.
> >>
> >> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org>
> wrote:
> >>
> >> > On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
> >> >
> >> > > Benson - thanks for the headsup on the maven plugin.  Seems like
> using
> >> > them
> >> > > to their fullest capability and then manually merging to master is
> >> > > perfectly fine to me.
> >> > >
> >> > > Billie
> >> > > As for CTR i don't think i have a good enough appreciation for the
> >> > > process/value proposition here.  Curious of other folks views.
> >> > >
> >> >
> >> > Both CTR and RTC have their own advantages, so either would be fine (
> >> > http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
> >> > retrospect I see my question could be viewed as leaning towards CTR,
> but
> >> it
> >> > was just based on an observation that people already seemed to be
> making
> >> > commits without review.
> >> >
> >> >
> >> > >
> >> > > It seems reasonable to keep the feature branch relaxed and in that
> >> sense
> >> > > what Gilman did today seems fine.  We can get bettter at those
> >> judgement
> >> > > calls and documenting the criteria as we go along.
> >> > >
> >> > > Thanks
> >> > > Joe
> >> > >
> >> > >
> >> > >
> >> > > On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
> >> bimargulies@gmail.com
> >> > >
> >> > > wrote:
> >> > >
> >> > > > PR's are certainly convenient. There's no much difference, for a
> >> > > committer,
> >> > > > between pushing a branch to the official repo and pushing a
> branch to
> >> > > some
> >> > > > personal repo on github. The same integration workflow can be used
> >> > either
> >> > > > way to close out the PR upon merge.
> >> > > >
> >> > > > However, in a CTR project, it seems perhaps excessive to _require_
> >> > > feature
> >> > > > branches for small fixes as opposed to just committing them
> directly
> >> to
> >> > > > develop. At day job we do mostly do branch-per-jira, but some
> people
> >> > > might
> >> > > > find that onerous.
> >> > > >
> >> > > > Pushing to the official repo leaves more history that someone
> might
> >> > find
> >> > > > interesting some day. Also more clutter; some people are very
> >> concerned
> >> > > > about repacking before merging to develop.
> >> > > >
> >> > > > Another issue with gitflow is the master branch. The master
> branch is
> >> > > > supposed to get merged to for releases. The maven-release-plugin
> >> won't
> >> > do
> >> > > > that, and the jgitflow plugin is unsafe. So one option is to 'use
> >> > > gitflow'
> >> > > > but not bother with the master versus develop distinction, the
> other
> >> is
> >> > > to
> >> > > > do manual merges to master at release points.
> >> > > >
> >> > > >
> >> > > > On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
> >> wrote:
> >> > > >
> >> > > > > Hello
> >> > > > >
> >> > > > > So a question on gitflow given that commits are now underway.
> When
> >> > > > working
> >> > > > > on a feature in a local repo which is a branch off the develop
> >> > > > branch...do
> >> > > > > you push the feature branch to the central repo?  This then can
> be
> >> > > merged
> >> > > > > by someone else as a sort of code review/pull process?
> >> > > > >
> >> > > > > Thanks
> >> > > > > Joe
> >> > > > >
> >> > > > > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
> >> > wrote:
> >> > > > >
> >> > > > > > All,
> >> > > > > >
> >> > > > > > Now that we have our code up it is important to establish a
> >> process
> >> > > > > around
> >> > > > > > git in particular.  A general consensus in the thread appears
> to
> >> be
> >> > > > that
> >> > > > > > gitflow workflow is a reasonable option.
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> >> > > > > >
> >> > > > > > To that end I've added a develop branch off of master from
> which
> >> > > > features
> >> > > > > > can be built.  As we converge toward a release then we'll
> >> > > > > address/introduce
> >> > > > > > some of the other aspects of gitflow.
> >> > > > > >
> >> > > > > > Please discuss/comment if there are views that we should be
> >> taking
> >> > > > > another
> >> > > > > > path.
> >> > > > > >
> >> > > > > > Thanks
> >> > > > > > Joe
> >> > > > > >
> >> > > > > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> >> > > > bimargulies@gmail.com
> >> > > > > >
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> >> > > wikier@apache.org>
> >> > > > > >> wrote:
> >> > > > > >> > Hi Adam,
> >> > > > > >> >
> >> > > > > >> > one remarks about this:
> >> > > > > >> >
> >> > > > > >> > On 28/11/14 18:07, Adam Taft wrote:
> >> > > > > >> >>
> >> > > > > >> >> Knowing how we work today, if it were me, I would suggest
> >> using
> >> > > the
> >> > > > > >> above
> >> > > > > >> >> workflow combined with the "forking workflow" to guard
> access
> >> > to
> >> > > > the
> >> > > > > >> >> production release (master) branches.  A very small
> subset of
> >> > the
> >> > > > > >> >> incubator's commiters should have the ability to merge the
> >> > > > "develop"
> >> > > > > >> >> branch
> >> > > > > >> >> down to a master "release" branch.
> >> > > > > >> >
> >> > > > > >> >
> >> > > > > >> > Suck workflow is not in place in ASF. On the one hand, the
> >> > current
> >> > > > git
> >> > > > > >> > infrastructure does not provide such branches' management,
> >> like
> >> > > > > >> > bitbucket/stash do for instance. On the other hand, and
> more
> >> > > > > important,
> >> > > > > >> a
> >> > > > > >> > project is not hierarchical organization, but a a
> meritocratic
> >> > > one.
> >> > > > > >> >
> >> > > > > >> > I recommend you this blog post in case you want to read a
> bit
> >> > > more:
> >> > > > > >> >
> >> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> >> > > > > >> >
> >> > > > > >> > If someone has permissions to do (i.e., he is a
> committer), he
> >> > can
> >> > > > do
> >> > > > > >> it,
> >> > > > > >> > simple The tool provide you instruments to revert those
> >> changes
> >> > in
> >> > > > > case
> >> > > > > >> on
> >> > > > > >> > involuntary errors.
> >> > > > > >> >
> >> > > > > >> >>  It would be ideal to have someone who
> >> > > > > >> >> is NOT performing the majority of changes on the "develop"
> >> > branch
> >> > > > > take
> >> > > > > >> >> this
> >> > > > > >> >> role to coordinate releases, ensure minimal coding
> standards,
> >> > run
> >> > > > > >> through
> >> > > > > >> >> unit and integration tests, before signing off on the
> release
> >> > and
> >> > > > > >> issuing
> >> > > > > >> >> the release artifacts.
> >> > > > > >>
> >> > > > > >> You seem to be imagining an individual with a job which is
> >> shared
> >> > in
> >> > > > > >> by the community. In healthy communities, a release happens
> when
> >> > > > > >> there's a consensus to have a release. There is no person who
> >> > > 'ensures
> >> > > > > >> minimal coding standards', that's everyone watching commits.
> >> > There's
> >> > > > > >> no one 'running unit and integration tests' because (a) every
> >> > > > > >> committer does this before every commit, (b) Jenkins does it,
> >> (c)
> >> > > the
> >> > > > > >> release process does it. (d) there's no signing off on a
> >> release.
> >> > > The
> >> > > > > >> RM puts it up for a vote, and PMC members vote.
> >> > > > > >>
> >> > > > > >>
> >> > > > > >> >
> >> > > > > >> >
> >> > > > > >> > Release comes after that. The release manager is
> responsible
> >> on
> >> > > > > >> creating a
> >> > > > > >> > proper release, which must include a code release and
> should
> >> > > include
> >> > > > > >> > binaries too. Each artifact release must be signed.
> >> Demonstrate
> >> > > your
> >> > > > > >> ability
> >> > > > > >> > as a project to produce releases is one of the goals of the
> >> > > > > incubation.
> >> > > > > >> But
> >> > > > > >> > we are not yet there, step by step.
> >> > > > > >> >
> >> > > > > >> > Hope that helps.
> >> > > > > >> >
> >> > > > > >> > Cheers,
> >> > > > > >> >
> >> > > > > >> >
> >> > > > > >> > --
> >> > > > > >> > Sergio Fernández
> >> > > > > >> > Partner Technology Manager
> >> > > > > >> > Redlink GmbH
> >> > > > > >> > m: +43 660 2747 925
> >> > > > > >> > e: sergio.fernandez@redlink.co
> >> > > > > >> > w: http://redlink.co
> >> > > > > >>
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
>
>
> --
> Joey Echeverria
>

Re: git workflow for nifi

Posted by Joey Echeverria <jo...@cloudera.com>.

> - What constitutes a valid review?

I think the community will get to decide, but what I've seen in other
projects is there has to be a +1 from a committer on the project. The
+1 can be a comment in JIRA, clicking the ship it button in Review
Board, or any other method where the +1 has been recorded in ASF
infrastructure. For something like Hadoop, this has been fairly formal
with a +1 needing to happen in JIRA before something can be committed.
I know Parquet uses pull requests, but I'm not sure if they allow +1's
to just be comments in github or if they need to also be provided in
the JIRA.

My general belief is that either JIRA or a review tool is fine.
Generally, a formal vote isn't required for a review and would only be
needed if a committer has vetoed a change and consensus can't be
reached through the normal review back and forth.


> - What is the best tooling/process around this to actually conduct/document
> the review?

There are two things you typically want, a standard for how
code/patches are submitted. Going down to the what git commands to run
to format the patch is very useful as each project is a little
different. If we're able to use pull requests, then that's less
critical as the pull request will handle those details. The second is
where to do the review comments themselves. I really like tools like
Review Board or GitHub's pull request review interface. Having a web
based way of providing per-line comments makes things flow much more
easily than comments in JIRA or mailing list discussions.

> - What are some key things a reviewer should be checking for and helping to
> enforce?  What are some out of bounds things?

There are two things that the reviewer should be focusing on. How will
this change improve the project and how can I help mentor the
contributor to generally improve the quality of their contributions.
That means that anything is in scope, but the focus of the review
should always be on how to guide the contributor to make the best
improvement to the project. If we want to adopt formal code style
guidelines, then we should document those and ideally have automated
ways of checking those (checkstyle, etc.) so that contributors can
verify for themselves rather than have to wait for review feedback.

Generally a veto on a code change requires a "valid technical reason".
I think the community has to decide what falls under that definition.
In my head it would include things like: introduces a security hole,
introduces a major performance regression, or violates or
compatibility guidelines for the release that it's targeting.

-Joey

On Wed, Dec 10, 2014 at 6:18 PM, Joe Witt <jo...@gmail.com> wrote:
> NiFi grew up in a CT[R] environment where the review was very rare and so
> really we ended up with CTDTFSOR - Commit then deploy then feel sense of
> regret.
>
> So the bad side: We ended up with a lot of avoidable defects where by
> avoidable I mean they could have likely been detected in a decent review
> effort.
>
> The good side: We were fast.  Very fast.  New features got out quick and if
> something was funky we fixed it very fast.  For the vast majority of
> mistakes the problem was highly isolated (thanks to our base design
> construct of FBP) and rarely caused extremely stressful days.
>
> On balance though and given the benefits it has to community growth I
> personally am very supportive of us adopting RTC immediately provided we
> can sort out some key questions:
>
> - What constitutes a valid review?
> This page http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> suggests that a review is a consensus approval.  I am very concerned by
> that definition if we're talking every commit means we need a vote.  For
> the vast majority of commits this just seems to onerous and too time
> consuming and frankly to me takes some of the fun out of developing.  If
> for us a review is simply that a 'committer' has reviewed the code then I
> am perfectly happy with this and I am thinking this is in-line with the
> model Benson described for his dayjob "'make branch, submit pr, get review,
> merge'"
>
> - What is the best tooling/process around this to actually conduct/document
> the review?
> I think
> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
> does a good job of describing the mechanics of a review/submission
> process.  And I'd just assume a patch is as good as a pull request.  I
> think even as a good starting point having the JIRA ticket commented on by
> the reviewer would be good.
>
> - What are some key things a reviewer should be checking for and helping to
> enforce?  What are some out of bounds things?
>
>
>
> This seems like a really important discussion and something that we should
> center on sooner than later.  There are ways to nuance this such as RTC for
> the core and CTR for extensions and so on but I think that just leads to
> more confusion.  We should likely pick our poison. I see strong benefits in
> both directions and so I can deal either way personally.  I see a couple
> strong arguments here in this thread already for RTC .
>
> Anyone willing to argue for CTR?
>
> Thanks
> Joe
>
>
> On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <bi...@gmail.com>
> wrote:
>
>> It seems to me, and this is purely opinion, that RTC has a lot to be said
>> for a new project, in terms of getting more people involved, more eyeballs,
>> and more of a community feeling. My dayjob workflow is 'make branch, submit
>> pr, get review, merge' and that seems pretty applicable. However, I am not
>> wearing any magic mentor hat-o-authority.
>>
>> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org> wrote:
>>
>> > On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
>> >
>> > > Benson - thanks for the headsup on the maven plugin.  Seems like using
>> > them
>> > > to their fullest capability and then manually merging to master is
>> > > perfectly fine to me.
>> > >
>> > > Billie
>> > > As for CTR i don't think i have a good enough appreciation for the
>> > > process/value proposition here.  Curious of other folks views.
>> > >
>> >
>> > Both CTR and RTC have their own advantages, so either would be fine (
>> > http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
>> > retrospect I see my question could be viewed as leaning towards CTR, but
>> it
>> > was just based on an observation that people already seemed to be making
>> > commits without review.
>> >
>> >
>> > >
>> > > It seems reasonable to keep the feature branch relaxed and in that
>> sense
>> > > what Gilman did today seems fine.  We can get bettter at those
>> judgement
>> > > calls and documenting the criteria as we go along.
>> > >
>> > > Thanks
>> > > Joe
>> > >
>> > >
>> > >
>> > > On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
>> bimargulies@gmail.com
>> > >
>> > > wrote:
>> > >
>> > > > PR's are certainly convenient. There's no much difference, for a
>> > > committer,
>> > > > between pushing a branch to the official repo and pushing a branch to
>> > > some
>> > > > personal repo on github. The same integration workflow can be used
>> > either
>> > > > way to close out the PR upon merge.
>> > > >
>> > > > However, in a CTR project, it seems perhaps excessive to _require_
>> > > feature
>> > > > branches for small fixes as opposed to just committing them directly
>> to
>> > > > develop. At day job we do mostly do branch-per-jira, but some people
>> > > might
>> > > > find that onerous.
>> > > >
>> > > > Pushing to the official repo leaves more history that someone might
>> > find
>> > > > interesting some day. Also more clutter; some people are very
>> concerned
>> > > > about repacking before merging to develop.
>> > > >
>> > > > Another issue with gitflow is the master branch. The master branch is
>> > > > supposed to get merged to for releases. The maven-release-plugin
>> won't
>> > do
>> > > > that, and the jgitflow plugin is unsafe. So one option is to 'use
>> > > gitflow'
>> > > > but not bother with the master versus develop distinction, the other
>> is
>> > > to
>> > > > do manual merges to master at release points.
>> > > >
>> > > >
>> > > > On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
>> wrote:
>> > > >
>> > > > > Hello
>> > > > >
>> > > > > So a question on gitflow given that commits are now underway.  When
>> > > > working
>> > > > > on a feature in a local repo which is a branch off the develop
>> > > > branch...do
>> > > > > you push the feature branch to the central repo?  This then can be
>> > > merged
>> > > > > by someone else as a sort of code review/pull process?
>> > > > >
>> > > > > Thanks
>> > > > > Joe
>> > > > >
>> > > > > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
>> > wrote:
>> > > > >
>> > > > > > All,
>> > > > > >
>> > > > > > Now that we have our code up it is important to establish a
>> process
>> > > > > around
>> > > > > > git in particular.  A general consensus in the thread appears to
>> be
>> > > > that
>> > > > > > gitflow workflow is a reasonable option.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>> > > > > >
>> > > > > > To that end I've added a develop branch off of master from which
>> > > > features
>> > > > > > can be built.  As we converge toward a release then we'll
>> > > > > address/introduce
>> > > > > > some of the other aspects of gitflow.
>> > > > > >
>> > > > > > Please discuss/comment if there are views that we should be
>> taking
>> > > > > another
>> > > > > > path.
>> > > > > >
>> > > > > > Thanks
>> > > > > > Joe
>> > > > > >
>> > > > > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
>> > > > bimargulies@gmail.com
>> > > > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
>> > > wikier@apache.org>
>> > > > > >> wrote:
>> > > > > >> > Hi Adam,
>> > > > > >> >
>> > > > > >> > one remarks about this:
>> > > > > >> >
>> > > > > >> > On 28/11/14 18:07, Adam Taft wrote:
>> > > > > >> >>
>> > > > > >> >> Knowing how we work today, if it were me, I would suggest
>> using
>> > > the
>> > > > > >> above
>> > > > > >> >> workflow combined with the "forking workflow" to guard access
>> > to
>> > > > the
>> > > > > >> >> production release (master) branches.  A very small subset of
>> > the
>> > > > > >> >> incubator's commiters should have the ability to merge the
>> > > > "develop"
>> > > > > >> >> branch
>> > > > > >> >> down to a master "release" branch.
>> > > > > >> >
>> > > > > >> >
>> > > > > >> > Suck workflow is not in place in ASF. On the one hand, the
>> > current
>> > > > git
>> > > > > >> > infrastructure does not provide such branches' management,
>> like
>> > > > > >> > bitbucket/stash do for instance. On the other hand, and more
>> > > > > important,
>> > > > > >> a
>> > > > > >> > project is not hierarchical organization, but a a meritocratic
>> > > one.
>> > > > > >> >
>> > > > > >> > I recommend you this blog post in case you want to read a bit
>> > > more:
>> > > > > >> >
>> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
>> > > > > >> >
>> > > > > >> > If someone has permissions to do (i.e., he is a committer), he
>> > can
>> > > > do
>> > > > > >> it,
>> > > > > >> > simple The tool provide you instruments to revert those
>> changes
>> > in
>> > > > > case
>> > > > > >> on
>> > > > > >> > involuntary errors.
>> > > > > >> >
>> > > > > >> >>  It would be ideal to have someone who
>> > > > > >> >> is NOT performing the majority of changes on the "develop"
>> > branch
>> > > > > take
>> > > > > >> >> this
>> > > > > >> >> role to coordinate releases, ensure minimal coding standards,
>> > run
>> > > > > >> through
>> > > > > >> >> unit and integration tests, before signing off on the release
>> > and
>> > > > > >> issuing
>> > > > > >> >> the release artifacts.
>> > > > > >>
>> > > > > >> You seem to be imagining an individual with a job which is
>> shared
>> > in
>> > > > > >> by the community. In healthy communities, a release happens when
>> > > > > >> there's a consensus to have a release. There is no person who
>> > > 'ensures
>> > > > > >> minimal coding standards', that's everyone watching commits.
>> > There's
>> > > > > >> no one 'running unit and integration tests' because (a) every
>> > > > > >> committer does this before every commit, (b) Jenkins does it,
>> (c)
>> > > the
>> > > > > >> release process does it. (d) there's no signing off on a
>> release.
>> > > The
>> > > > > >> RM puts it up for a vote, and PMC members vote.
>> > > > > >>
>> > > > > >>
>> > > > > >> >
>> > > > > >> >
>> > > > > >> > Release comes after that. The release manager is responsible
>> on
>> > > > > >> creating a
>> > > > > >> > proper release, which must include a code release and should
>> > > include
>> > > > > >> > binaries too. Each artifact release must be signed.
>> Demonstrate
>> > > your
>> > > > > >> ability
>> > > > > >> > as a project to produce releases is one of the goals of the
>> > > > > incubation.
>> > > > > >> But
>> > > > > >> > we are not yet there, step by step.
>> > > > > >> >
>> > > > > >> > Hope that helps.
>> > > > > >> >
>> > > > > >> > Cheers,
>> > > > > >> >
>> > > > > >> >
>> > > > > >> > --
>> > > > > >> > Sergio Fernández
>> > > > > >> > Partner Technology Manager
>> > > > > >> > Redlink GmbH
>> > > > > >> > m: +43 660 2747 925
>> > > > > >> > e: sergio.fernandez@redlink.co
>> > > > > >> > w: http://redlink.co
>> > > > > >>
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>



-- 
Joey Echeverria

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

NiFi grew up in a CT[R] environment where the review was very rare and so
really we ended up with CTDTFSOR - Commit then deploy then feel sense of
regret.

So the bad side: We ended up with a lot of avoidable defects where by
avoidable I mean they could have likely been detected in a decent review
effort.

The good side: We were fast.  Very fast.  New features got out quick and if
something was funky we fixed it very fast.  For the vast majority of
mistakes the problem was highly isolated (thanks to our base design
construct of FBP) and rarely caused extremely stressful days.

On balance though and given the benefits it has to community growth I
personally am very supportive of us adopting RTC immediately provided we
can sort out some key questions:

- What constitutes a valid review?
This page http://www.apache.org/foundation/glossary.html#ReviewThenCommit
suggests that a review is a consensus approval.  I am very concerned by
that definition if we're talking every commit means we need a vote.  For
the vast majority of commits this just seems to onerous and too time
consuming and frankly to me takes some of the fun out of developing.  If
for us a review is simply that a 'committer' has reviewed the code then I
am perfectly happy with this and I am thinking this is in-line with the
model Benson described for his dayjob "'make branch, submit pr, get review,
merge'"

- What is the best tooling/process around this to actually conduct/document
the review?
I think
https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
does a good job of describing the mechanics of a review/submission
process.  And I'd just assume a patch is as good as a pull request.  I
think even as a good starting point having the JIRA ticket commented on by
the reviewer would be good.

- What are some key things a reviewer should be checking for and helping to
enforce?  What are some out of bounds things?



This seems like a really important discussion and something that we should
center on sooner than later.  There are ways to nuance this such as RTC for
the core and CTR for extensions and so on but I think that just leads to
more confusion.  We should likely pick our poison. I see strong benefits in
both directions and so I can deal either way personally.  I see a couple
strong arguments here in this thread already for RTC .

Anyone willing to argue for CTR?

Thanks
Joe


On Wed, Dec 10, 2014 at 8:21 PM, Benson Margulies <bi...@gmail.com>
wrote:

> It seems to me, and this is purely opinion, that RTC has a lot to be said
> for a new project, in terms of getting more people involved, more eyeballs,
> and more of a community feeling. My dayjob workflow is 'make branch, submit
> pr, get review, merge' and that seems pretty applicable. However, I am not
> wearing any magic mentor hat-o-authority.
>
> On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org> wrote:
>
> > On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
> >
> > > Benson - thanks for the headsup on the maven plugin.  Seems like using
> > them
> > > to their fullest capability and then manually merging to master is
> > > perfectly fine to me.
> > >
> > > Billie
> > > As for CTR i don't think i have a good enough appreciation for the
> > > process/value proposition here.  Curious of other folks views.
> > >
> >
> > Both CTR and RTC have their own advantages, so either would be fine (
> > http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
> > retrospect I see my question could be viewed as leaning towards CTR, but
> it
> > was just based on an observation that people already seemed to be making
> > commits without review.
> >
> >
> > >
> > > It seems reasonable to keep the feature branch relaxed and in that
> sense
> > > what Gilman did today seems fine.  We can get bettter at those
> judgement
> > > calls and documenting the criteria as we go along.
> > >
> > > Thanks
> > > Joe
> > >
> > >
> > >
> > > On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <
> bimargulies@gmail.com
> > >
> > > wrote:
> > >
> > > > PR's are certainly convenient. There's no much difference, for a
> > > committer,
> > > > between pushing a branch to the official repo and pushing a branch to
> > > some
> > > > personal repo on github. The same integration workflow can be used
> > either
> > > > way to close out the PR upon merge.
> > > >
> > > > However, in a CTR project, it seems perhaps excessive to _require_
> > > feature
> > > > branches for small fixes as opposed to just committing them directly
> to
> > > > develop. At day job we do mostly do branch-per-jira, but some people
> > > might
> > > > find that onerous.
> > > >
> > > > Pushing to the official repo leaves more history that someone might
> > find
> > > > interesting some day. Also more clutter; some people are very
> concerned
> > > > about repacking before merging to develop.
> > > >
> > > > Another issue with gitflow is the master branch. The master branch is
> > > > supposed to get merged to for releases. The maven-release-plugin
> won't
> > do
> > > > that, and the jgitflow plugin is unsafe. So one option is to 'use
> > > gitflow'
> > > > but not bother with the master versus develop distinction, the other
> is
> > > to
> > > > do manual merges to master at release points.
> > > >
> > > >
> > > > On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com>
> wrote:
> > > >
> > > > > Hello
> > > > >
> > > > > So a question on gitflow given that commits are now underway.  When
> > > > working
> > > > > on a feature in a local repo which is a branch off the develop
> > > > branch...do
> > > > > you push the feature branch to the central repo?  This then can be
> > > merged
> > > > > by someone else as a sort of code review/pull process?
> > > > >
> > > > > Thanks
> > > > > Joe
> > > > >
> > > > > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
> > wrote:
> > > > >
> > > > > > All,
> > > > > >
> > > > > > Now that we have our code up it is important to establish a
> process
> > > > > around
> > > > > > git in particular.  A general consensus in the thread appears to
> be
> > > > that
> > > > > > gitflow workflow is a reasonable option.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> > > > > >
> > > > > > To that end I've added a develop branch off of master from which
> > > > features
> > > > > > can be built.  As we converge toward a release then we'll
> > > > > address/introduce
> > > > > > some of the other aspects of gitflow.
> > > > > >
> > > > > > Please discuss/comment if there are views that we should be
> taking
> > > > > another
> > > > > > path.
> > > > > >
> > > > > > Thanks
> > > > > > Joe
> > > > > >
> > > > > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> > > > bimargulies@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> > > wikier@apache.org>
> > > > > >> wrote:
> > > > > >> > Hi Adam,
> > > > > >> >
> > > > > >> > one remarks about this:
> > > > > >> >
> > > > > >> > On 28/11/14 18:07, Adam Taft wrote:
> > > > > >> >>
> > > > > >> >> Knowing how we work today, if it were me, I would suggest
> using
> > > the
> > > > > >> above
> > > > > >> >> workflow combined with the "forking workflow" to guard access
> > to
> > > > the
> > > > > >> >> production release (master) branches.  A very small subset of
> > the
> > > > > >> >> incubator's commiters should have the ability to merge the
> > > > "develop"
> > > > > >> >> branch
> > > > > >> >> down to a master "release" branch.
> > > > > >> >
> > > > > >> >
> > > > > >> > Suck workflow is not in place in ASF. On the one hand, the
> > current
> > > > git
> > > > > >> > infrastructure does not provide such branches' management,
> like
> > > > > >> > bitbucket/stash do for instance. On the other hand, and more
> > > > > important,
> > > > > >> a
> > > > > >> > project is not hierarchical organization, but a a meritocratic
> > > one.
> > > > > >> >
> > > > > >> > I recommend you this blog post in case you want to read a bit
> > > more:
> > > > > >> >
> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> > > > > >> >
> > > > > >> > If someone has permissions to do (i.e., he is a committer), he
> > can
> > > > do
> > > > > >> it,
> > > > > >> > simple The tool provide you instruments to revert those
> changes
> > in
> > > > > case
> > > > > >> on
> > > > > >> > involuntary errors.
> > > > > >> >
> > > > > >> >>  It would be ideal to have someone who
> > > > > >> >> is NOT performing the majority of changes on the "develop"
> > branch
> > > > > take
> > > > > >> >> this
> > > > > >> >> role to coordinate releases, ensure minimal coding standards,
> > run
> > > > > >> through
> > > > > >> >> unit and integration tests, before signing off on the release
> > and
> > > > > >> issuing
> > > > > >> >> the release artifacts.
> > > > > >>
> > > > > >> You seem to be imagining an individual with a job which is
> shared
> > in
> > > > > >> by the community. In healthy communities, a release happens when
> > > > > >> there's a consensus to have a release. There is no person who
> > > 'ensures
> > > > > >> minimal coding standards', that's everyone watching commits.
> > There's
> > > > > >> no one 'running unit and integration tests' because (a) every
> > > > > >> committer does this before every commit, (b) Jenkins does it,
> (c)
> > > the
> > > > > >> release process does it. (d) there's no signing off on a
> release.
> > > The
> > > > > >> RM puts it up for a vote, and PMC members vote.
> > > > > >>
> > > > > >>
> > > > > >> >
> > > > > >> >
> > > > > >> > Release comes after that. The release manager is responsible
> on
> > > > > >> creating a
> > > > > >> > proper release, which must include a code release and should
> > > include
> > > > > >> > binaries too. Each artifact release must be signed.
> Demonstrate
> > > your
> > > > > >> ability
> > > > > >> > as a project to produce releases is one of the goals of the
> > > > > incubation.
> > > > > >> But
> > > > > >> > we are not yet there, step by step.
> > > > > >> >
> > > > > >> > Hope that helps.
> > > > > >> >
> > > > > >> > Cheers,
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > Sergio Fernández
> > > > > >> > Partner Technology Manager
> > > > > >> > Redlink GmbH
> > > > > >> > m: +43 660 2747 925
> > > > > >> > e: sergio.fernandez@redlink.co
> > > > > >> > w: http://redlink.co
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: git workflow for nifi

Posted by Benson Margulies <bi...@gmail.com>.

It seems to me, and this is purely opinion, that RTC has a lot to be said
for a new project, in terms of getting more people involved, more eyeballs,
and more of a community feeling. My dayjob workflow is 'make branch, submit
pr, get review, merge' and that seems pretty applicable. However, I am not
wearing any magic mentor hat-o-authority.

On Wed, Dec 10, 2014 at 2:23 PM, Billie Rinaldi <bi...@apache.org> wrote:

> On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
>
> > Benson - thanks for the headsup on the maven plugin.  Seems like using
> them
> > to their fullest capability and then manually merging to master is
> > perfectly fine to me.
> >
> > Billie
> > As for CTR i don't think i have a good enough appreciation for the
> > process/value proposition here.  Curious of other folks views.
> >
>
> Both CTR and RTC have their own advantages, so either would be fine (
> http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
> retrospect I see my question could be viewed as leaning towards CTR, but it
> was just based on an observation that people already seemed to be making
> commits without review.
>
>
> >
> > It seems reasonable to keep the feature branch relaxed and in that sense
> > what Gilman did today seems fine.  We can get bettter at those judgement
> > calls and documenting the criteria as we go along.
> >
> > Thanks
> > Joe
> >
> >
> >
> > On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <bimargulies@gmail.com
> >
> > wrote:
> >
> > > PR's are certainly convenient. There's no much difference, for a
> > committer,
> > > between pushing a branch to the official repo and pushing a branch to
> > some
> > > personal repo on github. The same integration workflow can be used
> either
> > > way to close out the PR upon merge.
> > >
> > > However, in a CTR project, it seems perhaps excessive to _require_
> > feature
> > > branches for small fixes as opposed to just committing them directly to
> > > develop. At day job we do mostly do branch-per-jira, but some people
> > might
> > > find that onerous.
> > >
> > > Pushing to the official repo leaves more history that someone might
> find
> > > interesting some day. Also more clutter; some people are very concerned
> > > about repacking before merging to develop.
> > >
> > > Another issue with gitflow is the master branch. The master branch is
> > > supposed to get merged to for releases. The maven-release-plugin won't
> do
> > > that, and the jgitflow plugin is unsafe. So one option is to 'use
> > gitflow'
> > > but not bother with the master versus develop distinction, the other is
> > to
> > > do manual merges to master at release points.
> > >
> > >
> > > On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com> wrote:
> > >
> > > > Hello
> > > >
> > > > So a question on gitflow given that commits are now underway.  When
> > > working
> > > > on a feature in a local repo which is a branch off the develop
> > > branch...do
> > > > you push the feature branch to the central repo?  This then can be
> > merged
> > > > by someone else as a sort of code review/pull process?
> > > >
> > > > Thanks
> > > > Joe
> > > >
> > > > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com>
> wrote:
> > > >
> > > > > All,
> > > > >
> > > > > Now that we have our code up it is important to establish a process
> > > > around
> > > > > git in particular.  A general consensus in the thread appears to be
> > > that
> > > > > gitflow workflow is a reasonable option.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> > > > >
> > > > > To that end I've added a develop branch off of master from which
> > > features
> > > > > can be built.  As we converge toward a release then we'll
> > > > address/introduce
> > > > > some of the other aspects of gitflow.
> > > > >
> > > > > Please discuss/comment if there are views that we should be taking
> > > > another
> > > > > path.
> > > > >
> > > > > Thanks
> > > > > Joe
> > > > >
> > > > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> > > bimargulies@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> > wikier@apache.org>
> > > > >> wrote:
> > > > >> > Hi Adam,
> > > > >> >
> > > > >> > one remarks about this:
> > > > >> >
> > > > >> > On 28/11/14 18:07, Adam Taft wrote:
> > > > >> >>
> > > > >> >> Knowing how we work today, if it were me, I would suggest using
> > the
> > > > >> above
> > > > >> >> workflow combined with the "forking workflow" to guard access
> to
> > > the
> > > > >> >> production release (master) branches.  A very small subset of
> the
> > > > >> >> incubator's commiters should have the ability to merge the
> > > "develop"
> > > > >> >> branch
> > > > >> >> down to a master "release" branch.
> > > > >> >
> > > > >> >
> > > > >> > Suck workflow is not in place in ASF. On the one hand, the
> current
> > > git
> > > > >> > infrastructure does not provide such branches' management, like
> > > > >> > bitbucket/stash do for instance. On the other hand, and more
> > > > important,
> > > > >> a
> > > > >> > project is not hierarchical organization, but a a meritocratic
> > one.
> > > > >> >
> > > > >> > I recommend you this blog post in case you want to read a bit
> > more:
> > > > >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> > > > >> >
> > > > >> > If someone has permissions to do (i.e., he is a committer), he
> can
> > > do
> > > > >> it,
> > > > >> > simple The tool provide you instruments to revert those changes
> in
> > > > case
> > > > >> on
> > > > >> > involuntary errors.
> > > > >> >
> > > > >> >>  It would be ideal to have someone who
> > > > >> >> is NOT performing the majority of changes on the "develop"
> branch
> > > > take
> > > > >> >> this
> > > > >> >> role to coordinate releases, ensure minimal coding standards,
> run
> > > > >> through
> > > > >> >> unit and integration tests, before signing off on the release
> and
> > > > >> issuing
> > > > >> >> the release artifacts.
> > > > >>
> > > > >> You seem to be imagining an individual with a job which is shared
> in
> > > > >> by the community. In healthy communities, a release happens when
> > > > >> there's a consensus to have a release. There is no person who
> > 'ensures
> > > > >> minimal coding standards', that's everyone watching commits.
> There's
> > > > >> no one 'running unit and integration tests' because (a) every
> > > > >> committer does this before every commit, (b) Jenkins does it, (c)
> > the
> > > > >> release process does it. (d) there's no signing off on a release.
> > The
> > > > >> RM puts it up for a vote, and PMC members vote.
> > > > >>
> > > > >>
> > > > >> >
> > > > >> >
> > > > >> > Release comes after that. The release manager is responsible on
> > > > >> creating a
> > > > >> > proper release, which must include a code release and should
> > include
> > > > >> > binaries too. Each artifact release must be signed. Demonstrate
> > your
> > > > >> ability
> > > > >> > as a project to produce releases is one of the goals of the
> > > > incubation.
> > > > >> But
> > > > >> > we are not yet there, step by step.
> > > > >> >
> > > > >> > Hope that helps.
> > > > >> >
> > > > >> > Cheers,
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Sergio Fernández
> > > > >> > Partner Technology Manager
> > > > >> > Redlink GmbH
> > > > >> > m: +43 660 2747 925
> > > > >> > e: sergio.fernandez@redlink.co
> > > > >> > w: http://redlink.co
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: git workflow for nifi

Posted by Billie Rinaldi <bi...@apache.org>.

On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:

> Benson - thanks for the headsup on the maven plugin.  Seems like using them
> to their fullest capability and then manually merging to master is
> perfectly fine to me.
>
> Billie
> As for CTR i don't think i have a good enough appreciation for the
> process/value proposition here.  Curious of other folks views.
>

Both CTR and RTC have their own advantages, so either would be fine (
http://www.apache.org/foundation/glossary.html#CommitThenReview).  In
retrospect I see my question could be viewed as leaning towards CTR, but it
was just based on an observation that people already seemed to be making
commits without review.


>
> It seems reasonable to keep the feature branch relaxed and in that sense
> what Gilman did today seems fine.  We can get bettter at those judgement
> calls and documenting the criteria as we go along.
>
> Thanks
> Joe
>
>
>
> On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <bi...@gmail.com>
> wrote:
>
> > PR's are certainly convenient. There's no much difference, for a
> committer,
> > between pushing a branch to the official repo and pushing a branch to
> some
> > personal repo on github. The same integration workflow can be used either
> > way to close out the PR upon merge.
> >
> > However, in a CTR project, it seems perhaps excessive to _require_
> feature
> > branches for small fixes as opposed to just committing them directly to
> > develop. At day job we do mostly do branch-per-jira, but some people
> might
> > find that onerous.
> >
> > Pushing to the official repo leaves more history that someone might find
> > interesting some day. Also more clutter; some people are very concerned
> > about repacking before merging to develop.
> >
> > Another issue with gitflow is the master branch. The master branch is
> > supposed to get merged to for releases. The maven-release-plugin won't do
> > that, and the jgitflow plugin is unsafe. So one option is to 'use
> gitflow'
> > but not bother with the master versus develop distinction, the other is
> to
> > do manual merges to master at release points.
> >
> >
> > On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com> wrote:
> >
> > > Hello
> > >
> > > So a question on gitflow given that commits are now underway.  When
> > working
> > > on a feature in a local repo which is a branch off the develop
> > branch...do
> > > you push the feature branch to the central repo?  This then can be
> merged
> > > by someone else as a sort of code review/pull process?
> > >
> > > Thanks
> > > Joe
> > >
> > > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com> wrote:
> > >
> > > > All,
> > > >
> > > > Now that we have our code up it is important to establish a process
> > > around
> > > > git in particular.  A general consensus in the thread appears to be
> > that
> > > > gitflow workflow is a reasonable option.
> > > >
> > > >
> > > >
> > >
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> > > >
> > > > To that end I've added a develop branch off of master from which
> > features
> > > > can be built.  As we converge toward a release then we'll
> > > address/introduce
> > > > some of the other aspects of gitflow.
> > > >
> > > > Please discuss/comment if there are views that we should be taking
> > > another
> > > > path.
> > > >
> > > > Thanks
> > > > Joe
> > > >
> > > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> > bimargulies@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <
> wikier@apache.org>
> > > >> wrote:
> > > >> > Hi Adam,
> > > >> >
> > > >> > one remarks about this:
> > > >> >
> > > >> > On 28/11/14 18:07, Adam Taft wrote:
> > > >> >>
> > > >> >> Knowing how we work today, if it were me, I would suggest using
> the
> > > >> above
> > > >> >> workflow combined with the "forking workflow" to guard access to
> > the
> > > >> >> production release (master) branches.  A very small subset of the
> > > >> >> incubator's commiters should have the ability to merge the
> > "develop"
> > > >> >> branch
> > > >> >> down to a master "release" branch.
> > > >> >
> > > >> >
> > > >> > Suck workflow is not in place in ASF. On the one hand, the current
> > git
> > > >> > infrastructure does not provide such branches' management, like
> > > >> > bitbucket/stash do for instance. On the other hand, and more
> > > important,
> > > >> a
> > > >> > project is not hierarchical organization, but a a meritocratic
> one.
> > > >> >
> > > >> > I recommend you this blog post in case you want to read a bit
> more:
> > > >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> > > >> >
> > > >> > If someone has permissions to do (i.e., he is a committer), he can
> > do
> > > >> it,
> > > >> > simple The tool provide you instruments to revert those changes in
> > > case
> > > >> on
> > > >> > involuntary errors.
> > > >> >
> > > >> >>  It would be ideal to have someone who
> > > >> >> is NOT performing the majority of changes on the "develop" branch
> > > take
> > > >> >> this
> > > >> >> role to coordinate releases, ensure minimal coding standards, run
> > > >> through
> > > >> >> unit and integration tests, before signing off on the release and
> > > >> issuing
> > > >> >> the release artifacts.
> > > >>
> > > >> You seem to be imagining an individual with a job which is shared in
> > > >> by the community. In healthy communities, a release happens when
> > > >> there's a consensus to have a release. There is no person who
> 'ensures
> > > >> minimal coding standards', that's everyone watching commits. There's
> > > >> no one 'running unit and integration tests' because (a) every
> > > >> committer does this before every commit, (b) Jenkins does it, (c)
> the
> > > >> release process does it. (d) there's no signing off on a release.
> The
> > > >> RM puts it up for a vote, and PMC members vote.
> > > >>
> > > >>
> > > >> >
> > > >> >
> > > >> > Release comes after that. The release manager is responsible on
> > > >> creating a
> > > >> > proper release, which must include a code release and should
> include
> > > >> > binaries too. Each artifact release must be signed. Demonstrate
> your
> > > >> ability
> > > >> > as a project to produce releases is one of the goals of the
> > > incubation.
> > > >> But
> > > >> > we are not yet there, step by step.
> > > >> >
> > > >> > Hope that helps.
> > > >> >
> > > >> > Cheers,
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Sergio Fernández
> > > >> > Partner Technology Manager
> > > >> > Redlink GmbH
> > > >> > m: +43 660 2747 925
> > > >> > e: sergio.fernandez@redlink.co
> > > >> > w: http://redlink.co
> > > >>
> > > >
> > > >
> > >
> >
>

Re: git workflow for nifi

Posted by Joey Echeverria <jo...@cloudera.com>.

I'm a big believer in RTC. IMO, it's much easier to review changes
before they're committed to the project. It also makes the status of
contributors and committers equal when performing the same task. If
I'm writing a patch, it should be reviewed by one or more committers
before it's committed regardless of my status in the project. I find
it much harder to track what's going on with CTR projects because it's
easier for me to miss a commit unless I'm subscribed to a commit
e-mail list and have time to watch all the commits as they go in.
That's much harder if working on the project isn't my full time job.

I don't know enough about gitflow to comment fully on that, but I can
provide a little bit of color based on my experience with other
projects. I'd say most patches don't really need the overhead of a
feature branch in the project's central repository. The majority of
patches will end up being relatively small fixes. The way that we
handle this with Kite is with PRs, which I think is described as part
of the "Forking workflow"[1]. Generally, small changes coming in
either as a PR or a PATCH attached to a JIRA should be eligible to get
committed after a review directly into the main-line development
branch; master or develop if you want to use gitflow. Feature branches
should be created for large features  which I'd describe as anything
that requires more than one JIRA/commit.

That brings up another point, which is how the community wants to map
commits to JIRAs. In my experience, it's best if you can make commits
to JIRAs 1:1. This makes it much easier for any downstream maintainers
to backport specific fixes and it's way easier to answer the question
of at which point is a fix in the codebase. If the community wants to
maintain different version branches, then I generally prefer a new
JIRA be opened for backports of a fixes to an older version. Although
I can see the benefits of just doing the backport as a cherrypick,
with a possible conflict resolution, but still committing it with the
same JIRA number.

>From what I can tell of gitflow, there aren't long running version
branches so that may be a mute point.

-Joey

[1] https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow

On Tue, Dec 9, 2014 at 8:07 AM, Joe Witt <jo...@gmail.com> wrote:
> Benson - thanks for the headsup on the maven plugin.  Seems like using them
> to their fullest capability and then manually merging to master is
> perfectly fine to me.
>
> Billie
> As for CTR i don't think i have a good enough appreciation for the
> process/value proposition here.  Curious of other folks views.
>
> It seems reasonable to keep the feature branch relaxed and in that sense
> what Gilman did today seems fine.  We can get bettter at those judgement
> calls and documenting the criteria as we go along.
>
> Thanks
> Joe
>
>
>
> On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <bi...@gmail.com>
> wrote:
>
>> PR's are certainly convenient. There's no much difference, for a committer,
>> between pushing a branch to the official repo and pushing a branch to some
>> personal repo on github. The same integration workflow can be used either
>> way to close out the PR upon merge.
>>
>> However, in a CTR project, it seems perhaps excessive to _require_ feature
>> branches for small fixes as opposed to just committing them directly to
>> develop. At day job we do mostly do branch-per-jira, but some people might
>> find that onerous.
>>
>> Pushing to the official repo leaves more history that someone might find
>> interesting some day. Also more clutter; some people are very concerned
>> about repacking before merging to develop.
>>
>> Another issue with gitflow is the master branch. The master branch is
>> supposed to get merged to for releases. The maven-release-plugin won't do
>> that, and the jgitflow plugin is unsafe. So one option is to 'use gitflow'
>> but not bother with the master versus develop distinction, the other is to
>> do manual merges to master at release points.
>>
>>
>> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com> wrote:
>>
>> > Hello
>> >
>> > So a question on gitflow given that commits are now underway.  When
>> working
>> > on a feature in a local repo which is a branch off the develop
>> branch...do
>> > you push the feature branch to the central repo?  This then can be merged
>> > by someone else as a sort of code review/pull process?
>> >
>> > Thanks
>> > Joe
>> >
>> > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com> wrote:
>> >
>> > > All,
>> > >
>> > > Now that we have our code up it is important to establish a process
>> > around
>> > > git in particular.  A general consensus in the thread appears to be
>> that
>> > > gitflow workflow is a reasonable option.
>> > >
>> > >
>> > >
>> >
>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>> > >
>> > > To that end I've added a develop branch off of master from which
>> features
>> > > can be built.  As we converge toward a release then we'll
>> > address/introduce
>> > > some of the other aspects of gitflow.
>> > >
>> > > Please discuss/comment if there are views that we should be taking
>> > another
>> > > path.
>> > >
>> > > Thanks
>> > > Joe
>> > >
>> > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
>> bimargulies@gmail.com
>> > >
>> > > wrote:
>> > >
>> > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <wi...@apache.org>
>> > >> wrote:
>> > >> > Hi Adam,
>> > >> >
>> > >> > one remarks about this:
>> > >> >
>> > >> > On 28/11/14 18:07, Adam Taft wrote:
>> > >> >>
>> > >> >> Knowing how we work today, if it were me, I would suggest using the
>> > >> above
>> > >> >> workflow combined with the "forking workflow" to guard access to
>> the
>> > >> >> production release (master) branches.  A very small subset of the
>> > >> >> incubator's commiters should have the ability to merge the
>> "develop"
>> > >> >> branch
>> > >> >> down to a master "release" branch.
>> > >> >
>> > >> >
>> > >> > Suck workflow is not in place in ASF. On the one hand, the current
>> git
>> > >> > infrastructure does not provide such branches' management, like
>> > >> > bitbucket/stash do for instance. On the other hand, and more
>> > important,
>> > >> a
>> > >> > project is not hierarchical organization, but a a meritocratic one.
>> > >> >
>> > >> > I recommend you this blog post in case you want to read a bit more:
>> > >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
>> > >> >
>> > >> > If someone has permissions to do (i.e., he is a committer), he can
>> do
>> > >> it,
>> > >> > simple The tool provide you instruments to revert those changes in
>> > case
>> > >> on
>> > >> > involuntary errors.
>> > >> >
>> > >> >>  It would be ideal to have someone who
>> > >> >> is NOT performing the majority of changes on the "develop" branch
>> > take
>> > >> >> this
>> > >> >> role to coordinate releases, ensure minimal coding standards, run
>> > >> through
>> > >> >> unit and integration tests, before signing off on the release and
>> > >> issuing
>> > >> >> the release artifacts.
>> > >>
>> > >> You seem to be imagining an individual with a job which is shared in
>> > >> by the community. In healthy communities, a release happens when
>> > >> there's a consensus to have a release. There is no person who 'ensures
>> > >> minimal coding standards', that's everyone watching commits. There's
>> > >> no one 'running unit and integration tests' because (a) every
>> > >> committer does this before every commit, (b) Jenkins does it, (c) the
>> > >> release process does it. (d) there's no signing off on a release. The
>> > >> RM puts it up for a vote, and PMC members vote.
>> > >>
>> > >>
>> > >> >
>> > >> >
>> > >> > Release comes after that. The release manager is responsible on
>> > >> creating a
>> > >> > proper release, which must include a code release and should include
>> > >> > binaries too. Each artifact release must be signed. Demonstrate your
>> > >> ability
>> > >> > as a project to produce releases is one of the goals of the
>> > incubation.
>> > >> But
>> > >> > we are not yet there, step by step.
>> > >> >
>> > >> > Hope that helps.
>> > >> >
>> > >> > Cheers,
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Sergio Fernández
>> > >> > Partner Technology Manager
>> > >> > Redlink GmbH
>> > >> > m: +43 660 2747 925
>> > >> > e: sergio.fernandez@redlink.co
>> > >> > w: http://redlink.co
>> > >>
>> > >
>> > >
>> >
>>



-- 
Joey Echeverria

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

Benson - thanks for the headsup on the maven plugin.  Seems like using them
to their fullest capability and then manually merging to master is
perfectly fine to me.

Billie
As for CTR i don't think i have a good enough appreciation for the
process/value proposition here.  Curious of other folks views.

It seems reasonable to keep the feature branch relaxed and in that sense
what Gilman did today seems fine.  We can get bettter at those judgement
calls and documenting the criteria as we go along.

Thanks
Joe



On Tue, Dec 9, 2014 at 11:00 AM, Benson Margulies <bi...@gmail.com>
wrote:

> PR's are certainly convenient. There's no much difference, for a committer,
> between pushing a branch to the official repo and pushing a branch to some
> personal repo on github. The same integration workflow can be used either
> way to close out the PR upon merge.
>
> However, in a CTR project, it seems perhaps excessive to _require_ feature
> branches for small fixes as opposed to just committing them directly to
> develop. At day job we do mostly do branch-per-jira, but some people might
> find that onerous.
>
> Pushing to the official repo leaves more history that someone might find
> interesting some day. Also more clutter; some people are very concerned
> about repacking before merging to develop.
>
> Another issue with gitflow is the master branch. The master branch is
> supposed to get merged to for releases. The maven-release-plugin won't do
> that, and the jgitflow plugin is unsafe. So one option is to 'use gitflow'
> but not bother with the master versus develop distinction, the other is to
> do manual merges to master at release points.
>
>
> On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com> wrote:
>
> > Hello
> >
> > So a question on gitflow given that commits are now underway.  When
> working
> > on a feature in a local repo which is a branch off the develop
> branch...do
> > you push the feature branch to the central repo?  This then can be merged
> > by someone else as a sort of code review/pull process?
> >
> > Thanks
> > Joe
> >
> > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com> wrote:
> >
> > > All,
> > >
> > > Now that we have our code up it is important to establish a process
> > around
> > > git in particular.  A general consensus in the thread appears to be
> that
> > > gitflow workflow is a reasonable option.
> > >
> > >
> > >
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> > >
> > > To that end I've added a develop branch off of master from which
> features
> > > can be built.  As we converge toward a release then we'll
> > address/introduce
> > > some of the other aspects of gitflow.
> > >
> > > Please discuss/comment if there are views that we should be taking
> > another
> > > path.
> > >
> > > Thanks
> > > Joe
> > >
> > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <
> bimargulies@gmail.com
> > >
> > > wrote:
> > >
> > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <wi...@apache.org>
> > >> wrote:
> > >> > Hi Adam,
> > >> >
> > >> > one remarks about this:
> > >> >
> > >> > On 28/11/14 18:07, Adam Taft wrote:
> > >> >>
> > >> >> Knowing how we work today, if it were me, I would suggest using the
> > >> above
> > >> >> workflow combined with the "forking workflow" to guard access to
> the
> > >> >> production release (master) branches.  A very small subset of the
> > >> >> incubator's commiters should have the ability to merge the
> "develop"
> > >> >> branch
> > >> >> down to a master "release" branch.
> > >> >
> > >> >
> > >> > Suck workflow is not in place in ASF. On the one hand, the current
> git
> > >> > infrastructure does not provide such branches' management, like
> > >> > bitbucket/stash do for instance. On the other hand, and more
> > important,
> > >> a
> > >> > project is not hierarchical organization, but a a meritocratic one.
> > >> >
> > >> > I recommend you this blog post in case you want to read a bit more:
> > >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> > >> >
> > >> > If someone has permissions to do (i.e., he is a committer), he can
> do
> > >> it,
> > >> > simple The tool provide you instruments to revert those changes in
> > case
> > >> on
> > >> > involuntary errors.
> > >> >
> > >> >>  It would be ideal to have someone who
> > >> >> is NOT performing the majority of changes on the "develop" branch
> > take
> > >> >> this
> > >> >> role to coordinate releases, ensure minimal coding standards, run
> > >> through
> > >> >> unit and integration tests, before signing off on the release and
> > >> issuing
> > >> >> the release artifacts.
> > >>
> > >> You seem to be imagining an individual with a job which is shared in
> > >> by the community. In healthy communities, a release happens when
> > >> there's a consensus to have a release. There is no person who 'ensures
> > >> minimal coding standards', that's everyone watching commits. There's
> > >> no one 'running unit and integration tests' because (a) every
> > >> committer does this before every commit, (b) Jenkins does it, (c) the
> > >> release process does it. (d) there's no signing off on a release. The
> > >> RM puts it up for a vote, and PMC members vote.
> > >>
> > >>
> > >> >
> > >> >
> > >> > Release comes after that. The release manager is responsible on
> > >> creating a
> > >> > proper release, which must include a code release and should include
> > >> > binaries too. Each artifact release must be signed. Demonstrate your
> > >> ability
> > >> > as a project to produce releases is one of the goals of the
> > incubation.
> > >> But
> > >> > we are not yet there, step by step.
> > >> >
> > >> > Hope that helps.
> > >> >
> > >> > Cheers,
> > >> >
> > >> >
> > >> > --
> > >> > Sergio Fernández
> > >> > Partner Technology Manager
> > >> > Redlink GmbH
> > >> > m: +43 660 2747 925
> > >> > e: sergio.fernandez@redlink.co
> > >> > w: http://redlink.co
> > >>
> > >
> > >
> >
>

Re: git workflow for nifi

Posted by Benson Margulies <bi...@gmail.com>.

PR's are certainly convenient. There's no much difference, for a committer,
between pushing a branch to the official repo and pushing a branch to some
personal repo on github. The same integration workflow can be used either
way to close out the PR upon merge.

However, in a CTR project, it seems perhaps excessive to _require_ feature
branches for small fixes as opposed to just committing them directly to
develop. At day job we do mostly do branch-per-jira, but some people might
find that onerous.

Pushing to the official repo leaves more history that someone might find
interesting some day. Also more clutter; some people are very concerned
about repacking before merging to develop.

Another issue with gitflow is the master branch. The master branch is
supposed to get merged to for releases. The maven-release-plugin won't do
that, and the jgitflow plugin is unsafe. So one option is to 'use gitflow'
but not bother with the master versus develop distinction, the other is to
do manual merges to master at release points.


On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <jo...@gmail.com> wrote:

> Hello
>
> So a question on gitflow given that commits are now underway.  When working
> on a feature in a local repo which is a branch off the develop branch...do
> you push the feature branch to the central repo?  This then can be merged
> by someone else as a sort of code review/pull process?
>
> Thanks
> Joe
>
> On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com> wrote:
>
> > All,
> >
> > Now that we have our code up it is important to establish a process
> around
> > git in particular.  A general consensus in the thread appears to be that
> > gitflow workflow is a reasonable option.
> >
> >
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> >
> > To that end I've added a develop branch off of master from which features
> > can be built.  As we converge toward a release then we'll
> address/introduce
> > some of the other aspects of gitflow.
> >
> > Please discuss/comment if there are views that we should be taking
> another
> > path.
> >
> > Thanks
> > Joe
> >
> > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <bimargulies@gmail.com
> >
> > wrote:
> >
> >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <wi...@apache.org>
> >> wrote:
> >> > Hi Adam,
> >> >
> >> > one remarks about this:
> >> >
> >> > On 28/11/14 18:07, Adam Taft wrote:
> >> >>
> >> >> Knowing how we work today, if it were me, I would suggest using the
> >> above
> >> >> workflow combined with the "forking workflow" to guard access to the
> >> >> production release (master) branches.  A very small subset of the
> >> >> incubator's commiters should have the ability to merge the "develop"
> >> >> branch
> >> >> down to a master "release" branch.
> >> >
> >> >
> >> > Suck workflow is not in place in ASF. On the one hand, the current git
> >> > infrastructure does not provide such branches' management, like
> >> > bitbucket/stash do for instance. On the other hand, and more
> important,
> >> a
> >> > project is not hierarchical organization, but a a meritocratic one.
> >> >
> >> > I recommend you this blog post in case you want to read a bit more:
> >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> >> >
> >> > If someone has permissions to do (i.e., he is a committer), he can do
> >> it,
> >> > simple The tool provide you instruments to revert those changes in
> case
> >> on
> >> > involuntary errors.
> >> >
> >> >>  It would be ideal to have someone who
> >> >> is NOT performing the majority of changes on the "develop" branch
> take
> >> >> this
> >> >> role to coordinate releases, ensure minimal coding standards, run
> >> through
> >> >> unit and integration tests, before signing off on the release and
> >> issuing
> >> >> the release artifacts.
> >>
> >> You seem to be imagining an individual with a job which is shared in
> >> by the community. In healthy communities, a release happens when
> >> there's a consensus to have a release. There is no person who 'ensures
> >> minimal coding standards', that's everyone watching commits. There's
> >> no one 'running unit and integration tests' because (a) every
> >> committer does this before every commit, (b) Jenkins does it, (c) the
> >> release process does it. (d) there's no signing off on a release. The
> >> RM puts it up for a vote, and PMC members vote.
> >>
> >>
> >> >
> >> >
> >> > Release comes after that. The release manager is responsible on
> >> creating a
> >> > proper release, which must include a code release and should include
> >> > binaries too. Each artifact release must be signed. Demonstrate your
> >> ability
> >> > as a project to produce releases is one of the goals of the
> incubation.
> >> But
> >> > we are not yet there, step by step.
> >> >
> >> > Hope that helps.
> >> >
> >> > Cheers,
> >> >
> >> >
> >> > --
> >> > Sergio Fernández
> >> > Partner Technology Manager
> >> > Redlink GmbH
> >> > m: +43 660 2747 925
> >> > e: sergio.fernandez@redlink.co
> >> > w: http://redlink.co
> >>
> >
> >
>

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

Hello

So a question on gitflow given that commits are now underway.  When working
on a feature in a local repo which is a branch off the develop branch...do
you push the feature branch to the central repo?  This then can be merged
by someone else as a sort of code review/pull process?

Thanks
Joe

On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <jo...@gmail.com> wrote:

> All,
>
> Now that we have our code up it is important to establish a process around
> git in particular.  A general consensus in the thread appears to be that
> gitflow workflow is a reasonable option.
>
>
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>
> To that end I've added a develop branch off of master from which features
> can be built.  As we converge toward a release then we'll address/introduce
> some of the other aspects of gitflow.
>
> Please discuss/comment if there are views that we should be taking another
> path.
>
> Thanks
> Joe
>
> On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <bi...@gmail.com>
> wrote:
>
>> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <wi...@apache.org>
>> wrote:
>> > Hi Adam,
>> >
>> > one remarks about this:
>> >
>> > On 28/11/14 18:07, Adam Taft wrote:
>> >>
>> >> Knowing how we work today, if it were me, I would suggest using the
>> above
>> >> workflow combined with the "forking workflow" to guard access to the
>> >> production release (master) branches.  A very small subset of the
>> >> incubator's commiters should have the ability to merge the "develop"
>> >> branch
>> >> down to a master "release" branch.
>> >
>> >
>> > Suck workflow is not in place in ASF. On the one hand, the current git
>> > infrastructure does not provide such branches' management, like
>> > bitbucket/stash do for instance. On the other hand, and more important,
>> a
>> > project is not hierarchical organization, but a a meritocratic one.
>> >
>> > I recommend you this blog post in case you want to read a bit more:
>> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
>> >
>> > If someone has permissions to do (i.e., he is a committer), he can do
>> it,
>> > simple The tool provide you instruments to revert those changes in case
>> on
>> > involuntary errors.
>> >
>> >>  It would be ideal to have someone who
>> >> is NOT performing the majority of changes on the "develop" branch take
>> >> this
>> >> role to coordinate releases, ensure minimal coding standards, run
>> through
>> >> unit and integration tests, before signing off on the release and
>> issuing
>> >> the release artifacts.
>>
>> You seem to be imagining an individual with a job which is shared in
>> by the community. In healthy communities, a release happens when
>> there's a consensus to have a release. There is no person who 'ensures
>> minimal coding standards', that's everyone watching commits. There's
>> no one 'running unit and integration tests' because (a) every
>> committer does this before every commit, (b) Jenkins does it, (c) the
>> release process does it. (d) there's no signing off on a release. The
>> RM puts it up for a vote, and PMC members vote.
>>
>>
>> >
>> >
>> > Release comes after that. The release manager is responsible on
>> creating a
>> > proper release, which must include a code release and should include
>> > binaries too. Each artifact release must be signed. Demonstrate your
>> ability
>> > as a project to produce releases is one of the goals of the incubation.
>> But
>> > we are not yet there, step by step.
>> >
>> > Hope that helps.
>> >
>> > Cheers,
>> >
>> >
>> > --
>> > Sergio Fernández
>> > Partner Technology Manager
>> > Redlink GmbH
>> > m: +43 660 2747 925
>> > e: sergio.fernandez@redlink.co
>> > w: http://redlink.co
>>
>
>

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

All,

Now that we have our code up it is important to establish a process around
git in particular.  A general consensus in the thread appears to be that
gitflow workflow is a reasonable option.

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

To that end I've added a develop branch off of master from which features
can be built.  As we converge toward a release then we'll address/introduce
some of the other aspects of gitflow.

Please discuss/comment if there are views that we should be taking another
path.

Thanks
Joe

On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <bi...@gmail.com>
wrote:

> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <wi...@apache.org>
> wrote:
> > Hi Adam,
> >
> > one remarks about this:
> >
> > On 28/11/14 18:07, Adam Taft wrote:
> >>
> >> Knowing how we work today, if it were me, I would suggest using the
> above
> >> workflow combined with the "forking workflow" to guard access to the
> >> production release (master) branches.  A very small subset of the
> >> incubator's commiters should have the ability to merge the "develop"
> >> branch
> >> down to a master "release" branch.
> >
> >
> > Suck workflow is not in place in ASF. On the one hand, the current git
> > infrastructure does not provide such branches' management, like
> > bitbucket/stash do for instance. On the other hand, and more important, a
> > project is not hierarchical organization, but a a meritocratic one.
> >
> > I recommend you this blog post in case you want to read a bit more:
> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
> >
> > If someone has permissions to do (i.e., he is a committer), he can do it,
> > simple The tool provide you instruments to revert those changes in case
> on
> > involuntary errors.
> >
> >>  It would be ideal to have someone who
> >> is NOT performing the majority of changes on the "develop" branch take
> >> this
> >> role to coordinate releases, ensure minimal coding standards, run
> through
> >> unit and integration tests, before signing off on the release and
> issuing
> >> the release artifacts.
>
> You seem to be imagining an individual with a job which is shared in
> by the community. In healthy communities, a release happens when
> there's a consensus to have a release. There is no person who 'ensures
> minimal coding standards', that's everyone watching commits. There's
> no one 'running unit and integration tests' because (a) every
> committer does this before every commit, (b) Jenkins does it, (c) the
> release process does it. (d) there's no signing off on a release. The
> RM puts it up for a vote, and PMC members vote.
>
>
> >
> >
> > Release comes after that. The release manager is responsible on creating
> a
> > proper release, which must include a code release and should include
> > binaries too. Each artifact release must be signed. Demonstrate your
> ability
> > as a project to produce releases is one of the goals of the incubation.
> But
> > we are not yet there, step by step.
> >
> > Hope that helps.
> >
> > Cheers,
> >
> >
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: sergio.fernandez@redlink.co
> > w: http://redlink.co
>

Re: git workflow for nifi

Posted by Benson Margulies <bi...@gmail.com>.

On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <wi...@apache.org> wrote:
> Hi Adam,
>
> one remarks about this:
>
> On 28/11/14 18:07, Adam Taft wrote:
>>
>> Knowing how we work today, if it were me, I would suggest using the above
>> workflow combined with the "forking workflow" to guard access to the
>> production release (master) branches.  A very small subset of the
>> incubator's commiters should have the ability to merge the "develop"
>> branch
>> down to a master "release" branch.
>
>
> Suck workflow is not in place in ASF. On the one hand, the current git
> infrastructure does not provide such branches' management, like
> bitbucket/stash do for instance. On the other hand, and more important, a
> project is not hierarchical organization, but a a meritocratic one.
>
> I recommend you this blog post in case you want to read a bit more:
> http://communityovercode.com/2012/05/meritocracy-and-hierarchy/
>
> If someone has permissions to do (i.e., he is a committer), he can do it,
> simple The tool provide you instruments to revert those changes in case on
> involuntary errors.
>
>>  It would be ideal to have someone who
>> is NOT performing the majority of changes on the "develop" branch take
>> this
>> role to coordinate releases, ensure minimal coding standards, run through
>> unit and integration tests, before signing off on the release and issuing
>> the release artifacts.

You seem to be imagining an individual with a job which is shared in
by the community. In healthy communities, a release happens when
there's a consensus to have a release. There is no person who 'ensures
minimal coding standards', that's everyone watching commits. There's
no one 'running unit and integration tests' because (a) every
committer does this before every commit, (b) Jenkins does it, (c) the
release process does it. (d) there's no signing off on a release. The
RM puts it up for a vote, and PMC members vote.


>
>
> Release comes after that. The release manager is responsible on creating a
> proper release, which must include a code release and should include
> binaries too. Each artifact release must be signed. Demonstrate your ability
> as a project to produce releases is one of the goals of the incubation. But
> we are not yet there, step by step.
>
> Hope that helps.
>
> Cheers,
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co

Re: git workflow for nifi

Posted by Sergio Fernández <wi...@apache.org>.

Hi Adam,

one remarks about this:

On 28/11/14 18:07, Adam Taft wrote:
> Knowing how we work today, if it were me, I would suggest using the above
> workflow combined with the "forking workflow" to guard access to the
> production release (master) branches.  A very small subset of the
> incubator's commiters should have the ability to merge the "develop" branch
> down to a master "release" branch.

Suck workflow is not in place in ASF. On the one hand, the current git 
infrastructure does not provide such branches' management, like 
bitbucket/stash do for instance. On the other hand, and more important, 
a project is not hierarchical organization, but a a meritocratic one.

I recommend you this blog post in case you want to read a bit more:
http://communityovercode.com/2012/05/meritocracy-and-hierarchy/

If someone has permissions to do (i.e., he is a committer), he can do 
it, simple The tool provide you instruments to revert those changes in 
case on involuntary errors.

>  It would be ideal to have someone who
> is NOT performing the majority of changes on the "develop" branch take this
> role to coordinate releases, ensure minimal coding standards, run through
> unit and integration tests, before signing off on the release and issuing
> the release artifacts.

Release comes after that. The release manager is responsible on creating 
a proper release, which must include a code release and should include 
binaries too. Each artifact release must be signed. Demonstrate your 
ability as a project to produce releases is one of the goals of the 
incubation. But we are not yet there, step by step.

Hope that helps.

Cheers,

-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co

Re: git workflow for nifi

Posted by Tony Kurc <tr...@gmail.com>.

I wouldn't go so far as to say "problematic". However, I sure don't like
the maven plugins. I have had more success implementing the steps manually.
I'd be the first to admit this may be personal preference. I haven't used
the git-flow subcommands.

On Fri, Nov 28, 2014 at 9:43 PM, Joe Witt <jo...@gmail.com> wrote:

> Sergio - thanks for the refs.  Very helpful.
>
> Adam
>
> From a pure developer perspective I think what you're saying there sounds
> ideal.  Again as with versioning it comes down to discipline.  Being
> disciplined of course is aided by convenience.  I am curious of the
> mechanics of doing what you propose.  Tony had made a comment about the
> tooling around a Gitflow construct perhaps being problematic.  This is
> something where I think we'll need one or two folks to set the tone for the
> rest of us to follow.
>
> Thanks
> Joe
>
> On Fri, Nov 28, 2014 at 12:07 PM, Adam Taft <ad...@adamtaft.com> wrote:
>
> > +1 to the "git workflow".  Quoting Atlassian:
> >
> > "Maintenance or “hotfix” branches are used to quickly patch production
> > releases. This is the only branch that should fork directly off of
> master.
> > As soon as the fix is complete, it should be merged into both master and
> > develop (or the current release branch), and master should be tagged with
> > an updated version number."
> >
> > We should reflect on what the NiFi pre-OSS development model looks like
> and
> > how it could be improved from a prescribed workflow like the "git
> > workflow.".  The concept that hotfixes should be applied directly to a
> > release (and merged with the develop branch) is something we have done
> > poorly to date.  We have tended to flush all changes (whether new
> > experimental features or hot fixes) down onto the same release, which has
> > caused stability problems too many times to count.
> >
> > Knowing how we work today, if it were me, I would suggest using the above
> > workflow combined with the "forking workflow" to guard access to the
> > production release (master) branches.  A very small subset of the
> > incubator's commiters should have the ability to merge the "develop"
> branch
> > down to a master "release" branch.  It would be ideal to have someone who
> > is NOT performing the majority of changes on the "develop" branch take
> this
> > role to coordinate releases, ensure minimal coding standards, run through
> > unit and integration tests, before signing off on the release and issuing
> > the release artifacts.
> >
> > Adam
> >
> >
> >
> > On Fri, Nov 28, 2014 at 4:11 AM, Sergio Fernández <wi...@apache.org>
> > wrote:
> >
> > > Just in case it help, in Marmotta we follow Giflow with very good
> > results:
> > >
> > > http://marmotta.apache.org/development#Source_code
> > >
> > > Further reading:
> > >
> > > http://nvie.com/posts/a-successful-git-branching-model/
> > > http://www.atlassian.com/git/workflows#!workflow-gitflow
> > >
> > > Hope that helps.
> > >
> > > On 26/11/14 17:35, Tony Kurc wrote:
> > >
> > >> I wanted to kick off a discussion about workflow in git. There are a
> lot
> > >> of
> > >> techniques in git for working effectively as a team, managing several
> > >> product versions at once, and for branching and merging code back in.
> It
> > >> looks like several other apache projects have guides for their team
> > >> conventions, such as Deltaspike [1] and Accumulo [2], I think it would
> > be
> > >> prudent to work on some conventions for NiFi. I've used several
> styles,
> > >> one
> > >> of which works well for other projects I've worked on is called
> gitflow
> > >> [3]. I like the concepts of gitflow, but I really don't like depending
> > on
> > >> maven plugins to execute the conventions. I'd be in favor of something
> > >> like
> > >> gitflow, not sure if others had opinions.
> > >>
> > >> Tony
> > >>
> > >> [1]https://deltaspike.apache.org/suggested-git-workflows.html
> > >> [2] https://accumulo.apache.org/git.html
> > >> [3]
> > >> https://www.atlassian.com/git/tutorials/comparing-workflows/
> > >> gitflow-workflow/
> > >>
> > >>
> > > --
> > > Sergio Fernández
> > > Partner Technology Manager
> > > Redlink GmbH
> > > m: +43 660 2747 925
> > > e: sergio.fernandez@redlink.co
> > > w: http://redlink.co
> > >
> >
>

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

Sergio - thanks for the refs.  Very helpful.

Adam

>From a pure developer perspective I think what you're saying there sounds
ideal.  Again as with versioning it comes down to discipline.  Being
disciplined of course is aided by convenience.  I am curious of the
mechanics of doing what you propose.  Tony had made a comment about the
tooling around a Gitflow construct perhaps being problematic.  This is
something where I think we'll need one or two folks to set the tone for the
rest of us to follow.

Thanks
Joe

On Fri, Nov 28, 2014 at 12:07 PM, Adam Taft <ad...@adamtaft.com> wrote:

> +1 to the "git workflow".  Quoting Atlassian:
>
> "Maintenance or “hotfix” branches are used to quickly patch production
> releases. This is the only branch that should fork directly off of master.
> As soon as the fix is complete, it should be merged into both master and
> develop (or the current release branch), and master should be tagged with
> an updated version number."
>
> We should reflect on what the NiFi pre-OSS development model looks like and
> how it could be improved from a prescribed workflow like the "git
> workflow.".  The concept that hotfixes should be applied directly to a
> release (and merged with the develop branch) is something we have done
> poorly to date.  We have tended to flush all changes (whether new
> experimental features or hot fixes) down onto the same release, which has
> caused stability problems too many times to count.
>
> Knowing how we work today, if it were me, I would suggest using the above
> workflow combined with the "forking workflow" to guard access to the
> production release (master) branches.  A very small subset of the
> incubator's commiters should have the ability to merge the "develop" branch
> down to a master "release" branch.  It would be ideal to have someone who
> is NOT performing the majority of changes on the "develop" branch take this
> role to coordinate releases, ensure minimal coding standards, run through
> unit and integration tests, before signing off on the release and issuing
> the release artifacts.
>
> Adam
>
>
>
> On Fri, Nov 28, 2014 at 4:11 AM, Sergio Fernández <wi...@apache.org>
> wrote:
>
> > Just in case it help, in Marmotta we follow Giflow with very good
> results:
> >
> > http://marmotta.apache.org/development#Source_code
> >
> > Further reading:
> >
> > http://nvie.com/posts/a-successful-git-branching-model/
> > http://www.atlassian.com/git/workflows#!workflow-gitflow
> >
> > Hope that helps.
> >
> > On 26/11/14 17:35, Tony Kurc wrote:
> >
> >> I wanted to kick off a discussion about workflow in git. There are a lot
> >> of
> >> techniques in git for working effectively as a team, managing several
> >> product versions at once, and for branching and merging code back in. It
> >> looks like several other apache projects have guides for their team
> >> conventions, such as Deltaspike [1] and Accumulo [2], I think it would
> be
> >> prudent to work on some conventions for NiFi. I've used several styles,
> >> one
> >> of which works well for other projects I've worked on is called gitflow
> >> [3]. I like the concepts of gitflow, but I really don't like depending
> on
> >> maven plugins to execute the conventions. I'd be in favor of something
> >> like
> >> gitflow, not sure if others had opinions.
> >>
> >> Tony
> >>
> >> [1]https://deltaspike.apache.org/suggested-git-workflows.html
> >> [2] https://accumulo.apache.org/git.html
> >> [3]
> >> https://www.atlassian.com/git/tutorials/comparing-workflows/
> >> gitflow-workflow/
> >>
> >>
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: sergio.fernandez@redlink.co
> > w: http://redlink.co
> >
>

Re: git workflow for nifi

Posted by Adam Taft <ad...@adamtaft.com>.

+1 to the "git workflow".  Quoting Atlassian:

"Maintenance or “hotfix” branches are used to quickly patch production
releases. This is the only branch that should fork directly off of master.
As soon as the fix is complete, it should be merged into both master and
develop (or the current release branch), and master should be tagged with
an updated version number."

We should reflect on what the NiFi pre-OSS development model looks like and
how it could be improved from a prescribed workflow like the "git
workflow.".  The concept that hotfixes should be applied directly to a
release (and merged with the develop branch) is something we have done
poorly to date.  We have tended to flush all changes (whether new
experimental features or hot fixes) down onto the same release, which has
caused stability problems too many times to count.

Knowing how we work today, if it were me, I would suggest using the above
workflow combined with the "forking workflow" to guard access to the
production release (master) branches.  A very small subset of the
incubator's commiters should have the ability to merge the "develop" branch
down to a master "release" branch.  It would be ideal to have someone who
is NOT performing the majority of changes on the "develop" branch take this
role to coordinate releases, ensure minimal coding standards, run through
unit and integration tests, before signing off on the release and issuing
the release artifacts.

Adam

On Fri, Nov 28, 2014 at 4:11 AM, Sergio Fernández <wi...@apache.org> wrote:

> Just in case it help, in Marmotta we follow Giflow with very good results:
>
> http://marmotta.apache.org/development#Source_code
>
> Further reading:
>
> http://nvie.com/posts/a-successful-git-branching-model/
> http://www.atlassian.com/git/workflows#!workflow-gitflow
>
> Hope that helps.
>
> On 26/11/14 17:35, Tony Kurc wrote:
>
>> I wanted to kick off a discussion about workflow in git. There are a lot
>> of
>> techniques in git for working effectively as a team, managing several
>> product versions at once, and for branching and merging code back in. It
>> looks like several other apache projects have guides for their team
>> conventions, such as Deltaspike [1] and Accumulo [2], I think it would be
>> prudent to work on some conventions for NiFi. I've used several styles,
>> one
>> of which works well for other projects I've worked on is called gitflow
>> [3]. I like the concepts of gitflow, but I really don't like depending on
>> maven plugins to execute the conventions. I'd be in favor of something
>> like
>> gitflow, not sure if others had opinions.
>>
>> Tony
>>
>> [1]https://deltaspike.apache.org/suggested-git-workflows.html
>> [2] https://accumulo.apache.org/git.html
>> [3]
>> https://www.atlassian.com/git/tutorials/comparing-workflows/
>> gitflow-workflow/
>>
>>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>

Re: git workflow for nifi

Posted by Sergio Fernández <wi...@apache.org>.

Just in case it help, in Marmotta we follow Giflow with very good results:

http://marmotta.apache.org/development#Source_code

Further reading:

http://nvie.com/posts/a-successful-git-branching-model/
http://www.atlassian.com/git/workflows#!workflow-gitflow

Hope that helps.

On 26/11/14 17:35, Tony Kurc wrote:
> I wanted to kick off a discussion about workflow in git. There are a lot of
> techniques in git for working effectively as a team, managing several
> product versions at once, and for branching and merging code back in. It
> looks like several other apache projects have guides for their team
> conventions, such as Deltaspike [1] and Accumulo [2], I think it would be
> prudent to work on some conventions for NiFi. I've used several styles, one
> of which works well for other projects I've worked on is called gitflow
> [3]. I like the concepts of gitflow, but I really don't like depending on
> maven plugins to execute the conventions. I'd be in favor of something like
> gitflow, not sure if others had opinions.
>
> Tony
>
> [1]https://deltaspike.apache.org/suggested-git-workflows.html
> [2] https://accumulo.apache.org/git.html
> [3]
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/
>

-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co

Re: git workflow for nifi

Posted by Joe Witt <jo...@gmail.com>.

We will have a lot of thinking to do in terms of ideal release/dev
processes.  This is an important doc to read:

http://incubator.apache.org/guides/releasemanagement.html

On Wed, Nov 26, 2014 at 1:32 PM, Matt Gilman <ma...@gmail.com>
wrote:

> I think a lot of this is going to depend on our development process. If we
> can establish a regular and structured release process where the releases
> are long lived (maybe weekly or bi-weekly), I think gitflow makes a lot of
> sense. Also, as team size and number of committers grows the benefit of the
> added process would certainly be realized. Until then however and assuming
> we release at our discretion initially, using the feature branch workflow
> may make more sense.
>
> Matt
>
> On Wed, Nov 26, 2014 at 11:35 AM, Tony Kurc <tr...@gmail.com> wrote:
>
> > I wanted to kick off a discussion about workflow in git. There are a lot
> of
> > techniques in git for working effectively as a team, managing several
> > product versions at once, and for branching and merging code back in. It
> > looks like several other apache projects have guides for their team
> > conventions, such as Deltaspike [1] and Accumulo [2], I think it would be
> > prudent to work on some conventions for NiFi. I've used several styles,
> one
> > of which works well for other projects I've worked on is called gitflow
> > [3]. I like the concepts of gitflow, but I really don't like depending on
> > maven plugins to execute the conventions. I'd be in favor of something
> like
> > gitflow, not sure if others had opinions.
> >
> > Tony
> >
> > [1]https://deltaspike.apache.org/suggested-git-workflows.html
> > [2] https://accumulo.apache.org/git.html
> > [3]
> >
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/
> >
>

Re: git workflow for nifi

Posted by Matt Gilman <ma...@gmail.com>.

I think a lot of this is going to depend on our development process. If we
can establish a regular and structured release process where the releases
are long lived (maybe weekly or bi-weekly), I think gitflow makes a lot of
sense. Also, as team size and number of committers grows the benefit of the
added process would certainly be realized. Until then however and assuming
we release at our discretion initially, using the feature branch workflow
may make more sense.

Matt

On Wed, Nov 26, 2014 at 11:35 AM, Tony Kurc <tr...@gmail.com> wrote:

> I wanted to kick off a discussion about workflow in git. There are a lot of
> techniques in git for working effectively as a team, managing several
> product versions at once, and for branching and merging code back in. It
> looks like several other apache projects have guides for their team
> conventions, such as Deltaspike [1] and Accumulo [2], I think it would be
> prudent to work on some conventions for NiFi. I've used several styles, one
> of which works well for other projects I've worked on is called gitflow
> [3]. I like the concepts of gitflow, but I really don't like depending on
> maven plugins to execute the conventions. I'd be in favor of something like
> gitflow, not sure if others had opinions.
>
> Tony
>
> [1]https://deltaspike.apache.org/suggested-git-workflows.html
> [2] https://accumulo.apache.org/git.html
> [3]
>
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/
>