yetus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <enis....@gmail.com>
Subject Re: /bin/ls permission issue on precommit tests
Date Wed, 02 Mar 2016 22:18:44 GMT
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 <busbey@apache.org> 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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message