accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Medinets <david.medin...@gmail.com>
Subject Re: GIT
Date Tue, 04 Jun 2013 22:27:10 GMT
+1 for <apacheID>/<jira ticket> - I'm ambivalent about the rest.


On Tue, Jun 4, 2013 at 6:11 PM, Christopher <ctubbsii@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 <ctubbsii@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 <keith@deenlo.com> wrote:
> >> On Tue, Jun 4, 2013 at 10:01 AM, Josh Elser <josh.elser@gmail.com>
> wrote:
> >>
> >>> On 6/4/13 9:35 AM, Keith Turner wrote:
> >>>
> >>>> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser<josh.elser@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.
> >>>>>
> >>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message