You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Christopher <ct...@apache.org> on 2013/06/01 22:28:13 UTC
Re: GIT
Reviewing this thread, it seems everyone is pretty much in favor of
this. I propose we proceed by electing a "git transition advisor"...
someone who:
1) is sufficiently knowledgeable with git to identify roadblocks
during the transition and is willing to make it a point to propose and
follow through with solutions,
2) can serve as the main point of contact with INFRA tickets related
to the transition,
3) can advise other developers on best practices for things like when
to branch, where to put contribs, when to delete a branch (if ever),
etc. for things related to the shared repo.
Item 3 is really something we can all do to the extent that our
expertise allows, but it'd be nice to have somebody willing to do item
2, in the context of their experience in item 1.
I would like to nominate Josh Elser, because I think he's qualified,
and because his exact response to this inquiry was "Yay, git."
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, May 21, 2013 at 5:44 PM, Christopher <ct...@apache.org> wrote:
> I'm sure this has been entertained before, I'm starting to think that
> we should seriously consider switching to git, maybe sooner (during
> 1.6 development cycle?).
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
Re: GIT
Posted by David Medinets <da...@gmail.com>.
+1 for <apacheID>/<jira ticket> - I'm ambivalent about the rest.
On Tue, Jun 4, 2013 at 6:11 PM, Christopher <ct...@apache.org> wrote:
> Also, I think short-lived feature/bugfix/etc. branches make sense in
> the form, "<apacheID>/ACCUMULO-<issue#>".
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, Jun 4, 2013 at 6:09 PM, Christopher <ct...@apache.org> wrote:
> > I can get behind this also, but I have an additional suggestion that
> > diverges from the proposed model at
> > http://nvie.com/posts/a-successful-git-branching-model/ (suggested
> > earlier in this thread):
> >
> > I'm not a fan of separate "master" and "develop" branches, since
> > "master" is only used as a pointer for tracking the latest and
> > greatest stable tag. I think just a "master" would be fine (for active
> > development on the next anticipated major release), because I think
> > it's safe to assume people know what tags are and how to use them if
> > they want a stable version. If we *really* need a pointer, I'd rather
> > call it "stable", as it's more explicit.
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> >
> > On Tue, Jun 4, 2013 at 5:51 PM, Keith Turner <ke...@deenlo.com> wrote:
> >> On Tue, Jun 4, 2013 at 10:01 AM, Josh Elser <jo...@gmail.com>
> wrote:
> >>
> >>> On 6/4/13 9:35 AM, Keith Turner wrote:
> >>>
> >>>> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser<jo...@gmail.com>
> wrote:
> >>>>
> >>>> >Yay, Git. Wait...
> >>>>> >
> >>>>> >I was going to wait to respond until I collected all of the info,
> but
> >>>>> >since I still haven't gotten that done yet, I figured I should just
> say
> >>>>> >"sure".
> >>>>> >
> >>>>> >The one thing I do want to get hammered out is the general workflow
> we
> >>>>> >plan to use. I believe that one "unstable" or "development" branch
> will
> >>>>> >satisfy most use cases as we typically don't have much active
> >>>>> development
> >>>>> >against previous major releases.
> >>>>> >
> >>>>> >The thing I don't care for (putting it mildly) is long-running
> >>>>> >minor-release branches. I'm curious of suggestions that people might
> >>>>> have
> >>>>> >for how to work around this. One
> >>>>>
> >>>>
> >>>> Why? What problems are you thinking of w/ long-running minor release
> >>>> branches?
> >>>>
> >>>
> >>> I do not like them. It's mainly a personal opinion. Most modern SCM
> tools
> >>> (even that 'terrible' SVN) strongly encourage you to release early and
> >>> often. As such, I don't like having branches named like tags/releases.
> This
> >>> is mostly a personal opinion; however, you can also read that as
> opinions
> >>> after using git for ~5 years.
> >>>
> >>
> >> Discussed this w/ Christopher and Josh. I understand Josh's point of
> view
> >> a bit better now. One thing I was unsure about was what to name these
> >> transient branches for gathering bug fixes. Christopher suggested using
> >> snapshots, which seems very natural to me.
> >>
> >> * For serious bugs in 1.4.3 take 1.4.3 tag and create 1.4.4-SNAPSHOT
> >> branch
> >> * Merge bug fixes to 1.4.4-SNAPSHOT from bug fix branches
> >> * Eventually tag 1.4.4 and delete 1.4.4-SNAPSHOT branch
> >> * 1.4.5-SNAPSHOT would only be created on an as needed basis.
> >>
> >> I think this is nicer than leaving a 1.4 branch around.
> >>
> >>
> >>>
> >>>> >possibility would be to be git-tag heavy while being more lax on
> >>>>> official
> >>>>> >apache releases.
> >>>>> >
> >>>>> >Merits:
> >>>>> >- Less merging through 2-3 branches which a bug-fix might apply
> >>>>> >(1.4->1.5->1.6)
> >>>>> >- Less clutter in the branch space (could be moot if we impose some
> sort
> >>>>> >of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
> >>>>> >minor/ACCUMULO-XXXX)
> >>>>> >- Quicker availability of fixes for consumers (after a fix, a new
> tag is
> >>>>> >made)
> >>>>> >
> >>>>> >Downsides:
> >>>>> >- Could create more work for us as we would be noting new minor
> >>>>> releases.
> >>>>> >Does Christopher's release work mitigate some/most of this?
> >>>>> >- Creating git-tags without making an official release_might_
> skirt a
> >>>>>
> >>>>> >line on ASF releases. Some artifact that is intended for public
> >>>>> consumption
> >>>>> >is meant to follow the release process.
> >>>>> >
> >>>>> >
> >>>>>
> >>>> It seems like you have a specific workflow in mind, but its not clear
> to
> >>>> me
> >>>> exactly what you are thinking. Are you planning on elaborating on
> this
> >>>> tonight? Is this workflow written up somewhere? If its not written
> up, a
> >>>> few quick example scenarios would probably help me get on the same
> page.
> >>>>
> >>>
> >>> That's correct. I don't have the time to make a good write-up right
> now.
> >>> I'll try to outline what I think would work fully tonight, but I tried
> to
> >>> outline the general gist of what I think is best.
> >>>
> >>>
> >>>
> >>>> >Personally, I'd consider making the bold assumption that, over
> time, we
> >>>>> >will create the infrastructure for ourselves to make better and
> better
> >>>>> >releases which will also mitigate this. I'm curious what everyone
> else
> >>>>> >thinks.
> >>>>> >
> >>>>> >I'll try to make time tonight to get info on all of the necessary
> below.
> >>>>>
> >>>>
>
Re: GIT
Posted by Christopher <ct...@apache.org>.
Also, I think short-lived feature/bugfix/etc. branches make sense in
the form, "<apacheID>/ACCUMULO-<issue#>".
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Jun 4, 2013 at 6:09 PM, Christopher <ct...@apache.org> wrote:
> I can get behind this also, but I have an additional suggestion that
> diverges from the proposed model at
> http://nvie.com/posts/a-successful-git-branching-model/ (suggested
> earlier in this thread):
>
> I'm not a fan of separate "master" and "develop" branches, since
> "master" is only used as a pointer for tracking the latest and
> greatest stable tag. I think just a "master" would be fine (for active
> development on the next anticipated major release), because I think
> it's safe to assume people know what tags are and how to use them if
> they want a stable version. If we *really* need a pointer, I'd rather
> call it "stable", as it's more explicit.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, Jun 4, 2013 at 5:51 PM, Keith Turner <ke...@deenlo.com> wrote:
>> On Tue, Jun 4, 2013 at 10:01 AM, Josh Elser <jo...@gmail.com> wrote:
>>
>>> On 6/4/13 9:35 AM, Keith Turner wrote:
>>>
>>>> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser<jo...@gmail.com> wrote:
>>>>
>>>> >Yay, Git. Wait...
>>>>> >
>>>>> >I was going to wait to respond until I collected all of the info, but
>>>>> >since I still haven't gotten that done yet, I figured I should just say
>>>>> >"sure".
>>>>> >
>>>>> >The one thing I do want to get hammered out is the general workflow we
>>>>> >plan to use. I believe that one "unstable" or "development" branch will
>>>>> >satisfy most use cases as we typically don't have much active
>>>>> development
>>>>> >against previous major releases.
>>>>> >
>>>>> >The thing I don't care for (putting it mildly) is long-running
>>>>> >minor-release branches. I'm curious of suggestions that people might
>>>>> have
>>>>> >for how to work around this. One
>>>>>
>>>>
>>>> Why? What problems are you thinking of w/ long-running minor release
>>>> branches?
>>>>
>>>
>>> I do not like them. It's mainly a personal opinion. Most modern SCM tools
>>> (even that 'terrible' SVN) strongly encourage you to release early and
>>> often. As such, I don't like having branches named like tags/releases. This
>>> is mostly a personal opinion; however, you can also read that as opinions
>>> after using git for ~5 years.
>>>
>>
>> Discussed this w/ Christopher and Josh. I understand Josh's point of view
>> a bit better now. One thing I was unsure about was what to name these
>> transient branches for gathering bug fixes. Christopher suggested using
>> snapshots, which seems very natural to me.
>>
>> * For serious bugs in 1.4.3 take 1.4.3 tag and create 1.4.4-SNAPSHOT
>> branch
>> * Merge bug fixes to 1.4.4-SNAPSHOT from bug fix branches
>> * Eventually tag 1.4.4 and delete 1.4.4-SNAPSHOT branch
>> * 1.4.5-SNAPSHOT would only be created on an as needed basis.
>>
>> I think this is nicer than leaving a 1.4 branch around.
>>
>>
>>>
>>>> >possibility would be to be git-tag heavy while being more lax on
>>>>> official
>>>>> >apache releases.
>>>>> >
>>>>> >Merits:
>>>>> >- Less merging through 2-3 branches which a bug-fix might apply
>>>>> >(1.4->1.5->1.6)
>>>>> >- Less clutter in the branch space (could be moot if we impose some sort
>>>>> >of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
>>>>> >minor/ACCUMULO-XXXX)
>>>>> >- Quicker availability of fixes for consumers (after a fix, a new tag is
>>>>> >made)
>>>>> >
>>>>> >Downsides:
>>>>> >- Could create more work for us as we would be noting new minor
>>>>> releases.
>>>>> >Does Christopher's release work mitigate some/most of this?
>>>>> >- Creating git-tags without making an official release_might_ skirt a
>>>>>
>>>>> >line on ASF releases. Some artifact that is intended for public
>>>>> consumption
>>>>> >is meant to follow the release process.
>>>>> >
>>>>> >
>>>>>
>>>> It seems like you have a specific workflow in mind, but its not clear to
>>>> me
>>>> exactly what you are thinking. Are you planning on elaborating on this
>>>> tonight? Is this workflow written up somewhere? If its not written up, a
>>>> few quick example scenarios would probably help me get on the same page.
>>>>
>>>
>>> That's correct. I don't have the time to make a good write-up right now.
>>> I'll try to outline what I think would work fully tonight, but I tried to
>>> outline the general gist of what I think is best.
>>>
>>>
>>>
>>>> >Personally, I'd consider making the bold assumption that, over time, we
>>>>> >will create the infrastructure for ourselves to make better and better
>>>>> >releases which will also mitigate this. I'm curious what everyone else
>>>>> >thinks.
>>>>> >
>>>>> >I'll try to make time tonight to get info on all of the necessary below.
>>>>>
>>>>
Re: GIT
Posted by Christopher <ct...@apache.org>.
I don't think we should restrict the development branches to be local.
They can be pushed, but they should still be removed from the remote
after merging to master, just to keep things pretty and organized.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jun 5, 2013 at 12:49 PM, David Medinets
<da...@gmail.com> wrote:
>>+1 for only having one infinite-lifetime branch.
>
> Do we all have the same understanding that branches and tags (and SHA-1
> hashes) are essentially the same thing in git? Is the Accumulo community
> saying that a release gets a git tag but development is done inside a
> branch? Each developer creates a personal branch, does stuff and then
> merges that branch (details TBD) into master. The development branch is
> always local and not pushed to the official git repository? I'll note that
> this description does not preclude developers from sharing each other's
> branches in a point-to-point network.
Re: GIT
Posted by David Medinets <da...@gmail.com>.
>+1 for only having one infinite-lifetime branch.
Do we all have the same understanding that branches and tags (and SHA-1
hashes) are essentially the same thing in git? Is the Accumulo community
saying that a release gets a git tag but development is done inside a
branch? Each developer creates a personal branch, does stuff and then
merges that branch (details TBD) into master. The development branch is
always local and not pushed to the official git repository? I'll note that
this description does not preclude developers from sharing each other's
branches in a point-to-point network.
Re: GIT
Posted by Billie Rinaldi <bi...@gmail.com>.
On Tue, Jun 4, 2013 at 3:09 PM, Christopher <ct...@apache.org> wrote:
> I can get behind this also, but I have an additional suggestion that
> diverges from the proposed model at
> http://nvie.com/posts/a-successful-git-branching-model/ (suggested
> earlier in this thread):
>
> I'm not a fan of separate "master" and "develop" branches, since
> "master" is only used as a pointer for tracking the latest and
> greatest stable tag. I think just a "master" would be fine (for active
> development on the next anticipated major release), because I think
> it's safe to assume people know what tags are and how to use them if
> they want a stable version. If we *really* need a pointer, I'd rather
> call it "stable", as it's more explicit.
>
+1 for only having one infinite-lifetime branch.
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, Jun 4, 2013 at 5:51 PM, Keith Turner <ke...@deenlo.com> wrote:
> > On Tue, Jun 4, 2013 at 10:01 AM, Josh Elser <jo...@gmail.com>
> wrote:
> >
> >> On 6/4/13 9:35 AM, Keith Turner wrote:
> >>
> >>> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser<jo...@gmail.com>
> wrote:
> >>>
> >>> >Yay, Git. Wait...
> >>>> >
> >>>> >I was going to wait to respond until I collected all of the info, but
> >>>> >since I still haven't gotten that done yet, I figured I should just
> say
> >>>> >"sure".
> >>>> >
> >>>> >The one thing I do want to get hammered out is the general workflow
> we
> >>>> >plan to use. I believe that one "unstable" or "development" branch
> will
> >>>> >satisfy most use cases as we typically don't have much active
> >>>> development
> >>>> >against previous major releases.
> >>>> >
> >>>> >The thing I don't care for (putting it mildly) is long-running
> >>>> >minor-release branches. I'm curious of suggestions that people might
> >>>> have
> >>>> >for how to work around this. One
> >>>>
> >>>
> >>> Why? What problems are you thinking of w/ long-running minor release
> >>> branches?
> >>>
> >>
> >> I do not like them. It's mainly a personal opinion. Most modern SCM
> tools
> >> (even that 'terrible' SVN) strongly encourage you to release early and
> >> often. As such, I don't like having branches named like tags/releases.
> This
> >> is mostly a personal opinion; however, you can also read that as
> opinions
> >> after using git for ~5 years.
> >>
> >
> > Discussed this w/ Christopher and Josh. I understand Josh's point of
> view
> > a bit better now. One thing I was unsure about was what to name these
> > transient branches for gathering bug fixes. Christopher suggested using
> > snapshots, which seems very natural to me.
> >
> > * For serious bugs in 1.4.3 take 1.4.3 tag and create 1.4.4-SNAPSHOT
> > branch
> > * Merge bug fixes to 1.4.4-SNAPSHOT from bug fix branches
> > * Eventually tag 1.4.4 and delete 1.4.4-SNAPSHOT branch
> > * 1.4.5-SNAPSHOT would only be created on an as needed basis.
> >
> > I think this is nicer than leaving a 1.4 branch around.
> >
> >
> >>
> >>> >possibility would be to be git-tag heavy while being more lax on
> >>>> official
> >>>> >apache releases.
> >>>> >
> >>>> >Merits:
> >>>> >- Less merging through 2-3 branches which a bug-fix might apply
> >>>> >(1.4->1.5->1.6)
> >>>> >- Less clutter in the branch space (could be moot if we impose some
> sort
> >>>> >of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
> >>>> >minor/ACCUMULO-XXXX)
> >>>> >- Quicker availability of fixes for consumers (after a fix, a new
> tag is
> >>>> >made)
> >>>> >
> >>>> >Downsides:
> >>>> >- Could create more work for us as we would be noting new minor
> >>>> releases.
> >>>> >Does Christopher's release work mitigate some/most of this?
> >>>> >- Creating git-tags without making an official release_might_ skirt
> a
> >>>>
> >>>> >line on ASF releases. Some artifact that is intended for public
> >>>> consumption
> >>>> >is meant to follow the release process.
> >>>> >
> >>>> >
> >>>>
> >>> It seems like you have a specific workflow in mind, but its not clear
> to
> >>> me
> >>> exactly what you are thinking. Are you planning on elaborating on this
> >>> tonight? Is this workflow written up somewhere? If its not written
> up, a
> >>> few quick example scenarios would probably help me get on the same
> page.
> >>>
> >>
> >> That's correct. I don't have the time to make a good write-up right now.
> >> I'll try to outline what I think would work fully tonight, but I tried
> to
> >> outline the general gist of what I think is best.
> >>
> >>
> >>
> >>> >Personally, I'd consider making the bold assumption that, over time,
> we
> >>>> >will create the infrastructure for ourselves to make better and
> better
> >>>> >releases which will also mitigate this. I'm curious what everyone
> else
> >>>> >thinks.
> >>>> >
> >>>> >I'll try to make time tonight to get info on all of the necessary
> below.
> >>>>
> >>>
>
Re: GIT
Posted by Christopher <ct...@apache.org>.
I can get behind this also, but I have an additional suggestion that
diverges from the proposed model at
http://nvie.com/posts/a-successful-git-branching-model/ (suggested
earlier in this thread):
I'm not a fan of separate "master" and "develop" branches, since
"master" is only used as a pointer for tracking the latest and
greatest stable tag. I think just a "master" would be fine (for active
development on the next anticipated major release), because I think
it's safe to assume people know what tags are and how to use them if
they want a stable version. If we *really* need a pointer, I'd rather
call it "stable", as it's more explicit.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Jun 4, 2013 at 5:51 PM, Keith Turner <ke...@deenlo.com> wrote:
> On Tue, Jun 4, 2013 at 10:01 AM, Josh Elser <jo...@gmail.com> wrote:
>
>> On 6/4/13 9:35 AM, Keith Turner wrote:
>>
>>> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser<jo...@gmail.com> wrote:
>>>
>>> >Yay, Git. Wait...
>>>> >
>>>> >I was going to wait to respond until I collected all of the info, but
>>>> >since I still haven't gotten that done yet, I figured I should just say
>>>> >"sure".
>>>> >
>>>> >The one thing I do want to get hammered out is the general workflow we
>>>> >plan to use. I believe that one "unstable" or "development" branch will
>>>> >satisfy most use cases as we typically don't have much active
>>>> development
>>>> >against previous major releases.
>>>> >
>>>> >The thing I don't care for (putting it mildly) is long-running
>>>> >minor-release branches. I'm curious of suggestions that people might
>>>> have
>>>> >for how to work around this. One
>>>>
>>>
>>> Why? What problems are you thinking of w/ long-running minor release
>>> branches?
>>>
>>
>> I do not like them. It's mainly a personal opinion. Most modern SCM tools
>> (even that 'terrible' SVN) strongly encourage you to release early and
>> often. As such, I don't like having branches named like tags/releases. This
>> is mostly a personal opinion; however, you can also read that as opinions
>> after using git for ~5 years.
>>
>
> Discussed this w/ Christopher and Josh. I understand Josh's point of view
> a bit better now. One thing I was unsure about was what to name these
> transient branches for gathering bug fixes. Christopher suggested using
> snapshots, which seems very natural to me.
>
> * For serious bugs in 1.4.3 take 1.4.3 tag and create 1.4.4-SNAPSHOT
> branch
> * Merge bug fixes to 1.4.4-SNAPSHOT from bug fix branches
> * Eventually tag 1.4.4 and delete 1.4.4-SNAPSHOT branch
> * 1.4.5-SNAPSHOT would only be created on an as needed basis.
>
> I think this is nicer than leaving a 1.4 branch around.
>
>
>>
>>> >possibility would be to be git-tag heavy while being more lax on
>>>> official
>>>> >apache releases.
>>>> >
>>>> >Merits:
>>>> >- Less merging through 2-3 branches which a bug-fix might apply
>>>> >(1.4->1.5->1.6)
>>>> >- Less clutter in the branch space (could be moot if we impose some sort
>>>> >of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
>>>> >minor/ACCUMULO-XXXX)
>>>> >- Quicker availability of fixes for consumers (after a fix, a new tag is
>>>> >made)
>>>> >
>>>> >Downsides:
>>>> >- Could create more work for us as we would be noting new minor
>>>> releases.
>>>> >Does Christopher's release work mitigate some/most of this?
>>>> >- Creating git-tags without making an official release_might_ skirt a
>>>>
>>>> >line on ASF releases. Some artifact that is intended for public
>>>> consumption
>>>> >is meant to follow the release process.
>>>> >
>>>> >
>>>>
>>> It seems like you have a specific workflow in mind, but its not clear to
>>> me
>>> exactly what you are thinking. Are you planning on elaborating on this
>>> tonight? Is this workflow written up somewhere? If its not written up, a
>>> few quick example scenarios would probably help me get on the same page.
>>>
>>
>> That's correct. I don't have the time to make a good write-up right now.
>> I'll try to outline what I think would work fully tonight, but I tried to
>> outline the general gist of what I think is best.
>>
>>
>>
>>> >Personally, I'd consider making the bold assumption that, over time, we
>>>> >will create the infrastructure for ourselves to make better and better
>>>> >releases which will also mitigate this. I'm curious what everyone else
>>>> >thinks.
>>>> >
>>>> >I'll try to make time tonight to get info on all of the necessary below.
>>>>
>>>
Re: GIT
Posted by Keith Turner <ke...@deenlo.com>.
On Tue, Jun 4, 2013 at 10:01 AM, Josh Elser <jo...@gmail.com> wrote:
> On 6/4/13 9:35 AM, Keith Turner wrote:
>
>> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser<jo...@gmail.com> wrote:
>>
>> >Yay, Git. Wait...
>>> >
>>> >I was going to wait to respond until I collected all of the info, but
>>> >since I still haven't gotten that done yet, I figured I should just say
>>> >"sure".
>>> >
>>> >The one thing I do want to get hammered out is the general workflow we
>>> >plan to use. I believe that one "unstable" or "development" branch will
>>> >satisfy most use cases as we typically don't have much active
>>> development
>>> >against previous major releases.
>>> >
>>> >The thing I don't care for (putting it mildly) is long-running
>>> >minor-release branches. I'm curious of suggestions that people might
>>> have
>>> >for how to work around this. One
>>>
>>
>> Why? What problems are you thinking of w/ long-running minor release
>> branches?
>>
>
> I do not like them. It's mainly a personal opinion. Most modern SCM tools
> (even that 'terrible' SVN) strongly encourage you to release early and
> often. As such, I don't like having branches named like tags/releases. This
> is mostly a personal opinion; however, you can also read that as opinions
> after using git for ~5 years.
>
Discussed this w/ Christopher and Josh. I understand Josh's point of view
a bit better now. One thing I was unsure about was what to name these
transient branches for gathering bug fixes. Christopher suggested using
snapshots, which seems very natural to me.
* For serious bugs in 1.4.3 take 1.4.3 tag and create 1.4.4-SNAPSHOT
branch
* Merge bug fixes to 1.4.4-SNAPSHOT from bug fix branches
* Eventually tag 1.4.4 and delete 1.4.4-SNAPSHOT branch
* 1.4.5-SNAPSHOT would only be created on an as needed basis.
I think this is nicer than leaving a 1.4 branch around.
>
>> >possibility would be to be git-tag heavy while being more lax on
>>> official
>>> >apache releases.
>>> >
>>> >Merits:
>>> >- Less merging through 2-3 branches which a bug-fix might apply
>>> >(1.4->1.5->1.6)
>>> >- Less clutter in the branch space (could be moot if we impose some sort
>>> >of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
>>> >minor/ACCUMULO-XXXX)
>>> >- Quicker availability of fixes for consumers (after a fix, a new tag is
>>> >made)
>>> >
>>> >Downsides:
>>> >- Could create more work for us as we would be noting new minor
>>> releases.
>>> >Does Christopher's release work mitigate some/most of this?
>>> >- Creating git-tags without making an official release_might_ skirt a
>>>
>>> >line on ASF releases. Some artifact that is intended for public
>>> consumption
>>> >is meant to follow the release process.
>>> >
>>> >
>>>
>> It seems like you have a specific workflow in mind, but its not clear to
>> me
>> exactly what you are thinking. Are you planning on elaborating on this
>> tonight? Is this workflow written up somewhere? If its not written up, a
>> few quick example scenarios would probably help me get on the same page.
>>
>
> That's correct. I don't have the time to make a good write-up right now.
> I'll try to outline what I think would work fully tonight, but I tried to
> outline the general gist of what I think is best.
>
>
>
>> >Personally, I'd consider making the bold assumption that, over time, we
>>> >will create the infrastructure for ourselves to make better and better
>>> >releases which will also mitigate this. I'm curious what everyone else
>>> >thinks.
>>> >
>>> >I'll try to make time tonight to get info on all of the necessary below.
>>>
>>
Re: GIT
Posted by Josh Elser <jo...@gmail.com>.
On 6/4/13 9:35 AM, Keith Turner wrote:
> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser<jo...@gmail.com> wrote:
>
>> >Yay, Git. Wait...
>> >
>> >I was going to wait to respond until I collected all of the info, but
>> >since I still haven't gotten that done yet, I figured I should just say
>> >"sure".
>> >
>> >The one thing I do want to get hammered out is the general workflow we
>> >plan to use. I believe that one "unstable" or "development" branch will
>> >satisfy most use cases as we typically don't have much active development
>> >against previous major releases.
>> >
>> >The thing I don't care for (putting it mildly) is long-running
>> >minor-release branches. I'm curious of suggestions that people might have
>> >for how to work around this. One
>
> Why? What problems are you thinking of w/ long-running minor release
> branches?
I do not like them. It's mainly a personal opinion. Most modern SCM
tools (even that 'terrible' SVN) strongly encourage you to release early
and often. As such, I don't like having branches named like
tags/releases. This is mostly a personal opinion; however, you can also
read that as opinions after using git for ~5 years.
>
>> >possibility would be to be git-tag heavy while being more lax on official
>> >apache releases.
>> >
>> >Merits:
>> >- Less merging through 2-3 branches which a bug-fix might apply
>> >(1.4->1.5->1.6)
>> >- Less clutter in the branch space (could be moot if we impose some sort
>> >of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
>> >minor/ACCUMULO-XXXX)
>> >- Quicker availability of fixes for consumers (after a fix, a new tag is
>> >made)
>> >
>> >Downsides:
>> >- Could create more work for us as we would be noting new minor releases.
>> >Does Christopher's release work mitigate some/most of this?
>> >- Creating git-tags without making an official release_might_ skirt a
>> >line on ASF releases. Some artifact that is intended for public consumption
>> >is meant to follow the release process.
>> >
>> >
> It seems like you have a specific workflow in mind, but its not clear to me
> exactly what you are thinking. Are you planning on elaborating on this
> tonight? Is this workflow written up somewhere? If its not written up, a
> few quick example scenarios would probably help me get on the same page.
That's correct. I don't have the time to make a good write-up right now.
I'll try to outline what I think would work fully tonight, but I tried
to outline the general gist of what I think is best.
>
>> >Personally, I'd consider making the bold assumption that, over time, we
>> >will create the infrastructure for ourselves to make better and better
>> >releases which will also mitigate this. I'm curious what everyone else
>> >thinks.
>> >
>> >I'll try to make time tonight to get info on all of the necessary below.
GIT
Posted by Drew Farris <dr...@apache.org>.
Joe,
Thanks for sharing this. How does Kafka handle branching, etc?
On Tuesday, June 4, 2013, Joe Stein wrote:
> Here is the git flow we use w/ Apache Kafka
> https://cwiki.apache.org/confluence/display/KAFKA/Git+Workflow
>
> folks have liked the transition from svn IMHO
>
>
>
>
Re: GIT
Posted by Joe Stein <cr...@gmail.com>.
Here is the git flow we use w/ Apache Kafka
https://cwiki.apache.org/confluence/display/KAFKA/Git+Workflow
folks have liked the transition from svn IMHO
On Tue, Jun 4, 2013 at 2:34 PM, Christopher <ct...@apache.org> wrote:
> Personally, I'm fine with not having a super-long running release
> branch, but I like them for a few reasons:
>
> 1. It doesn't force rapid releases that are time-consuming and require
> testing, but we still have that option if we want.
> 2. We can batch a few bugfixes and work on a bugfix release schedule
> for nice-to-have, but not urgent bugfixes (patch Tuesdays? :)
> 3. We're going to create this branch anyway, so we can stabilize
> things for testing prior to release... so why not leave it around for
> bugfixes?
> 4. Pretending we won't have bugfixes for a prior release is possibly
> delusional, and it seems like it doesn't really avoid anything
> regarding merging over multiple branches... when we patch, we'll just
> have to create these branches from their respective tags before we do
> this process. It doesn't seem to save us from this merging process.
>
> In short, I don't think leaving these branches around diverges from
> the proposed branching model... it just keeps them around until we
> decide that branch is EOL. If we leave a branch around until it
> reaches EOL, and we never make a bugfix in it, then no big deal, no
> harm done... just delete the branch at EOL.
>
> I think branches should be hierarchical for subprojects and contribs,
> as in: contrib/InstamoOrWhatever (unless there's a better way to
> handle contribs...?)
>
> I think ticket/feature branches should be deleted after they've merged
> back to develop, and should also be hierarchical, as in:
> feature/ACCUMULO-9001
>
> As for tags, I'm not comfortable tagging anything we haven't voted on
> as an official release, and I think the time-consuming nature of that
> should be factored in, when considering these long-running bugfix
> branches for a release line.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, Jun 4, 2013 at 9:35 AM, Keith Turner <ke...@deenlo.com> wrote:
> > On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser <jo...@gmail.com> wrote:
> >
> >> Yay, Git. Wait...
> >>
> >> I was going to wait to respond until I collected all of the info, but
> >> since I still haven't gotten that done yet, I figured I should just say
> >> "sure".
> >>
> >> The one thing I do want to get hammered out is the general workflow we
> >> plan to use. I believe that one "unstable" or "development" branch will
> >> satisfy most use cases as we typically don't have much active
> development
> >> against previous major releases.
> >>
> >> The thing I don't care for (putting it mildly) is long-running
> >> minor-release branches. I'm curious of suggestions that people might
> have
> >> for how to work around this. One
> >
> >
> > Why? What problems are you thinking of w/ long-running minor release
> > branches?
> >
> >
> >> possibility would be to be git-tag heavy while being more lax on
> official
> >> apache releases.
> >>
> >> Merits:
> >> - Less merging through 2-3 branches which a bug-fix might apply
> >> (1.4->1.5->1.6)
> >> - Less clutter in the branch space (could be moot if we impose some sort
> >> of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
> >> minor/ACCUMULO-XXXX)
> >> - Quicker availability of fixes for consumers (after a fix, a new tag is
> >> made)
> >>
> >> Downsides:
> >> - Could create more work for us as we would be noting new minor
> releases.
> >> Does Christopher's release work mitigate some/most of this?
> >> - Creating git-tags without making an official release _might_ skirt a
> >> line on ASF releases. Some artifact that is intended for public
> consumption
> >> is meant to follow the release process.
> >>
> >>
> > It seems like you have a specific workflow in mind, but its not clear to
> me
> > exactly what you are thinking. Are you planning on elaborating on this
> > tonight? Is this workflow written up somewhere? If its not written up,
> a
> > few quick example scenarios would probably help me get on the same page.
> >
> >
> >> Personally, I'd consider making the bold assumption that, over time, we
> >> will create the infrastructure for ourselves to make better and better
> >> releases which will also mitigate this. I'm curious what everyone else
> >> thinks.
> >>
> >> I'll try to make time tonight to get info on all of the necessary below.
> >
> >
> >>
> >> On 6/1/13 4:28 PM, Christopher wrote:
> >>
> >>> Reviewing this thread, it seems everyone is pretty much in favor of
> >>> this. I propose we proceed by electing a "git transition advisor"...
> >>> someone who:
> >>>
> >>> 1) is sufficiently knowledgeable with git to identify roadblocks
> >>> during the transition and is willing to make it a point to propose and
> >>> follow through with solutions,
> >>> 2) can serve as the main point of contact with INFRA tickets related
> >>> to the transition,
> >>> 3) can advise other developers on best practices for things like when
> >>> to branch, where to put contribs, when to delete a branch (if ever),
> >>> etc. for things related to the shared repo.
> >>>
> >>> Item 3 is really something we can all do to the extent that our
> >>> expertise allows, but it'd be nice to have somebody willing to do item
> >>> 2, in the context of their experience in item 1.
> >>>
> >>> I would like to nominate Josh Elser, because I think he's qualified,
> >>> and because his exact response to this inquiry was "Yay, git."
> >>>
> >>> --
> >>> Christopher L Tubbs II
> >>> http://gravatar.com/ctubbsii
> >>>
> >>>
> >>> On Tue, May 21, 2013 at 5:44 PM, Christopher <ct...@apache.org>
> wrote:
> >>>
> >>>> I'm sure this has been entertained before, I'm starting to think that
> >>>> we should seriously consider switching to git, maybe sooner (during
> >>>> 1.6 development cycle?).
> >>>>
> >>>> --
> >>>> Christopher L Tubbs II
> >>>> http://gravatar.com/ctubbsii
> >>>>
> >>>
>
--
/*
Joe Stein
http://www.linkedin.com/in/charmalloc
Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop>
*/
Re: GIT
Posted by Christopher <ct...@apache.org>.
On Tue, Jun 4, 2013 at 4:15 PM, Josh Elser <jo...@gmail.com> wrote:
> On 6/4/13 2:34 PM, Christopher wrote:
>>
>> Personally, I'm fine with not having a super-long running release
>> branch, but I like them for a few reasons:
[snip]
> I just want to keep make note that this will affect things much more than
> previously in SVN as a merge is more than a guess at metadata.
>
> If you have long-lived branches, this necessitates that there are very many
> viable options in which a bug-fix can be applied (any branch at all). Not
> keeping these around will force the developer to think about where their fix
> is supposed to go (earliest, non-EOL'ed version).
[snip]
Good point.
>
>> I think branches should be hierarchical for subprojects and contribs,
>> as in: contrib/InstamoOrWhatever (unless there's a better way to
>> handle contribs...?)
>
>
> I believe we'll need to make separate repos for subprojects and contribs.
> This is one of the things I need to investigate how it's currently handled.
> New repos are certainly the easiest to manage.
I agree, of course, and that's the preferred option if INFRA permits
this. But this is a workable alternative if they don't.
[snip]
> Point being, I do not want to preclude developers from making tags unless
> it's an ASF release as I believe this gimps Git quite a bit. IMO, for tags,
> the line should be drawn between "internal" and "external". Tags advertised
> or intended for public use should (probably) be voted on, while
> internal-only intended (doesn't preclude someone from finding and
> downloading themselves) are encouraged.
>
Understandable, as long as the line is drawn.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
Re: GIT
Posted by Josh Elser <jo...@gmail.com>.
On 6/4/13 2:34 PM, Christopher wrote:
> Personally, I'm fine with not having a super-long running release
> branch, but I like them for a few reasons:
>
> 1. It doesn't force rapid releases that are time-consuming and require
> testing, but we still have that option if we want.
> 2. We can batch a few bugfixes and work on a bugfix release schedule
> for nice-to-have, but not urgent bugfixes (patch Tuesdays? :)
> 3. We're going to create this branch anyway, so we can stabilize
> things for testing prior to release... so why not leave it around for
> bugfixes?
> 4. Pretending we won't have bugfixes for a prior release is possibly
> delusional, and it seems like it doesn't really avoid anything
> regarding merging over multiple branches... when we patch, we'll just
> have to create these branches from their respective tags before we do
> this process. It doesn't seem to save us from this merging process.
>
> In short, I don't think leaving these branches around diverges from
> the proposed branching model... it just keeps them around until we
> decide that branch is EOL. If we leave a branch around until it
> reaches EOL, and we never make a bugfix in it, then no big deal, no
> harm done... just delete the branch at EOL.
I just want to keep make note that this will affect things much more
than previously in SVN as a merge is more than a guess at metadata.
If you have long-lived branches, this necessitates that there are very
many viable options in which a bug-fix can be applied (any branch at
all). Not keeping these around will force the developer to think about
where their fix is supposed to go (earliest, non-EOL'ed version).
Again, this is mostly a stylistic argument, and where I tend to disagree
with you. :)
> I think branches should be hierarchical for subprojects and contribs,
> as in: contrib/InstamoOrWhatever (unless there's a better way to
> handle contribs...?)
I believe we'll need to make separate repos for subprojects and
contribs. This is one of the things I need to investigate how it's
currently handled. New repos are certainly the easiest to manage.
> I think ticket/feature branches should be deleted after they've merged
> back to develop, and should also be hierarchical, as in:
> feature/ACCUMULO-9001
Works for me.
> As for tags, I'm not comfortable tagging anything we haven't voted on
> as an official release, and I think the time-consuming nature of that
> should be factored in, when considering these long-running bugfix
> branches for a release line.
I personally like being tag-heavy; however, there is a fine line here as
I already stated. There's no reason to not make a tag for something
you're working on in a feature branch that you want to share with
someone else (while you continue work on that feature). They can
checkout that tag which is assumed stable to an extent (the reason you
wanted someone else to pull it in the first place) and then make a
branch if they want to change something.
Point being, I do not want to preclude developers from making tags
unless it's an ASF release as I believe this gimps Git quite a bit. IMO,
for tags, the line should be drawn between "internal" and "external".
Tags advertised or intended for public use should (probably) be voted
on, while internal-only intended (doesn't preclude someone from finding
and downloading themselves) are encouraged.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, Jun 4, 2013 at 9:35 AM, Keith Turner <ke...@deenlo.com> wrote:
>> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser <jo...@gmail.com> wrote:
>>
>>> Yay, Git. Wait...
>>>
>>> I was going to wait to respond until I collected all of the info, but
>>> since I still haven't gotten that done yet, I figured I should just say
>>> "sure".
>>>
>>> The one thing I do want to get hammered out is the general workflow we
>>> plan to use. I believe that one "unstable" or "development" branch will
>>> satisfy most use cases as we typically don't have much active development
>>> against previous major releases.
>>>
>>> The thing I don't care for (putting it mildly) is long-running
>>> minor-release branches. I'm curious of suggestions that people might have
>>> for how to work around this. One
>>
>>
>> Why? What problems are you thinking of w/ long-running minor release
>> branches?
>>
>>
>>> possibility would be to be git-tag heavy while being more lax on official
>>> apache releases.
>>>
>>> Merits:
>>> - Less merging through 2-3 branches which a bug-fix might apply
>>> (1.4->1.5->1.6)
>>> - Less clutter in the branch space (could be moot if we impose some sort
>>> of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
>>> minor/ACCUMULO-XXXX)
>>> - Quicker availability of fixes for consumers (after a fix, a new tag is
>>> made)
>>>
>>> Downsides:
>>> - Could create more work for us as we would be noting new minor releases.
>>> Does Christopher's release work mitigate some/most of this?
>>> - Creating git-tags without making an official release _might_ skirt a
>>> line on ASF releases. Some artifact that is intended for public consumption
>>> is meant to follow the release process.
>>>
>>>
>> It seems like you have a specific workflow in mind, but its not clear to me
>> exactly what you are thinking. Are you planning on elaborating on this
>> tonight? Is this workflow written up somewhere? If its not written up, a
>> few quick example scenarios would probably help me get on the same page.
>>
>>
>>> Personally, I'd consider making the bold assumption that, over time, we
>>> will create the infrastructure for ourselves to make better and better
>>> releases which will also mitigate this. I'm curious what everyone else
>>> thinks.
>>>
>>> I'll try to make time tonight to get info on all of the necessary below.
>>
>>
>>>
>>> On 6/1/13 4:28 PM, Christopher wrote:
>>>
>>>> Reviewing this thread, it seems everyone is pretty much in favor of
>>>> this. I propose we proceed by electing a "git transition advisor"...
>>>> someone who:
>>>>
>>>> 1) is sufficiently knowledgeable with git to identify roadblocks
>>>> during the transition and is willing to make it a point to propose and
>>>> follow through with solutions,
>>>> 2) can serve as the main point of contact with INFRA tickets related
>>>> to the transition,
>>>> 3) can advise other developers on best practices for things like when
>>>> to branch, where to put contribs, when to delete a branch (if ever),
>>>> etc. for things related to the shared repo.
>>>>
>>>> Item 3 is really something we can all do to the extent that our
>>>> expertise allows, but it'd be nice to have somebody willing to do item
>>>> 2, in the context of their experience in item 1.
>>>>
>>>> I would like to nominate Josh Elser, because I think he's qualified,
>>>> and because his exact response to this inquiry was "Yay, git."
>>>>
>>>> --
>>>> Christopher L Tubbs II
>>>> http://gravatar.com/ctubbsii
>>>>
>>>>
>>>> On Tue, May 21, 2013 at 5:44 PM, Christopher <ct...@apache.org> wrote:
>>>>
>>>>> I'm sure this has been entertained before, I'm starting to think that
>>>>> we should seriously consider switching to git, maybe sooner (during
>>>>> 1.6 development cycle?).
>>>>>
>>>>> --
>>>>> Christopher L Tubbs II
>>>>> http://gravatar.com/ctubbsii
>>>>>
>>>>
Re: GIT
Posted by Christopher <ct...@apache.org>.
Personally, I'm fine with not having a super-long running release
branch, but I like them for a few reasons:
1. It doesn't force rapid releases that are time-consuming and require
testing, but we still have that option if we want.
2. We can batch a few bugfixes and work on a bugfix release schedule
for nice-to-have, but not urgent bugfixes (patch Tuesdays? :)
3. We're going to create this branch anyway, so we can stabilize
things for testing prior to release... so why not leave it around for
bugfixes?
4. Pretending we won't have bugfixes for a prior release is possibly
delusional, and it seems like it doesn't really avoid anything
regarding merging over multiple branches... when we patch, we'll just
have to create these branches from their respective tags before we do
this process. It doesn't seem to save us from this merging process.
In short, I don't think leaving these branches around diverges from
the proposed branching model... it just keeps them around until we
decide that branch is EOL. If we leave a branch around until it
reaches EOL, and we never make a bugfix in it, then no big deal, no
harm done... just delete the branch at EOL.
I think branches should be hierarchical for subprojects and contribs,
as in: contrib/InstamoOrWhatever (unless there's a better way to
handle contribs...?)
I think ticket/feature branches should be deleted after they've merged
back to develop, and should also be hierarchical, as in:
feature/ACCUMULO-9001
As for tags, I'm not comfortable tagging anything we haven't voted on
as an official release, and I think the time-consuming nature of that
should be factored in, when considering these long-running bugfix
branches for a release line.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Jun 4, 2013 at 9:35 AM, Keith Turner <ke...@deenlo.com> wrote:
> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser <jo...@gmail.com> wrote:
>
>> Yay, Git. Wait...
>>
>> I was going to wait to respond until I collected all of the info, but
>> since I still haven't gotten that done yet, I figured I should just say
>> "sure".
>>
>> The one thing I do want to get hammered out is the general workflow we
>> plan to use. I believe that one "unstable" or "development" branch will
>> satisfy most use cases as we typically don't have much active development
>> against previous major releases.
>>
>> The thing I don't care for (putting it mildly) is long-running
>> minor-release branches. I'm curious of suggestions that people might have
>> for how to work around this. One
>
>
> Why? What problems are you thinking of w/ long-running minor release
> branches?
>
>
>> possibility would be to be git-tag heavy while being more lax on official
>> apache releases.
>>
>> Merits:
>> - Less merging through 2-3 branches which a bug-fix might apply
>> (1.4->1.5->1.6)
>> - Less clutter in the branch space (could be moot if we impose some sort
>> of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
>> minor/ACCUMULO-XXXX)
>> - Quicker availability of fixes for consumers (after a fix, a new tag is
>> made)
>>
>> Downsides:
>> - Could create more work for us as we would be noting new minor releases.
>> Does Christopher's release work mitigate some/most of this?
>> - Creating git-tags without making an official release _might_ skirt a
>> line on ASF releases. Some artifact that is intended for public consumption
>> is meant to follow the release process.
>>
>>
> It seems like you have a specific workflow in mind, but its not clear to me
> exactly what you are thinking. Are you planning on elaborating on this
> tonight? Is this workflow written up somewhere? If its not written up, a
> few quick example scenarios would probably help me get on the same page.
>
>
>> Personally, I'd consider making the bold assumption that, over time, we
>> will create the infrastructure for ourselves to make better and better
>> releases which will also mitigate this. I'm curious what everyone else
>> thinks.
>>
>> I'll try to make time tonight to get info on all of the necessary below.
>
>
>>
>> On 6/1/13 4:28 PM, Christopher wrote:
>>
>>> Reviewing this thread, it seems everyone is pretty much in favor of
>>> this. I propose we proceed by electing a "git transition advisor"...
>>> someone who:
>>>
>>> 1) is sufficiently knowledgeable with git to identify roadblocks
>>> during the transition and is willing to make it a point to propose and
>>> follow through with solutions,
>>> 2) can serve as the main point of contact with INFRA tickets related
>>> to the transition,
>>> 3) can advise other developers on best practices for things like when
>>> to branch, where to put contribs, when to delete a branch (if ever),
>>> etc. for things related to the shared repo.
>>>
>>> Item 3 is really something we can all do to the extent that our
>>> expertise allows, but it'd be nice to have somebody willing to do item
>>> 2, in the context of their experience in item 1.
>>>
>>> I would like to nominate Josh Elser, because I think he's qualified,
>>> and because his exact response to this inquiry was "Yay, git."
>>>
>>> --
>>> Christopher L Tubbs II
>>> http://gravatar.com/ctubbsii
>>>
>>>
>>> On Tue, May 21, 2013 at 5:44 PM, Christopher <ct...@apache.org> wrote:
>>>
>>>> I'm sure this has been entertained before, I'm starting to think that
>>>> we should seriously consider switching to git, maybe sooner (during
>>>> 1.6 development cycle?).
>>>>
>>>> --
>>>> Christopher L Tubbs II
>>>> http://gravatar.com/ctubbsii
>>>>
>>>
Re: GIT
Posted by Keith Turner <ke...@deenlo.com>.
On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser <jo...@gmail.com> wrote:
> Yay, Git. Wait...
>
> I was going to wait to respond until I collected all of the info, but
> since I still haven't gotten that done yet, I figured I should just say
> "sure".
>
> The one thing I do want to get hammered out is the general workflow we
> plan to use. I believe that one "unstable" or "development" branch will
> satisfy most use cases as we typically don't have much active development
> against previous major releases.
>
> The thing I don't care for (putting it mildly) is long-running
> minor-release branches. I'm curious of suggestions that people might have
> for how to work around this. One
Why? What problems are you thinking of w/ long-running minor release
branches?
> possibility would be to be git-tag heavy while being more lax on official
> apache releases.
>
> Merits:
> - Less merging through 2-3 branches which a bug-fix might apply
> (1.4->1.5->1.6)
> - Less clutter in the branch space (could be moot if we impose some sort
> of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
> minor/ACCUMULO-XXXX)
> - Quicker availability of fixes for consumers (after a fix, a new tag is
> made)
>
> Downsides:
> - Could create more work for us as we would be noting new minor releases.
> Does Christopher's release work mitigate some/most of this?
> - Creating git-tags without making an official release _might_ skirt a
> line on ASF releases. Some artifact that is intended for public consumption
> is meant to follow the release process.
>
>
It seems like you have a specific workflow in mind, but its not clear to me
exactly what you are thinking. Are you planning on elaborating on this
tonight? Is this workflow written up somewhere? If its not written up, a
few quick example scenarios would probably help me get on the same page.
> Personally, I'd consider making the bold assumption that, over time, we
> will create the infrastructure for ourselves to make better and better
> releases which will also mitigate this. I'm curious what everyone else
> thinks.
>
> I'll try to make time tonight to get info on all of the necessary below.
>
> On 6/1/13 4:28 PM, Christopher wrote:
>
>> Reviewing this thread, it seems everyone is pretty much in favor of
>> this. I propose we proceed by electing a "git transition advisor"...
>> someone who:
>>
>> 1) is sufficiently knowledgeable with git to identify roadblocks
>> during the transition and is willing to make it a point to propose and
>> follow through with solutions,
>> 2) can serve as the main point of contact with INFRA tickets related
>> to the transition,
>> 3) can advise other developers on best practices for things like when
>> to branch, where to put contribs, when to delete a branch (if ever),
>> etc. for things related to the shared repo.
>>
>> Item 3 is really something we can all do to the extent that our
>> expertise allows, but it'd be nice to have somebody willing to do item
>> 2, in the context of their experience in item 1.
>>
>> I would like to nominate Josh Elser, because I think he's qualified,
>> and because his exact response to this inquiry was "Yay, git."
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Tue, May 21, 2013 at 5:44 PM, Christopher <ct...@apache.org> wrote:
>>
>>> I'm sure this has been entertained before, I'm starting to think that
>>> we should seriously consider switching to git, maybe sooner (during
>>> 1.6 development cycle?).
>>>
>>> --
>>> Christopher L Tubbs II
>>> http://gravatar.com/ctubbsii
>>>
>>
Re: GIT
Posted by Christopher <ct...@apache.org>.
That's my understanding as well. The main point being that "old
version" branches don't stick around long enough to get stale. After
all, it was created because there was a a bugfix somebody felt was
worth patching... it should be released at some point. In other words,
create the branch for a *purpose* (in this case, to fix and release
some bug fixes) or don't create it at all.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Jun 4, 2013 at 10:46 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Tue, Jun 4, 2013 at 10:26 PM, Benson Margulies <bi...@gmail.com>wrote:
>
>> > 1.4.4 has been released. The first person finds some changes that should
>> be
>> > placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would be
>> > created from the 1.4.4 tag.
>>
>> What's the advantage of 1.4.5-SNAPSHOT as opposed to a branch named
>> 1.4.x? On other projects, there's an assumption of one branch per
>> maintained minor version, with point releases as tags along they way.
>> How is your more complex? scheme advantageous?
>>
>
> I believe in this set up, in the absence of 1.4 non-compatible changes in
> flight there would not be a 1.5 related branch unti 1.4.5-SNAPSHOT had been
> tagged and removed.
>
> Thus, when a someone comes in provide a patch for some new bug, there are
> not multiple release branches. I don't see, for example:
>
> * 1.4.x
> * 1.5.x
> * master (1.6.x)
>
> This means that I don't have the opportunity to go "Oh, which of these do I
> put this on?" Instead I have to think:
>
> 1) What isn't end of life? (1.4+)
> 2) Does this break compatibility for that version?
> 2a) no? branch from last 1.4 tag
> 2b) check next most recent release and loop 2
>
> Also implied is that the normal workflow means that tagging e.g 1.4.5 would
> be followed by making a 1.5.1-SNAPSHOT to roll those same fixes up to the
> list of supported versions.
>
> In practice, if there are changes in flight non-compatible across multiple
> supported versions we'll end up with multiple -SNAPSHOT versions at once
> and it will look much like maintaining the 1.y.x branches. However, it will
> be clear that we're in such a state and it will also be clear when things
> collapse back.
>
> --
> Sean
Re: GIT
Posted by Sean Busbey <bu...@cloudera.com>.
On Tue, Jun 4, 2013 at 10:26 PM, Benson Margulies <bi...@gmail.com>wrote:
> > 1.4.4 has been released. The first person finds some changes that should
> be
> > placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would be
> > created from the 1.4.4 tag.
>
> What's the advantage of 1.4.5-SNAPSHOT as opposed to a branch named
> 1.4.x? On other projects, there's an assumption of one branch per
> maintained minor version, with point releases as tags along they way.
> How is your more complex? scheme advantageous?
>
I believe in this set up, in the absence of 1.4 non-compatible changes in
flight there would not be a 1.5 related branch unti 1.4.5-SNAPSHOT had been
tagged and removed.
Thus, when a someone comes in provide a patch for some new bug, there are
not multiple release branches. I don't see, for example:
* 1.4.x
* 1.5.x
* master (1.6.x)
This means that I don't have the opportunity to go "Oh, which of these do I
put this on?" Instead I have to think:
1) What isn't end of life? (1.4+)
2) Does this break compatibility for that version?
2a) no? branch from last 1.4 tag
2b) check next most recent release and loop 2
Also implied is that the normal workflow means that tagging e.g 1.4.5 would
be followed by making a 1.5.1-SNAPSHOT to roll those same fixes up to the
list of supported versions.
In practice, if there are changes in flight non-compatible across multiple
supported versions we'll end up with multiple -SNAPSHOT versions at once
and it will look much like maintaining the 1.y.x branches. However, it will
be clear that we're in such a state and it will also be clear when things
collapse back.
--
Sean
Re: GIT
Posted by Christopher <ct...@apache.org>.
That's fine. I don't really have a good understanding of the site
workflow. I know I commit code to our svn, then I update some local
working copy using the CMS tool, click stage, to stage my working copy
for preview, then I click publish to push my staged working copy to
yet another svn that shows itself on the website.
It seems to me that my CMS working copy could just as easily grab from
git in this workflow... or the CMS working copy could just grab from
the publication SVN instead of our project SVN... but perhaps that's
just not implemented. Either way, making changes to the website seems
obtuse and I don't like it. If it's not affected by a switch to git, I
will continue to not like it, but at least we can table that for this
thread. :)
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jun 5, 2013 at 12:48 PM, Billie Rinaldi
<bi...@gmail.com> wrote:
> As far as I can tell, the site will stay in SVN, and will be the only part
> of the SVN repo that remains writable after we switch to git. (It has to
> stay in SVN because it relies on svnpubsub.)
>
> Billie
>
>
> On Wed, Jun 5, 2013 at 9:29 AM, Christopher <ct...@apache.org> wrote:
>
>> Another thing to consider, since we mentioned contribs/subprojects, is
>> the site SCM. That's currently in SVN also.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Wed, Jun 5, 2013 at 12:23 PM, Josh Elser <jo...@gmail.com> wrote:
>> >
>> > On 6/5/13 10:51 AM, Keith Turner wrote:
>> >>>>
>> >>>> >>Can you give more detail about "history is easily mucked up"? I am
>> >>>> >>curious
>> >>>> >>what constitutes a mucked up history and what sequence of steps lead
>> >>>> >> to
>> >>>> >>this?
>> >>>> >>
>> >>>> >> http://dan.bravender.us/2011/**10/20/Why_cherry-picking_**
>> >>>
>> >>>
>> >>> > >should_not_be_part_of_a_**normal_git_workflow.html<
>> http://dan.bravender.us/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html
>> >
>> >>
>> >>
>> >>
>> >> Thanks for the link, I do not think I could have easily found this via
>> >> google because I would not have know what to search for. I have little
>> >> experience w/ git outside of small projects on github w/ one branch.
>> Info
>> >> like this helps me make informed decisions. Cherry picking vs merging
>> >> seems to be at the heart of what you are talking about, are there any
>> >> other
>> >> key concepts?
>> >>
>> > Cherry-pick and merging is definitely important. There are likely others,
>> > but none immediately come to mind.
>> >
>> >
>> >> Would probably be good to add this link, plus the other useful links
>> posed
>> >> in this thread, to the document you are working on. I can make that
>> >> change
>> >> if you put it somewhere.
>> >>
>> >>
>> > Yep, that's currently the plan. I'll throw it up in SVN tonight. (how
>> meta)
>>
Re: GIT
Posted by Billie Rinaldi <bi...@gmail.com>.
As far as I can tell, the site will stay in SVN, and will be the only part
of the SVN repo that remains writable after we switch to git. (It has to
stay in SVN because it relies on svnpubsub.)
Billie
On Wed, Jun 5, 2013 at 9:29 AM, Christopher <ct...@apache.org> wrote:
> Another thing to consider, since we mentioned contribs/subprojects, is
> the site SCM. That's currently in SVN also.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Wed, Jun 5, 2013 at 12:23 PM, Josh Elser <jo...@gmail.com> wrote:
> >
> > On 6/5/13 10:51 AM, Keith Turner wrote:
> >>>>
> >>>> >>Can you give more detail about "history is easily mucked up"? I am
> >>>> >>curious
> >>>> >>what constitutes a mucked up history and what sequence of steps lead
> >>>> >> to
> >>>> >>this?
> >>>> >>
> >>>> >> http://dan.bravender.us/2011/**10/20/Why_cherry-picking_**
> >>>
> >>>
> >>> > >should_not_be_part_of_a_**normal_git_workflow.html<
> http://dan.bravender.us/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html
> >
> >>
> >>
> >>
> >> Thanks for the link, I do not think I could have easily found this via
> >> google because I would not have know what to search for. I have little
> >> experience w/ git outside of small projects on github w/ one branch.
> Info
> >> like this helps me make informed decisions. Cherry picking vs merging
> >> seems to be at the heart of what you are talking about, are there any
> >> other
> >> key concepts?
> >>
> > Cherry-pick and merging is definitely important. There are likely others,
> > but none immediately come to mind.
> >
> >
> >> Would probably be good to add this link, plus the other useful links
> posed
> >> in this thread, to the document you are working on. I can make that
> >> change
> >> if you put it somewhere.
> >>
> >>
> > Yep, that's currently the plan. I'll throw it up in SVN tonight. (how
> meta)
>
Re: GIT
Posted by Christopher <ct...@apache.org>.
Another thing to consider, since we mentioned contribs/subprojects, is
the site SCM. That's currently in SVN also.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jun 5, 2013 at 12:23 PM, Josh Elser <jo...@gmail.com> wrote:
>
> On 6/5/13 10:51 AM, Keith Turner wrote:
>>>>
>>>> >>Can you give more detail about "history is easily mucked up"? I am
>>>> >>curious
>>>> >>what constitutes a mucked up history and what sequence of steps lead
>>>> >> to
>>>> >>this?
>>>> >>
>>>> >> http://dan.bravender.us/2011/**10/20/Why_cherry-picking_**
>>>
>>>
>>> > >should_not_be_part_of_a_**normal_git_workflow.html<http://dan.bravender.us/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html>
>>
>>
>>
>> Thanks for the link, I do not think I could have easily found this via
>> google because I would not have know what to search for. I have little
>> experience w/ git outside of small projects on github w/ one branch. Info
>> like this helps me make informed decisions. Cherry picking vs merging
>> seems to be at the heart of what you are talking about, are there any
>> other
>> key concepts?
>>
> Cherry-pick and merging is definitely important. There are likely others,
> but none immediately come to mind.
>
>
>> Would probably be good to add this link, plus the other useful links posed
>> in this thread, to the document you are working on. I can make that
>> change
>> if you put it somewhere.
>>
>>
> Yep, that's currently the plan. I'll throw it up in SVN tonight. (how meta)
Re: GIT
Posted by Josh Elser <jo...@gmail.com>.
On 6/5/13 10:51 AM, Keith Turner wrote:
>>> >>Can you give more detail about "history is easily mucked up"? I am
>>> >>curious
>>> >>what constitutes a mucked up history and what sequence of steps lead to
>>> >>this?
>>> >>
>>> >> http://dan.bravender.us/2011/**10/20/Why_cherry-picking_**
>> >should_not_be_part_of_a_**normal_git_workflow.html<http://dan.bravender.us/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html>
>
>
> Thanks for the link, I do not think I could have easily found this via
> google because I would not have know what to search for. I have little
> experience w/ git outside of small projects on github w/ one branch. Info
> like this helps me make informed decisions. Cherry picking vs merging
> seems to be at the heart of what you are talking about, are there any other
> key concepts?
>
Cherry-pick and merging is definitely important. There are likely
others, but none immediately come to mind.
> Would probably be good to add this link, plus the other useful links posed
> in this thread, to the document you are working on. I can make that change
> if you put it somewhere.
>
>
Yep, that's currently the plan. I'll throw it up in SVN tonight. (how meta)
Re: GIT
Posted by Keith Turner <ke...@deenlo.com>.
On Wed, Jun 5, 2013 at 9:16 AM, Josh Elser <jo...@gmail.com> wrote:
>
>
> On 6/5/13 8:44 AM, Keith Turner wrote:
>
>> On Tue, Jun 4, 2013 at 10:49 PM, Josh Elser <jo...@gmail.com> wrote:
>>
>>
>>> On 06/04/2013 10:26 PM, Benson Margulies wrote:
>>>
>>> 1.4.4 has been released. The first person finds some changes that should
>>>>
>>>>> be
>>>>> placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would be
>>>>> created from the 1.4.4 tag.
>>>>>
>>>>> What's the advantage of 1.4.5-SNAPSHOT as opposed to a branch named
>>>> 1.4.x? On other projects, there's an assumption of one branch per
>>>> maintained minor version, with point releases as tags along they way.
>>>> How is your more complex? scheme advantageous?
>>>>
>>>> Much of this discussion is entirely based on the fact that my opinions
>>> were solicited while the majority of people tended not to agree with how
>>> I
>>> would prefer to manage branches.
>>>
>>> As such, I've stopped arguing my points as, and will attempt to be
>>> detached. Having been part of transition a decent-sized "subversion"
>>> team
>>> to git, which typically tries to manage with 2+ concurrent releases, I've
>>> developed my own opinions on how to manage this. Most of it stems from
>>> lack
>>> of moderation on where changes should be made in such an environment and
>>> that history is easily mucked up and when changes are placed in
>>> inappropriate places. If it seems completely absurd to even have this
>>> discussion (I don't fault you in the slightest -- I'm 99% there myself),
>>> I'm actively working a write-up to track concrete decisions.
>>>
>>>
>> Can you give more detail about "history is easily mucked up"? I am
>> curious
>> what constitutes a mucked up history and what sequence of steps lead to
>> this?
>>
>> http://dan.bravender.us/2011/**10/20/Why_cherry-picking_**
> should_not_be_part_of_a_**normal_git_workflow.html<http://dan.bravender.us/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html>
Thanks for the link, I do not think I could have easily found this via
google because I would not have know what to search for. I have little
experience w/ git outside of small projects on github w/ one branch. Info
like this helps me make informed decisions. Cherry picking vs merging
seems to be at the heart of what you are talking about, are there any other
key concepts?
Would probably be good to add this link, plus the other useful links posed
in this thread, to the document you are working on. I can make that change
if you put it somewhere.
>
>
>>
>>> As far as a minor-release branch name, I really just don't care. It's a
>>> name. My opinion is to tie it to something specific and meaningful. I do
>>> not find 1.4.x nomenclature meaningful, so, as such, I proposed
>>> alternatives.
>>>
>>> Ultimately, I hope that those currently performing the most development
>>> should form their own opinion from the facts that have been presented
>>> when
>>> it comes time for a decision to be made.
>>>
>>>
>>
Re: GIT
Posted by Josh Elser <jo...@gmail.com>.
On 6/5/13 8:44 AM, Keith Turner wrote:
> On Tue, Jun 4, 2013 at 10:49 PM, Josh Elser <jo...@gmail.com> wrote:
>
>>
>> On 06/04/2013 10:26 PM, Benson Margulies wrote:
>>
>>> 1.4.4 has been released. The first person finds some changes that should
>>>> be
>>>> placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would be
>>>> created from the 1.4.4 tag.
>>>>
>>> What's the advantage of 1.4.5-SNAPSHOT as opposed to a branch named
>>> 1.4.x? On other projects, there's an assumption of one branch per
>>> maintained minor version, with point releases as tags along they way.
>>> How is your more complex? scheme advantageous?
>>>
>> Much of this discussion is entirely based on the fact that my opinions
>> were solicited while the majority of people tended not to agree with how I
>> would prefer to manage branches.
>>
>> As such, I've stopped arguing my points as, and will attempt to be
>> detached. Having been part of transition a decent-sized "subversion" team
>> to git, which typically tries to manage with 2+ concurrent releases, I've
>> developed my own opinions on how to manage this. Most of it stems from lack
>> of moderation on where changes should be made in such an environment and
>> that history is easily mucked up and when changes are placed in
>> inappropriate places. If it seems completely absurd to even have this
>> discussion (I don't fault you in the slightest -- I'm 99% there myself),
>> I'm actively working a write-up to track concrete decisions.
>>
>
> Can you give more detail about "history is easily mucked up"? I am curious
> what constitutes a mucked up history and what sequence of steps lead to
> this?
>
http://dan.bravender.us/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html
>
>>
>> As far as a minor-release branch name, I really just don't care. It's a
>> name. My opinion is to tie it to something specific and meaningful. I do
>> not find 1.4.x nomenclature meaningful, so, as such, I proposed
>> alternatives.
>>
>> Ultimately, I hope that those currently performing the most development
>> should form their own opinion from the facts that have been presented when
>> it comes time for a decision to be made.
>>
>
Re: GIT
Posted by Keith Turner <ke...@deenlo.com>.
On Tue, Jun 4, 2013 at 10:49 PM, Josh Elser <jo...@gmail.com> wrote:
>
> On 06/04/2013 10:26 PM, Benson Margulies wrote:
>
>> 1.4.4 has been released. The first person finds some changes that should
>>> be
>>> placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would be
>>> created from the 1.4.4 tag.
>>>
>> What's the advantage of 1.4.5-SNAPSHOT as opposed to a branch named
>> 1.4.x? On other projects, there's an assumption of one branch per
>> maintained minor version, with point releases as tags along they way.
>> How is your more complex? scheme advantageous?
>>
> Much of this discussion is entirely based on the fact that my opinions
> were solicited while the majority of people tended not to agree with how I
> would prefer to manage branches.
>
> As such, I've stopped arguing my points as, and will attempt to be
> detached. Having been part of transition a decent-sized "subversion" team
> to git, which typically tries to manage with 2+ concurrent releases, I've
> developed my own opinions on how to manage this. Most of it stems from lack
> of moderation on where changes should be made in such an environment and
> that history is easily mucked up and when changes are placed in
> inappropriate places. If it seems completely absurd to even have this
> discussion (I don't fault you in the slightest -- I'm 99% there myself),
> I'm actively working a write-up to track concrete decisions.
>
Can you give more detail about "history is easily mucked up"? I am curious
what constitutes a mucked up history and what sequence of steps lead to
this?
>
> As far as a minor-release branch name, I really just don't care. It's a
> name. My opinion is to tie it to something specific and meaningful. I do
> not find 1.4.x nomenclature meaningful, so, as such, I proposed
> alternatives.
>
> Ultimately, I hope that those currently performing the most development
> should form their own opinion from the facts that have been presented when
> it comes time for a decision to be made.
>
Re: GIT
Posted by Josh Elser <jo...@gmail.com>.
On 06/04/2013 10:26 PM, Benson Margulies wrote:
>> 1.4.4 has been released. The first person finds some changes that should be
>> placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would be
>> created from the 1.4.4 tag.
> What's the advantage of 1.4.5-SNAPSHOT as opposed to a branch named
> 1.4.x? On other projects, there's an assumption of one branch per
> maintained minor version, with point releases as tags along they way.
> How is your more complex? scheme advantageous?
Much of this discussion is entirely based on the fact that my opinions
were solicited while the majority of people tended not to agree with how
I would prefer to manage branches.
As such, I've stopped arguing my points as, and will attempt to be
detached. Having been part of transition a decent-sized "subversion"
team to git, which typically tries to manage with 2+ concurrent
releases, I've developed my own opinions on how to manage this. Most of
it stems from lack of moderation on where changes should be made in such
an environment and that history is easily mucked up and when changes are
placed in inappropriate places. If it seems completely absurd to even
have this discussion (I don't fault you in the slightest -- I'm 99%
there myself), I'm actively working a write-up to track concrete decisions.
As far as a minor-release branch name, I really just don't care. It's a
name. My opinion is to tie it to something specific and meaningful. I do
not find 1.4.x nomenclature meaningful, so, as such, I proposed
alternatives.
Ultimately, I hope that those currently performing the most development
should form their own opinion from the facts that have been presented
when it comes time for a decision to be made.
Re: GIT
Posted by Benson Margulies <bi...@gmail.com>.
> 1.4.4 has been released. The first person finds some changes that should be
> placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would be
> created from the 1.4.4 tag.
What's the advantage of 1.4.5-SNAPSHOT as opposed to a branch named
1.4.x? On other projects, there's an assumption of one branch per
maintained minor version, with point releases as tags along they way.
How is your more complex? scheme advantageous?
Re: GIT
Posted by Josh Elser <jo...@gmail.com>.
tl;dr yes and yes
In an effort to continue productive conversation, let's go off of what
Keith was saying about making a branch suffixed with -SNAPSHOT to denote
the provenance of the changes and lifecycle of said branch.
Let's take the 1.4 series as an example:
1.4.4 has been released. The first person finds some changes that should
be placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would
be created from the 1.4.4 tag.
`git checkout 1.4.4 && git checkout -b 1.4.5-SNAPSHOT; hack; commit; git
push origin 1.4.5-SNAPSHOT`
After which, 1.4.5-SNAPSHOT would contain a certain number of bug-fixes
until it is deemed appropriate to release 1.4.4.
At which point, we would tag off of the 1.4.5-SNAPSHOT branch, merge the
tag into the 1.5 series and through to the 1.6 series and delete the
remote-tracking 1.4.5-SNAPSHOT branch as it now contains no additional
information not contained by the 1.4.5 tag.
On 06/04/2013 10:05 PM, Drew Farris wrote:
> On Tuesday, June 4, 2013, Josh Elser wrote:
>>
>> The thing I don't care for (putting it mildly) is long-running
>> minor-release branches. I'm curious of suggestions that people might have
>> for how to work around this. One possibility would be to be git-tag heavy
>> while being more lax on official apache releases.
>>
> I think I understand, but I am curious: At what point would we trash the
> minor release branch? For example, would we have trashed 1.4 by now? When
> would we trash the 1.5 branch?
>
> Also, do we tag from the short-lived branch 1.4.5-SNAPSHOT? When we delete
> the branch, will the tag preserve the history of what happened on that
> branch? E.g all of the commits that took us from 1.4.4 to 1.4.5?
>
Re: GIT
Posted by Benson Margulies <bi...@gmail.com>.
I'm not following this discussion, I confess. Regardless of whether it
is svn or git, if you want to support old releases, you end up with
'old release branches' upon which you maintain them and make point
releases.
Given Apache preferences for 'development in public', I'd sort of
expect a position like:
1. There's a master branch, aiming at the next major.
2. There's a long-lived branch for each older release that is actively
maintained.
3. There's a tag for each release.
After that, there are short-lived branches for tasks, shared projects.
If people prefer the release-from-a-branch model (as opposed to the
'release from the main line'), then I'm not sure what the right
lifetime is of those branches. A branch in git is just a name attached
to a commit, it's not a line. The 'line' is defined only by the fact
that commits have parents. So, so long as there's a tag on a commit,
no history is ever garbage collected that reaches that tag.
Re: GIT
Posted by Drew Farris <dr...@apache.org>.
On Tuesday, June 4, 2013, Josh Elser wrote:
>
>
> The thing I don't care for (putting it mildly) is long-running
> minor-release branches. I'm curious of suggestions that people might have
> for how to work around this. One possibility would be to be git-tag heavy
> while being more lax on official apache releases.
>
I think I understand, but I am curious: At what point would we trash the
minor release branch? For example, would we have trashed 1.4 by now? When
would we trash the 1.5 branch?
Also, do we tag from the short-lived branch 1.4.5-SNAPSHOT? When we delete
the branch, will the tag preserve the history of what happened on that
branch? E.g all of the commits that took us from 1.4.4 to 1.4.5?
Re: GIT
Posted by Aaron G <aa...@gmail.com>.
Sorry about that, didn't catch that I'm the thread.
On Jun 4, 2013, at 10:04 AM, Josh Elser <jo...@gmail.com> wrote:
> Aaron, yeah, I presented that as an option (or at least a good read). The premise is good, although I don't think we would want to implement that 100% as it just doesn't jive with how we do releases.
>
> Thanks for re-copying that, though. I'd encourage anyone who wants to discuss workflow to take a moment and read that page and consider it from a high-level.
>
> On 6/4/13 9:41 AM, Aaron G wrote:
>> You may want to look at:
>>
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> as a branching strategy.
>>
>> Sent from my iPhone
>>
>> On Jun 4, 2013, at 9:07 AM, Josh Elser <jo...@gmail.com> wrote:
>>
>>> Yay, Git. Wait...
>>>
>>> I was going to wait to respond until I collected all of the info, but since I still haven't gotten that done yet, I figured I should just say "sure".
>>>
>>> The one thing I do want to get hammered out is the general workflow we plan to use. I believe that one "unstable" or "development" branch will satisfy most use cases as we typically don't have much active development against previous major releases.
>>>
>>> The thing I don't care for (putting it mildly) is long-running minor-release branches. I'm curious of suggestions that people might have for how to work around this. One possibility would be to be git-tag heavy while being more lax on official apache releases.
>>>
>>> Merits:
>>> - Less merging through 2-3 branches which a bug-fix might apply (1.4->1.5->1.6)
>>> - Less clutter in the branch space (could be moot if we impose some sort of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX, minor/ACCUMULO-XXXX)
>>> - Quicker availability of fixes for consumers (after a fix, a new tag is made)
>>>
>>> Downsides:
>>> - Could create more work for us as we would be noting new minor releases. Does Christopher's release work mitigate some/most of this?
>>> - Creating git-tags without making an official release _might_ skirt a line on ASF releases. Some artifact that is intended for public consumption is meant to follow the release process.
>>>
>>> Personally, I'd consider making the bold assumption that, over time, we will create the infrastructure for ourselves to make better and better releases which will also mitigate this. I'm curious what everyone else thinks.
>>>
>>> I'll try to make time tonight to get info on all of the necessary below.
>>>
>>> On 6/1/13 4:28 PM, Christopher wrote:
>>>> Reviewing this thread, it seems everyone is pretty much in favor of
>>>> this. I propose we proceed by electing a "git transition advisor"...
>>>> someone who:
>>>>
>>>> 1) is sufficiently knowledgeable with git to identify roadblocks
>>>> during the transition and is willing to make it a point to propose and
>>>> follow through with solutions,
>>>> 2) can serve as the main point of contact with INFRA tickets related
>>>> to the transition,
>>>> 3) can advise other developers on best practices for things like when
>>>> to branch, where to put contribs, when to delete a branch (if ever),
>>>> etc. for things related to the shared repo.
>>>>
>>>> Item 3 is really something we can all do to the extent that our
>>>> expertise allows, but it'd be nice to have somebody willing to do item
>>>> 2, in the context of their experience in item 1.
>>>>
>>>> I would like to nominate Josh Elser, because I think he's qualified,
>>>> and because his exact response to this inquiry was "Yay, git."
>>>>
>>>> --
>>>> Christopher L Tubbs II
>>>> http://gravatar.com/ctubbsii
>>>>
>>>>
>>>> On Tue, May 21, 2013 at 5:44 PM, Christopher <ct...@apache.org> wrote:
>>>>> I'm sure this has been entertained before, I'm starting to think that
>>>>> we should seriously consider switching to git, maybe sooner (during
>>>>> 1.6 development cycle?).
>>>>>
>>>>> --
>>>>> Christopher L Tubbs II
>>>>> http://gravatar.com/ctubbsii
>>
Re: GIT
Posted by Josh Elser <jo...@gmail.com>.
Aaron, yeah, I presented that as an option (or at least a good read).
The premise is good, although I don't think we would want to implement
that 100% as it just doesn't jive with how we do releases.
Thanks for re-copying that, though. I'd encourage anyone who wants to
discuss workflow to take a moment and read that page and consider it
from a high-level.
On 6/4/13 9:41 AM, Aaron G wrote:
> You may want to look at:
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> as a branching strategy.
>
> Sent from my iPhone
>
> On Jun 4, 2013, at 9:07 AM, Josh Elser <jo...@gmail.com> wrote:
>
>> Yay, Git. Wait...
>>
>> I was going to wait to respond until I collected all of the info, but since I still haven't gotten that done yet, I figured I should just say "sure".
>>
>> The one thing I do want to get hammered out is the general workflow we plan to use. I believe that one "unstable" or "development" branch will satisfy most use cases as we typically don't have much active development against previous major releases.
>>
>> The thing I don't care for (putting it mildly) is long-running minor-release branches. I'm curious of suggestions that people might have for how to work around this. One possibility would be to be git-tag heavy while being more lax on official apache releases.
>>
>> Merits:
>> - Less merging through 2-3 branches which a bug-fix might apply (1.4->1.5->1.6)
>> - Less clutter in the branch space (could be moot if we impose some sort of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX, minor/ACCUMULO-XXXX)
>> - Quicker availability of fixes for consumers (after a fix, a new tag is made)
>>
>> Downsides:
>> - Could create more work for us as we would be noting new minor releases. Does Christopher's release work mitigate some/most of this?
>> - Creating git-tags without making an official release _might_ skirt a line on ASF releases. Some artifact that is intended for public consumption is meant to follow the release process.
>>
>> Personally, I'd consider making the bold assumption that, over time, we will create the infrastructure for ourselves to make better and better releases which will also mitigate this. I'm curious what everyone else thinks.
>>
>> I'll try to make time tonight to get info on all of the necessary below.
>>
>> On 6/1/13 4:28 PM, Christopher wrote:
>>> Reviewing this thread, it seems everyone is pretty much in favor of
>>> this. I propose we proceed by electing a "git transition advisor"...
>>> someone who:
>>>
>>> 1) is sufficiently knowledgeable with git to identify roadblocks
>>> during the transition and is willing to make it a point to propose and
>>> follow through with solutions,
>>> 2) can serve as the main point of contact with INFRA tickets related
>>> to the transition,
>>> 3) can advise other developers on best practices for things like when
>>> to branch, where to put contribs, when to delete a branch (if ever),
>>> etc. for things related to the shared repo.
>>>
>>> Item 3 is really something we can all do to the extent that our
>>> expertise allows, but it'd be nice to have somebody willing to do item
>>> 2, in the context of their experience in item 1.
>>>
>>> I would like to nominate Josh Elser, because I think he's qualified,
>>> and because his exact response to this inquiry was "Yay, git."
>>>
>>> --
>>> Christopher L Tubbs II
>>> http://gravatar.com/ctubbsii
>>>
>>>
>>> On Tue, May 21, 2013 at 5:44 PM, Christopher <ct...@apache.org> wrote:
>>>> I'm sure this has been entertained before, I'm starting to think that
>>>> we should seriously consider switching to git, maybe sooner (during
>>>> 1.6 development cycle?).
>>>>
>>>> --
>>>> Christopher L Tubbs II
>>>> http://gravatar.com/ctubbsii
>
Re: GIT
Posted by Aaron G <aa...@gmail.com>.
You may want to look at:
http://nvie.com/posts/a-successful-git-branching-model/
as a branching strategy.
Sent from my iPhone
On Jun 4, 2013, at 9:07 AM, Josh Elser <jo...@gmail.com> wrote:
> Yay, Git. Wait...
>
> I was going to wait to respond until I collected all of the info, but since I still haven't gotten that done yet, I figured I should just say "sure".
>
> The one thing I do want to get hammered out is the general workflow we plan to use. I believe that one "unstable" or "development" branch will satisfy most use cases as we typically don't have much active development against previous major releases.
>
> The thing I don't care for (putting it mildly) is long-running minor-release branches. I'm curious of suggestions that people might have for how to work around this. One possibility would be to be git-tag heavy while being more lax on official apache releases.
>
> Merits:
> - Less merging through 2-3 branches which a bug-fix might apply (1.4->1.5->1.6)
> - Less clutter in the branch space (could be moot if we impose some sort of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX, minor/ACCUMULO-XXXX)
> - Quicker availability of fixes for consumers (after a fix, a new tag is made)
>
> Downsides:
> - Could create more work for us as we would be noting new minor releases. Does Christopher's release work mitigate some/most of this?
> - Creating git-tags without making an official release _might_ skirt a line on ASF releases. Some artifact that is intended for public consumption is meant to follow the release process.
>
> Personally, I'd consider making the bold assumption that, over time, we will create the infrastructure for ourselves to make better and better releases which will also mitigate this. I'm curious what everyone else thinks.
>
> I'll try to make time tonight to get info on all of the necessary below.
>
> On 6/1/13 4:28 PM, Christopher wrote:
>> Reviewing this thread, it seems everyone is pretty much in favor of
>> this. I propose we proceed by electing a "git transition advisor"...
>> someone who:
>>
>> 1) is sufficiently knowledgeable with git to identify roadblocks
>> during the transition and is willing to make it a point to propose and
>> follow through with solutions,
>> 2) can serve as the main point of contact with INFRA tickets related
>> to the transition,
>> 3) can advise other developers on best practices for things like when
>> to branch, where to put contribs, when to delete a branch (if ever),
>> etc. for things related to the shared repo.
>>
>> Item 3 is really something we can all do to the extent that our
>> expertise allows, but it'd be nice to have somebody willing to do item
>> 2, in the context of their experience in item 1.
>>
>> I would like to nominate Josh Elser, because I think he's qualified,
>> and because his exact response to this inquiry was "Yay, git."
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Tue, May 21, 2013 at 5:44 PM, Christopher <ct...@apache.org> wrote:
>>> I'm sure this has been entertained before, I'm starting to think that
>>> we should seriously consider switching to git, maybe sooner (during
>>> 1.6 development cycle?).
>>>
>>> --
>>> Christopher L Tubbs II
>>> http://gravatar.com/ctubbsii
Re: GIT
Posted by Josh Elser <jo...@gmail.com>.
Yay, Git. Wait...
I was going to wait to respond until I collected all of the info, but
since I still haven't gotten that done yet, I figured I should just say
"sure".
The one thing I do want to get hammered out is the general workflow we
plan to use. I believe that one "unstable" or "development" branch will
satisfy most use cases as we typically don't have much active
development against previous major releases.
The thing I don't care for (putting it mildly) is long-running
minor-release branches. I'm curious of suggestions that people might
have for how to work around this. One possibility would be to be git-tag
heavy while being more lax on official apache releases.
Merits:
- Less merging through 2-3 branches which a bug-fix might apply
(1.4->1.5->1.6)
- Less clutter in the branch space (could be moot if we impose some sort
of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
minor/ACCUMULO-XXXX)
- Quicker availability of fixes for consumers (after a fix, a new tag is
made)
Downsides:
- Could create more work for us as we would be noting new minor
releases. Does Christopher's release work mitigate some/most of this?
- Creating git-tags without making an official release _might_ skirt a
line on ASF releases. Some artifact that is intended for public
consumption is meant to follow the release process.
Personally, I'd consider making the bold assumption that, over time, we
will create the infrastructure for ourselves to make better and better
releases which will also mitigate this. I'm curious what everyone else
thinks.
I'll try to make time tonight to get info on all of the necessary below.
On 6/1/13 4:28 PM, Christopher wrote:
> Reviewing this thread, it seems everyone is pretty much in favor of
> this. I propose we proceed by electing a "git transition advisor"...
> someone who:
>
> 1) is sufficiently knowledgeable with git to identify roadblocks
> during the transition and is willing to make it a point to propose and
> follow through with solutions,
> 2) can serve as the main point of contact with INFRA tickets related
> to the transition,
> 3) can advise other developers on best practices for things like when
> to branch, where to put contribs, when to delete a branch (if ever),
> etc. for things related to the shared repo.
>
> Item 3 is really something we can all do to the extent that our
> expertise allows, but it'd be nice to have somebody willing to do item
> 2, in the context of their experience in item 1.
>
> I would like to nominate Josh Elser, because I think he's qualified,
> and because his exact response to this inquiry was "Yay, git."
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, May 21, 2013 at 5:44 PM, Christopher <ct...@apache.org> wrote:
>> I'm sure this has been entertained before, I'm starting to think that
>> we should seriously consider switching to git, maybe sooner (during
>> 1.6 development cycle?).
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
Re: GIT
Posted by Jason Trost <ja...@gmail.com>.
+1 for Josh
Re: GIT
Posted by Josh Elser <jo...@gmail.com>.
For record keeping purposes:
5 Binding +1 (plus implicit +1 from Christopher who started the
discussion in the first place)
1 Non-binding +1
No +0, no -1.
On 06/01/2013 04:28 PM, Christopher wrote:
> Reviewing this thread, it seems everyone is pretty much in favor of
> this. I propose we proceed by electing a "git transition advisor"...
> someone who:
>
> 1) is sufficiently knowledgeable with git to identify roadblocks
> during the transition and is willing to make it a point to propose and
> follow through with solutions,
> 2) can serve as the main point of contact with INFRA tickets related
> to the transition,
> 3) can advise other developers on best practices for things like when
> to branch, where to put contribs, when to delete a branch (if ever),
> etc. for things related to the shared repo.
>
> Item 3 is really something we can all do to the extent that our
> expertise allows, but it'd be nice to have somebody willing to do item
> 2, in the context of their experience in item 1.
>
> I would like to nominate Josh Elser, because I think he's qualified,
> and because his exact response to this inquiry was "Yay, git."
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, May 21, 2013 at 5:44 PM, Christopher <ct...@apache.org> wrote:
>> I'm sure this has been entertained before, I'm starting to think that
>> we should seriously consider switching to git, maybe sooner (during
>> 1.6 development cycle?).
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii