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