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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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: [email protected] > > > w: http://redlink.co > > > > > >
