accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [VOTE] end of life plan for 1.4 branch
Date Tue, 06 May 2014 18:42:42 GMT
Changing vote to +1  w/ caveat that we drop .6 from tag name.  ok w/ any of
the alternate tag names that have been proposed


On Tue, May 6, 2014 at 12:22 PM, Joey Echeverria
<joey+ml@clouderagovt.com>wrote:

> [X ] +1 I am in favor of announcing End of Life according to the above
> plan with any of the following for the tag name:
>
> 1.4-eol
> 1.4-closed
> 1.4-orphaned
> 1.4-closeout
> 1.4-abandoned
> 1.4-unreleased
>
> -Joey
>
> On Tue, May 6, 2014 at 9:21 AM, Drew Farris <drew.farris@gmail.com> wrote:
> > On Tue, May 6, 2014 at 8:53 AM, Christopher <ctubbsii@apache.org> wrote:
> >
> >> I don't see how that affects removing of the branch for active
> >> development. If an issue
> >> warrants it, that branch can always be reopened. Removing it indicates
> >> that it's not expected to be reopened, and that we've agreed to focus
> >> on new versions.
> >>
> >
> > I don't like removing branches because forces those folks who are
> > maintaining their own 1.4 branches to figure out how to fix things
> locally
> > when the remote branch they're tracking goes away. Is it sufficient to
> tell
> > folks to do the following to address this?
> >
> > git rebase --onto 1.4.6-SNAPSHOT-eol 1.4.6-SNAPSHOT 1.4.6-SNAPSHOT-local
> >
> > What happens if the branch is deleted and then is reopened at a later
> time?
> > Are there further machinations that a developer maintaining a 1.4.x
> branch
> > much go through to get back on track?
> >
> > Perhaps this is just the way with git, and I'm trapped in the mindset of
> > long-running branches that run parallel to major revision development and
> > aren't targeted at a specific point release. In looking at this I'm
> > reminded that the Accumulo community has chosen the latter path where
> > branches are short-lived and targeted at the next release.
> >
> >
> >> I'm not sure if that means we should archive the 1.4.x
> >> versions in JIRA, so people can mark those versions as affected or
> >> not. Maybe it'd just be useful to just archive 1.4.0-1.4.3, and leave
> >> 1.4.4/1.4.5 unarchived. (I suggest the last two versions of 1.4, only
> >> because the last version introduced a lot of changes that people may
> >> be reluctant to update to, if they aren't transitioning to hadoop 2).
> >>
> >
> > I see JIRA being useful as both a work tracking/planning tool >and< a
> user
> > support tool / record of project history (like commit history). Would
> > archiving releases prevent historic issues from being findable via
> google?
> >
> > --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
> >>
> >> On Tue, May 6, 2014 at 8:34 AM, Drew Farris <drew.farris@gmail.com>
> wrote:
> >> > Thanks for the response Joey.
> >> >
> >> > It sounds as if there's agreement on a number of points and it sounds
> >> like
> >> > I'm the only person not in favor of deleting the branch and creating a
> >> tag
> >> > a this point. Also, bug management is an interesting issue. Thoughts
> >> > in-line below:
> >> >
> >> > On Mon, May 5, 2014 at 4:07 PM, Joey Echeverria <
> >> joey+ml@clouderagovt.com>wrote:
> >> >
> >> >>
> >> >> There is also the impact on ticket workflow. When a version is EOLed,
> >> >> I'd not expect the community to provide any additional fixes for that
> >> >> release line. If 1.4 hangs around, then it creates confusion over
> what
> >> >> will happen to tickets filed against it. It also will confuse users
> as
> >> >> they may keep filing 1.4 tickets.
> >> >>
> >> >
> >> > If people find ticket-worthy issues in 1.4 after it's end-of-lifed
> >> wouldn't
> >> > we expect them to file a ticket against that version? Shouldn't these
> >> > tickets reflect known issues with a release of software that people
> use?
> >> > Regardless of the desire of the development community to produce new
> >> > releases of a specific branch, it is a service to the community of
> users
> >> to
> >> > be able to record known issues (even if these will ultimately result
> in a
> >> > wontfix resolution). Google does a very good job indexing the Apache
> >> JIRA.
> >> >
> >> > Furthermore, issue reporting activity is a reflection of real-world
> use
> >> > which should naturally migrate to future versions, and if people
> aren't
> >> > migrating to future versions, we have bigger fish to fry.
> >> >
> >> >  > To something else, perhaps:
> >> >> >
> >> >> > Current Stable Release: 1.5.1
> >> >> > Legacy Bugfix Release: 1.4.5
> >> >>
> >> >> We used to have something like this, but that lead to some arguments
> >> >> over which is stable and which legacy. For example, 1.6.0 is out now
> >> >> so that means that there would be three releases we need to identify.
> >> >>
> >> >
> >> > Ok, so, we list three releases instead of two. Two of them happen to
> be
> >> > considered stable. If there's confusion in the user community, we
> likely
> >> > need to do a better job explaining which one to use a la tomcat [1]
> >> >
> >> > Current Stable Releases: 1.5.1, 1.6.0
> >> > Legacy Bugfix Release: 1.4.5
> >> >
> >> >> Could someone explain why we would want to ever delete the 1.4.x
> branch?
> >> >
> >> > I think you want to delete the branch because of our Git workflow[1]
> >> >> which is to always target a patch for the earliest, non-end-of-lifed
> >> >> version. You could argue that the documentation and mailing list
> >> >> announcement are sufficient to declare the branch EOLed, but I don't
> >> >> think that's strong enough for a casual contributor.
> >> >>
> >> >
> >> > Who are we trying to protect here? and what are we trying to protect
> them
> >> > from? If casual contributors can't keep up with the current state of
> the
> >> > code and repository via the mailing list or website, I'd worry either
> >> about
> >> > the quality of their contributions or the quality of the documentation
> >> the
> >> > community is producing in terms of the current state of the project.
> If
> >> > folks that would commit to the project aren't aware of where merges
> >> should
> >> > be made I'd worry that they shouldn't be committing to the project in
> the
> >> > first place without guidance from the community.
> >> >
> >> > So, to summarize:
> >> >
> >> > I agree it's time to end of life 1.4 in that I'm in favor of stating
> >> > clearly that users should not expect new releases of 1.4.x and new
> >> projects
> >> > and migrations should use some other version (preferably 1.6.0)
> >> >
> >> > I'm against stating that a new release of 1.4 will >never< be made
or
> >> must
> >> >>never< be made - and as a result against deleting the 1.4.x
> development
> >> > branch in favor of a tag.
> >> >
> >> > I'm also not in favor of preventing people from documenting the issues
> >> they
> >> > find with 1.4 as tickets in jira.
> >> >
> >> > Drew
> >> >
> >> > [1] http://tomcat.apache.org/whichversion.html
> >>
>

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