accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [DISCUSS] Time for a 1.8.0 release?
Date Wed, 03 Aug 2016 21:46:55 GMT
My understanding was that maintenance releases (aka double dot, e.g.
1.7.2) had relaxed criteria because we expected the scope of changes
in them to be more limited. Even so, the release notes for 1.7.2,
1.7.1, and 1.7.0 all claim the ITs passed.

Is there a reason we can't parallelize the ITs? What's stopping
builds.a.o from running them? Specific requests from projects to asf
infra can get us resources if that's the problem.

On Wed, Aug 3, 2016 at 3:55 PM, Michael Wall <mjwall@gmail.com> wrote:
> They do fail intermittently, and have been for some time.  It takes over 6
> hours to do a full IT run and the builds.apache.org servers can't run
> them.  We use -skipITs there.  I'd be surprised if they were all passing
> for the 1.7.2 release.  They are not all passing now on the 1.7 branch.
>
> I was thinking that a passing -Psunny would be a good release criteria
> until we can get the failing ones cleaned up.  The referenced ITs are not
> part of the sunny profile.  Josh and I have been cleaning them up, but it
> is going to take some time.  Many of them really need to be refactored and
> the validity of the tests should be evaluated.  I think some of them could
> become unit tests.  And we really need them to run in less than 6 hours.
>
> Since only tickets for sporadicly failing ITs not part of the sunny profile
> were left in Jira, I didn't want to hold up progress on the release.  What
> do others think?
>
>
>
> On Wed, Aug 3, 2016 at 3:43 PM, Sean Busbey <busbey@cloudera.com> wrote:
>
>> do the referenced ITs still fail? IIRC, passing ITs is part of our
>> release criteria.
>>
>> On Wed, Aug 3, 2016 at 1:52 PM, Michael Wall <mjwall@gmail.com> wrote:
>> > I just moved the last 2 tickets out of 1.8.0.  Both tickets were for
>> > failing ITs.  Seems like we are ready now for the release.  Anyone
>> disagree?
>> >
>> > I plan on making an RC tomorrow.  I'll start with a RC0 to work out the
>> > process then make an RC1 if that goes smoothly.
>> >
>> > On Fri, May 27, 2016 at 5:13 PM, Keith Turner <keith@deenlo.com> wrote:
>> >
>> >> On Thu, May 26, 2016 at 8:57 PM, Michael Wall <mjwall@gmail.com> wrote:
>> >>
>> >> > Didn't get a chance to talk to Christopher so hopefully what I
>> understood
>> >> > from emails with Josh and him is correct.
>> >> >
>> >> > Moved issues out of 1.8.0.  Here is a summary of the fix version
>> changes
>> >> >
>> >> > 8 issues - 1.7.2, 1.8.0 => 1.7.2, 1.8.1
>> >> > 9 issues - 1.6.6, 1.7.3, 1.8.0 => 1.6.6, 1.7.3, 1.8.1
>> >> > 34 issues - 1.7.3, 1.8.0 => 1.7.3, 1.8.1
>> >> > 102 issues (BUG) - 1.8.0 => 1.8.1
>> >> > 248 issues (not BUG) - 1.8.0 => 1.9.1
>> >> >
>> >> > That leaves 3 issues in 1.8.0, I made them blockers
>> >> > - https://issues.apache.org/jira/browse/ACCUMULO-4157 (WAL can be
>> >> > prematurely deleted)
>> >> > - https://issues.apache.org/jira/browse/ACCUMULO-4165 (Create a user
>> >> level
>> >> > API for RFile)
>> >> > - https://issues.apache.org/jira/browse/ACCUMULO-1124 (optimize index
>> >> size
>> >> > in RFile)
>> >> >
>> >> > Keith has a PR in for 1124.  I am looking to put in a PR for 4157
>> >> > tomorrow/Sat.  Keith, if I need to move 4165 to 1.8.1 let me know.
>> >> >
>> >>
>> >> 1124 is merged.  4165 has a PR.  I also created a PR for 4318[1].  While
>> >> testing the new RFile API I tried to use try-with-resources with a
>> scanner
>> >> and found I could not.  I think it would be nice to get 4318 into 1.8.0
>> >> because its a change that can only be made on a minor release.
>> >>
>> >> [1]: https://issues.apache.org/jira/browse/ACCUMULO-
>> >> <https://issues.apache.org/jira/browse/ACCUMULO-4165>4318
>> >>
>> >>
>> >>
>> >> >
>> >> > Once those are closed/moved, I will cut an RC1.
>> >> >
>> >> > Mike
>> >> >
>> >> >
>> >> > On Thu, May 26, 2016 at 8:18 AM, Michael Wall <mjwall@gmail.com>
>> wrote:
>> >> >
>> >> > > Christopher,
>> >> > >
>> >> > > I'd like to talk this through with you before I move the tickets
to
>> >> make
>> >> > > sure I understand what you are saying here.
>> >> > >
>> >> > > Thanks for the note, it is helpful.
>> >> > >
>> >> > > Mike
>> >> > >
>> >> > > On Tue, May 24, 2016 at 6:41 PM, Christopher <ctubbsii@apache.org>
>> >> > wrote:
>> >> > >
>> >> > >> On Sun, May 22, 2016 at 9:42 PM Michael Wall <mjwall@gmail.com>
>> >> wrote:
>> >> > >>
>> >> > >> > After last weeks discussion with Josh, Christopher and
others at
>> the
>> >> > >> > Accumulo Working Day, I am going to shepherd the 1.8
release.
>> First
>> >> > >> step
>> >> > >> > is to create a release candidate?  Before I do that,
are there
>> any
>> >> > >> tickets
>> >> > >> > that need to get into the release?  I know Keith mentioned
1 or 2
>> >> and
>> >> > I
>> >> > >> > have one I'd like to finish.
>> >> > >> >
>> >> > >> > Here is what Jira says is unresolved,
>> >> > >> > https://s.apache.org/accumulo-1.8-unresolved
>> >> > >> >
>> >> > >> > On Wed I would like to move all tickets not identified
for the
>> 1.8
>> >> > >> release
>> >> > >> > to 2.0.  Then on Friday I would like to cut the first
release
>> >> > candidate
>> >> > >> for
>> >> > >> > 1.8.  Is that enough time?  Anything I am missing?
>> >> > >> >
>> >> > >> > Thanks
>> >> > >> >
>> >> > >> > Mike
>> >> > >> >
>> >> > >>
>> >> > >> I think it's probably time. I don't know that I'd bump the
stuff to
>> >> 2.0.
>> >> > >> I'd rather bump it to 1.9, just because we've been on a roll
with
>> this
>> >> > >> backwards compatibility thing, and I think there's probably
ongoing
>> >> > demand
>> >> > >> for updated 1.x versions.
>> >> > >>
>> >> > >> I'll try to go through the issues I've created (or have assigned
to
>> >> me)
>> >> > >> and
>> >> > >> bump them myself. So, if you could hold off on that for a
few more
>> >> days,
>> >> > >> it
>> >> > >> would help.
>> >> > >>
>> >> > >> Also, keep in mind, if you do bump using JIRAs batch features,
>> you've
>> >> > got
>> >> > >> to do it multiple times, depending on if they have more than
one
>> >> > >> fixVersion
>> >> > >> on them, otherwise you'll overwrite the multiple versions
with a
>> >> single
>> >> > >> one
>> >> > >> (or vice versa).
>> >> > >>
>> >> > >> Eg.
>> >> > >> (1.6.6, 1.7.2, 1.8.0) -> (1.6.6, 1.7.2, 1.8.1) // should
just be
>> bug
>> >> > fixes
>> >> > >> (1.7.2, 1.8.0) -> (1.7.2, 1.8.1) // should just be bug
fixes
>> >> > >> (1.8.0) -> (1.8.1 or 1.9.0) // depends on if bugfix or
feature
>> >> addition
>> >> > >>
>> >> > >
>> >> > >
>> >> >
>> >>
>>
>>
>>
>> --
>> busbey
>>



-- 
busbey

Mime
View raw message