replies inline
On Tue, May 6, 2014 at 8:21 AM, Drew Farris <[email protected]> wrote: > On Tue, May 6, 2014 at 8:53 AM, Christopher <[email protected]> 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
