accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [VOTE] end of life plan for 1.4 branch
Date Tue, 06 May 2014 16:12:34 GMT
replies inline


On Tue, May 6, 2014 at 8: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.
>
>
>

Yes, I'd say your workflow is just at odds with our branch-and-merge
strategy. The work is no different then what you'd have to do when we cut a
release and the branch changed from 1.4.5-SNAPSHOT to 1.4.6-SNAPSHOT.

Hopefully with the compatibility focus changes in 2.0.0, you'll be seeing
more obviously short lived minor version branches that reappear briefly for
bugfix and this will be more obvious.



> > 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?
>
>

Tickets that only impact archived versions remain in Jira, e.g.
ACCUMULO-661 that only impacts the 1.3 line[1] and they are still
searchable in major search engines[2].

Because Jira stops accepting archived versions in autocomplete fields, you
can't use the simple search to find all tickets that impact a particular
archived version, but you can use advanced search[3]. Once you have
completed an advanced search, you can actually switch back to basic and
things will work (though it will warn you that your version choice is
invalid).

[1]: https://issues.apache.org/jira/browse/ACCUMULO-661
[2]: https://www.google.com/#q=accumulo+typo+manual+iterators
[3]:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20ACCUMULO%20AND%20affectedVersion%3D%221.3.5%22

-- 
Sean

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