accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Draft release timeline for 2.0.0
Date Tue, 12 Jun 2018 15:32:57 GMT
On Tue, Jun 12, 2018 at 10:49 AM, Josh Elser <elserj@apache.org> wrote:
>
>
> On 6/12/18 1:20 AM, Christopher wrote:
>>
>> On Mon, Jun 11, 2018 at 10:46 PM Josh Elser<elserj@apache.org>  wrote:
>>
>>> I'm just trying to point out the fallacy of meeting deadlines when the
>>> criteria for "success" is undefined.
>>>
>>>
>> Why? I proposed the timeline to solicit opinions on it. Use whatever
>> subjective criteria you want to inform your own. If you have criteria that
>> you think won't be satisfied within that timeline, then raise them for
>> discussion.
>
>
> Again, I am stating that a timeline with no recognition of what work needs
> to be done is silly. Yes, you can draw a line in the sand for when you want
> work to be done, but that's ineffective in making an actionable feature
> complete date.

Setting a date is an approach that many projects follow (OpenJDK just
adopted this approach).  With that approach the project takes whatever
features are complete at the given time.  Other projects take the
approach of agreeing on a list of features and saying when those are
done, we release.  Accumulo has not formally adopted either approach,
periodically someone just proposes a release.   For 2.0.0 I am in
favor of setting a tentative date of Sep 1 for feature freeze.  We
already have a lot of good features committed.  I would like to see
some more added, but I would also like to see 2.0.0 released which is
why I am in favor of the date.

>
> If you want the date to be meaningful, you need to understand what work
> actually _has_ to be done and structure the date around that. Does this make
> sense?
>
>> If Jira is overburdened, move everything out and have people move things
>>>
>>> back. We have multiple tools -- we should at least have one in use.
>>> Otherwise, this just seems like there are decisions happening behind the
>>> scenes.
>>>
>>>
>> You lost me. Every release, we triage (finish, reject, or bump) open
>> issues; nobody's done that yet for 2.0. That's all I was talking about
>> with
>> regard to the issue tracker noise.
>
>
> I thought you were saying that there were too many open issues on Jira to
> glean any information on outstanding work from it. I was trying to give a
> suggestion about how to move past that.

Mime
View raw message