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 <[email protected]> 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 <[email protected]> > 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 <[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 >> > >> >> > > >> > > >> > >> -- Joey Echeverria
