accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Farris <drew.far...@gmail.com>
Subject Re: [VOTE] end of life plan for 1.4 branch
Date Tue, 06 May 2014 13:21:18 GMT
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