I am also +1 on moving to Git and organizing branches by jira issue. Aaron Coburn
> On Jul 6, 2015, at 8:05 AM, Aaron Peeler <[email protected]> wrote: > > +1 on the Git workflow > > I support just releasing from trunk for a 2.4.3 bug-fix release in > order to move forward and focus on the Git workflows. > > Aaron > > On Thu, Jul 2, 2015 at 3:41 PM, Andy Kurth <[email protected]> wrote: >> +1 on the overall Git workflow. I like the idea of organizing feature >> branches by Jira issue. >> >> Would commits ever be done/allowed directly to the develop branch? It >> isn't described in the branching model page you shared but their diagram >> shows successive yellow dots without a merge from a feature branch. I'm >> guessing one may commit very minor changes to develop? If this is the >> case, on the one hand it makes things a bit easier in that I wouldn't want >> to have to create a branch and Jira issue if I'm just cleaning up code >> comments or fixing typos. On the other hand I could see the temptation to >> be lazy and committing functional changes to the develop branch. Thoughts? >> >> Regarding the 2.4.3 bugfix branch, what do you think about just releasing >> trunk? The current backend code in trunk is stable. The commits I have >> made have either been bug fixes or related to the VM migration feature -- >> currently a vcld -setup option. This changes made for this feature are >> mostly contained within dedicated subroutines. We could leave it in the >> code but prevent it from showing up. Creating a bugfix branch off of 2.4.2 >> at this point would require us having to go through all of the commits made >> since mid-April and commit them again, which could be error prone. >> >> -Andy >> >> >> >> >> >> On Fri, Jun 26, 2015 at 3:48 PM, Josh Thompson <[email protected]> >> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Here's what I suggest: >>> >>> 1) Go ahead and create a branch for a bugfix release as 2.4.3 in subversion >>> from the release-2.4.2 tag >>> 2) fix any know bugs in 2.4.2, commit the fixes to trunk and the 2.4.3 >>> branch >>> 3) release 2.4.3 >>> 4) migrate to git >>> >>> For git, I think we should follow the Gitflow Workflow. This would involve >>> maintaining a development branch on which developers would create branches >>> for >>> any development work, with the branches having a name related to the >>> feature >>> and an associated JIRA issue - something like VCL123-some_new_feature. >>> Once >>> development is complete in the branch, the developer either goes ahead and >>> merges it into the main development branch, or if the developer wants >>> feedback >>> first, a pull request can be done before merging it in. Then, the >>> developer >>> would merge the branch in after handling any suggestions/edits from others. >>> >>> At release time, we create a release branch, and tag it each time an RC is >>> released. Any bugs found are fixed in the release branch and also merged >>> into >>> the main development branch. Once a vote is successful, the release >>> branch is >>> merged into the master branch, a tag is created, and the release artifact >>> is >>> generated from that. (I do have a question here - the master branch after >>> the >>> merge would have to exactly match the release branch, otherwise we >>> wouldn't be >>> releasing exactly what was voted on. So, that may need some more >>> research.) >>> >>> I know I've had times when I've been working on a new feature that I >>> somewhat >>> have to pull out before commiting work to HEAD leading up to a release. >>> This >>> method allows development to continue on such features, but left in a >>> branch >>> that doesn't affect the release process. >>> >>> Here is a link for more reading on Gitflow: >>> >>> http://nvie.com/posts/a-successful-git-branching-model/ >>> >>> How does this sound? >>> >>> Josh >>> >>> On Monday, June 22, 2015 3:41:08 PM you wrote: >>>> - gpg control packet >>>> After reading over the link Akkaash sent and doing a little more >>> research, I >>>> think we'd be okay with the "Feature Branch Workflow". However, if we >>>> really want to get structured, we could move up to the "Gitflow >>> Workflow". >>>> >>>> It seems like the Feature Branch Workflow is really similar to how we >>>> currently work with subversion, except that with subversion, our >>> "branches" >>>> are just our local working copies. When I have something to work on, I >>> make >>>> sure my local copy is up to date, then do the work, then commit it back >>> to >>>> trunk. If changes have been made in trunk to the files I'm committing, I >>>> have to merge those changes in to my local copy before I can do the >>> commit. >>>> With git, we'd actually be creating branches for doing work, which would >>>> definitely provide some great benefits, but I feel like the workflow >>> would >>>> be really similar. >>>> >>>> Josh >>>> >>>> On Wednesday, June 10, 2015 11:03:51 AM Andy Kurth wrote: >>>>> On Tue, Jun 9, 2015 at 1:47 PM, Mark Gardner <[email protected]> wrote: >>>>>> Switching to git (well DVCS of any kind) from subversion will >>> require us >>>>>> to >>>>>> have a discussion of workflow as there was only one way to work with >>>>>> subversion but git is more of a version control toolkit (even more >>> than >>>>>> other DVCS tools). Workflow will be where people will feel most lost >>>>>> right >>>>>> after the change. >>>>>> >>>>>> Mark >>>>>> -- >>>>>> Mark Gardner >>>>>> -- >>>>> >>>>> Good point Mark. It is not appropriate at this point to have a vote or >>>>> make a request to infrastructure. It would be helpful if the workflow >>> was >>>>> discussed/planned/documented before switching. This would be very >>>>> beneficial for both committers and non-committers. >>>>> >>>>> The link Akkaash sent is a good starting point. I haven't worked much >>>>> with >>>>> git so this is helpful. Things I'd like to be worked out and >>> documented >>>>> (actual git commands should be included for all of these): >>>>> -General development workflow for committers >>>>> -Workflow for non-committers who are interested in contributing >>>>> code/patches -Workflow for creating a release >>>>> -How to handle major vs. minor/bugfix releases >>>>> >>>>> On a related note, migrating to git affects how we plan for the next >>>>> release. We never created a post-2.4.2 bugfix branch in subversion and >>>>> some commits have been made to trunk which should have probably been >>>>> mirrored into a bugfix branch. We need to decide how to handle this. >>>>> Should we create a bugfix branch in subversion from the 2.4.2 tag >>> before >>>>> the migration to git and apply changes made to trunk, or work this out >>>>> after migrating? >>>>> >>>>> -Andy >>>> >>>> -- >>>> ------------------------------- >>>> 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. >>> - -- >>> - ------------------------------- >>> 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----- >>> Version: GnuPG v2 >>> >>> iEYEARECAAYFAlWNrKIACgkQV/LQcNdtPQOArQCfZjwzJ6R/OpNq8W/LcmThfuOJ >>> pqQAnRF2G0bgGy2FYRGCiQPwGWMBgIb+ >>> =ULHv >>> -----END PGP SIGNATURE----- >>> >>> > > > > -- > Aaron Peeler > Program Manager > Virtual Computing Lab > NC State University > > 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
