hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@apache.org>
Subject Re: /bin/ls permission issue on precommit tests
Date Wed, 02 Mar 2016 22:10:03 GMT
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 <enis.soz@gmail.com> 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 <enis.soz@gmail.com> wrote:
>
>> On Wed, Mar 2, 2016 at 12:24 PM, Sean Busbey <sean.busbey@gmail.com>
>> wrote:
>>
>>> On Wed, Mar 2, 2016 at 2:04 PM, Enis Söztutar <enis.soz@gmail.com> wrote:
>>> > On Wed, Mar 2, 2016 at 11:53 AM, Sean Busbey <busbey@apache.org> 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
>>>
>>
>>

Mime
View raw message