I have seen it in a couple of places: HBASE-15325, HBASE-15375, HBASE-15181, HBASE-14949. I had checked the hosts before, I remember H0 and ubuntu-4 as hosts, but I assumed that this is not host specific, thus did not do the exclude.
Let's do turn off the docker mode if you think that it will solve the issue. I really just want to unblock precommit builds. Enis On Wed, Mar 2, 2016 at 2:10 PM, Sean Busbey <[email protected]> wrote: > How often is the problem happening? I hadn't seen it come up prior to > this thread. > > What about just turning off docker mode? > > What about seeing if this is only happening on a single host and just > blacklisting that host until the release? > > -Sean > > On Wed, Mar 2, 2016 at 3:49 PM, Enis Söztutar <[email protected]> wrote: > > Let me do another proposal (for the HBase community) > > > > Let's set USE_YETUS_PRERELEASE in the HBase precommit job for now until > > 0.2.0 release. Once the release is out, we can switch it back to using > > 0.2.0 and depend on 0.2.0 until 0.3.0. > > > > How does this sound? > > > > Enis > > > > On Wed, Mar 2, 2016 at 1:33 PM, Enis Söztutar <[email protected]> > wrote: > > > >> On Wed, Mar 2, 2016 at 12:24 PM, Sean Busbey <[email protected]> > >> wrote: > >> > >>> On Wed, Mar 2, 2016 at 2:04 PM, Enis Söztutar <[email protected]> > wrote: > >>> > On Wed, Mar 2, 2016 at 11:53 AM, Sean Busbey <[email protected]> > wrote: > >>> > > >>> >> Such a tag would be a distribution according to ASF rules. The Yetus > >>> >> PMC would have to vote on it just as we do releases. > >>> >> > >>> > > >>> > Not necessarily. We can depend on a pre-release tag of any of our > >>> > dependencies as long as we are not releasing them with our release. > We > >>> are > >>> > not releasing yetus together with HBase. We can depend on any > snapshot > >>> tag > >>> > for our precommit build. I was suggesting that the yetus community > have > >>> a > >>> > guideline on what commit has is the best. > >>> > > >>> > >>> It would be a distribution for _the_Yetus_PMC_. HBase is free to do as > >>> it pleases, you are correct, but ASF rules about use from those > outside of > >>> dev@yetus is clear: If the Yetus PMC is aware of regular use of our > >>> project in > >>> non-released form we need to take action to stop it. > >> > >> > >>> I *really*, *really* would like to avoid going down the rabbit hole of > >>> ASF rules lawyering on "who's using the artifact" and other ways of > >>> attempting > >>> to use semantics to avoid the root cause of yetus needing to release > more > >>> often. > >>> That will be exhausting, a waste of time that could instead be put > towards > >>> actually having releases, and will doom the Yetus project to fail in > >>> its expressed purpose of making software for the public good (rather > than > >>> for > >>> ASF internal belly-itching). > >>> > >> > >> ASF internal projects are the immediate consumer of yetus today and we > >> depend on it in a critical manner in the development lifecycle. That is > why > >> prioritizing ASF internal needs for YETUS makes sense to me. Given > enough > >> time, and if yetus community keeps up with frequent releases and more > >> stability we would not need to depend on unreleased tags. But if HBase > and > >> Hadoop and other projects are blocked for precommit until a release > which > >> may be another week or so, I would rather go with a solution that fixes > the > >> issue now and worry about the perfect solution later. > >> > >> > >>> > >>> > >>> > > >>> >> > >>> >> The answer to the issue of blocking downstream folks is to release > more > >>> >> often. > >>> >> > >>> >> The Yetus PMC has a release cadence goal of weekly. Other projects > >>> >> that want access to more frequent releases can help the situation by > >>> >> helping to vote on releases. > >>> >> > >>> > > >>> > This is great, but I did not see it happen yet. Again, my main goal > is > >>> to > >>> > unblock current state with the least amount of friction. > >>> > > >>> > >>> As I mentioned, the best way to unblock the current state is to help > >>> vote on releases. > >>> > >>> Another way to help would be to be more vocal on prioritization for > >>> things going into a release. For example, we have the 0.2.0 vote > closing > >>> this coming Friday rather than the prior Monday because the Yetus > >>> community prioritized fixing a few last sharp edges over > >>> the weekend. More voices that state the pressing need for blocking > >>> issues will help the community make calls that are in line with what > you > >>> desire. > >>> > >>> FWIW, I had no visibility that HBase was hitting YETUS-285 and so I > >>> had no reason to push for a sooner release with my HBase hat on. > >>> > >>> > >>> -- > >>> Sean > >>> > >> > >> >
