-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andy - Thanks for your additional thoughts. You highlight a good concern for non committers contributing code.
I'd prefer to stick with having committers developing directly on the official repository rather than forking into their personal repositories. I think working in a personal repository overly complicates things since git is already a distributed VCS. Having a personal remote copy puts us working with the official ASF repo, a remote personal repo, and our local clone. In the initial discussion [1] about migrating from Subversion to Git, I mentioned using the Feature Branch Workflow [2]. It is very similar to the Gitflow Workflow except that there is no develop branch - all feature branches are just merged straight into the master branch. I think the Feature Branch Workflow would work fine for us and would address the concern you have of non committers working off of the wrong branch. It would actually be fairly similar to how we have been working with Subversion. For committers, I'd prefer not to use pull requests. I honestly just don't think our base of committers has the cycles to review everything others commit. For work done by non committers, I really like how the Forking Workflow works out as described in the link [3] you included for the DeltaSpike project. That lays out a very clear path for non committers to contribute code. Using pull requests for work by non committers is a great path to incorporating their work into the official repository since it must be reviewed and committed by a committer anyway. More thoughts from Andy and others? Thanks, Josh [1] https://markmail.org/thread/mn2fgcnsdgjkckhl [2] https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow [3] https://deltaspike.apache.org/suggested-git-workflows.html On Wednesday, May 2, 2018 12:30:01 PM EDT Andy Kurth wrote: > Thanks for starting this Josh! > > You mentioned and linked to the "Gitflow Workflow". There are endless Git > workflow arguments on the web. *IMHO, Git workflows are like diets -- > you'll always find a contrarian who's more than happy to explain why yours > is doomed.* But anyway, I think we should think about what our goals are > and design a workflow around that. > > I think a primary goal should simplicity/ease of use. With that in mind, > I'm wondering what value does maintaining an additional *develop* branch > buy us? > > I'm mainly concerned about what may be the default workflow for a > non-committer who hasn't found or read our dev docs and hasn't examined all > of the branches in the repo. This could happen: > * Clone the *master *branch > * Work on something (yay!) > * Do some git pulls throughout development (hmm, VCL releases are few and > far between, not much is changing, no conflicts to worry about) > * Try to contribute it via patch or PR (yay!) > * Work is based on *master*, *develop *is now very different, contribution > is now extremely difficult to merge and parts of it may now be irrelevant > (fail!) > > We have seen this sort of thing happen with Subversion where someone > checked out the last release (not trunk), did some major work, then hoped > to contribute it. > > I'm thinking something more akin to the Forking Workflow > <https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflo > w> would > be an improvement. Other ASF projects are using something similar: > https://deltaspike.apache.org/suggested-git-workflows.html > https://bookkeeper.apache.org/community/contributing/ > https://cwiki.apache.org/confluence/display/COUCHDB/Git+Workflow > > I think a forking model coupled with using PRs would have a few benefits: > * People would fork to their own repo. Work however they want. > Branch/pull/rebase/push *(to their own repo)* however they want as they > develop. > * Using PRs will add a code review process. We have never done this but it > will be useful. It will help eliminate poor quality commits to master, > features being committed but never totally finished/refined, and > horrendously lacking commit messages. The VCL dev community and activity > level is *svelte *enough that this shouldn't be much of a burden. > * Project continuity - having other committers examine and review parts of > the code they ordinarily don't work on can't hurt. > * Forked repos may be tracked/linked/visible from the main VCL Github > repo. This will better let us see who is active. Having additional repos, > if public, may also help improve the project's visibility via search > results. > > Either way, the devil is in the details. Git can be highly user > unfriendly. One thing I think we need and I'd be happy to help contribute > is a bunch of cookbook style git commands in the documentation. > > Thoughts? > > Thanks, > Andy > > > On Mon, Apr 30, 2018 at 2:15 PM, Josh Thompson <[email protected]> > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > All, > > > > I created the following page to explain how to work with our Git repo > > using > > the Gitflow workflow. Please review the page and see if it seems > > sensible. > > Feel free to edit it. Once we get it to a point we agree it works, I'll > > remove the line at the top about it being in a draft state and then link > > to it > > from the navigation area. > > > > https://cwiki.apache.org/confluence/display/VCL/Working+With+Git+Source > > +Control > > > > Thanks, > > Josh > > - -- > > - ------------------------------- > > Josh Thompson > > VCL Developer > > North Carolina State University > > > > my GPG/PGP key can be found at pgp.mit.edu > > > > All electronic mail messages in connection with State business which > > are sent to or received by this account are subject to the NC Public > > Records Law and may be disclosed to third parties. > > -----BEGIN PGP SIGNATURE----- > > > > iF0EARECAB0WIQRMIdRtWXideTZDK31X8tBw1209AwUCWuddPwAKCRBX8tBw1209 > > A1TSAJ9EkIFyJCFYzycndm9fmnZHVZBHgACfRXZ4L/hhBjTDB8vYxoDbRZp5jgk= > > =0ZVj > > -----END PGP SIGNATURE----- - -- - ------------------------------- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQRMIdRtWXideTZDK31X8tBw1209AwUCWvG3bwAKCRBX8tBw1209 AxKcAJ0Z7uJrg6AML5TuGYF5l//k152sEgCfe/fClhL3kcz18zxG5ej1V8yCpK0= =cgZo -----END PGP SIGNATURE-----
