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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 < > > [email protected] > > > > > > > > wrote: > > > > > > > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández < > [email protected]> > > > >> 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: [email protected] > > > >> > w: http://redlink.co > > > >> > > > > > > > > > > > > > >
