You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by Andy Kurth <an...@ncsu.edu> on 2015/07/02 21:41:47 UTC
Re: [DISCUSS] migrate to git
+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 <jo...@ncsu.edu>
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 <mk...@vt.edu> 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-----
>
>
Re: [DISCUSS] migrate to git
Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday, July 02, 2015 3:41:47 PM Andy Kurth 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?
Commits to the develop branch would be allowed. It would be preferred that
any non-trivial work be done in branches, but I don't think we need to be
heavy handed in enforcing that. Everything would still be tracked in commits,
and would actually be more like what we are currently doing with subversion.
> 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.
I'm good with releasing 2.4.3 from trunk. I have a few minor things to commit
before we do so.
We can have a vote to move to git after getting 2.4.3 out.
Josh
> -Andy
>
>
>
>
>
> On Fri, Jun 26, 2015 at 3:48 PM, Josh Thompson <jo...@ncsu.edu>
>
> 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 <mk...@vt.edu> 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-----
- --
- -------------------------------
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
iEYEARECAAYFAlWaqZMACgkQV/LQcNdtPQM5FQCfT3ygqmYcAXAnPl55Idy/FaBQ
BKcAnjZOcqfTpzzTmB7oINcnqMQIwxDJ
=5rLU
-----END PGP SIGNATURE-----
Re: [DISCUSS] migrate to git
Posted by Aaron Coburn <ac...@amherst.edu>.
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 <aa...@ncsu.edu> 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 <an...@ncsu.edu> 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 <jo...@ncsu.edu>
>> 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 <mk...@vt.edu> 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.
Re: [DISCUSS] migrate to git
Posted by Aaron Peeler <aa...@ncsu.edu>.
+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 <an...@ncsu.edu> 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 <jo...@ncsu.edu>
> 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 <mk...@vt.edu> 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.