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 <[email protected]>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 <[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. > > > > > >> 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 <[email protected]> > 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 < > >> [email protected]>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 > >> >
