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