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