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:05:38 GMT
Replies in line.


On Tue, May 6, 2014 at 7:34 AM, Drew Farris <drew.farris@gmail.com> wrote:

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

If we archive the version in Jira, it will not allow people to use that
version as Affected or Fix when modifying tickets (though it will leave
previous tickets in place).

This means that people filing an issue against 1.4 would have to leave this
field blank (or preferably state a non-archived version it also impacts)
and then mention that it impacts 1.4 in the environment or in the
description.

We could wait some period of time to archive the version and declare that
time period on the mailing list (say 6 months or 1 year). However, that's a
slippery slope. At what point do we stop waiting for issues to be filed?
Why did we archive 1.3.x?



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


This is a bad idea. We have the archive for a reason. We even say "if
you're looking for an older release, here's the archive." We can't keep
every major branch prominent forever.

Regardless of the current situation around a certain user base sticking
with the 1.4 branch, as a community our recommendation is that people not
use that version. Right? Or are we not in agreement on this?



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

For the record, no one is saying "never"; we're saying "probably not". It
would take a significant error (say a critical security flaw) along with a
user asking for us to have another 1.4 release after end-of-life. The same
goes for 1.3, as far as I'm concerned.

The biggest impact of that change means we stop looking for things to fix
in 1.4.



-- 
Sean

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