Mailing-List: contact dev-help@yetus.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@yetus.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAN5cbe5GCG8goo+v-5JURMpyX3oF639Vr1n+aaB6gdnj+Lm5+w@mail.gmail.com>
References: 
 <CAMUu0w9mP57t8d66OiX44sw4J+AV4veZRqCpM3VvRX7+Bh=m4A@mail.gmail.com>
 <D2FC7CAC.3C73F%cnauroth@hortonworks.com>
 <CALte62wsFwh58wDhdi6LdFRJ3g1xO4u6yctXiOWJmER=OsHnew@mail.gmail.com>
 <CAMUu0w8F54zUXSWD5HqhrOQBZesyNVuM08WsW-O=rhXN7Pjgyg@mail.gmail.com>
 <CAN5cbe5by_gQxctQLjMSwa1am5OXefVDsXv4h6DO+F8Ng9CqAA@mail.gmail.com>
 <CAMUu0w-95qqj=+PoZeg_yaZBL+kH0Z2edX_YK9hxPaixAEHTVQ@mail.gmail.com>
 <CAN5cbe7OGr+585TDJ9Ko5Y2Kv-RuwKfQPcXOUdH7X9wNJEaPKA@mail.gmail.com>
 <CAMUu0w9vx5sbxSeOrvPiAfHgtan4jB+7ZUUYgdcM1Acps7MamA@mail.gmail.com>
 <CAMUu0w-uqmf8aMQZfrGJzu1WqVaf05+k+AphwOOAKgjFUD-bdw@mail.gmail.com>
 <CAN5cbe5GCG8goo+v-5JURMpyX3oF639Vr1n+aaB6gdnj+Lm5+w@mail.gmail.com>
From: =?UTF-8?Q?Enis_S=C3=B6ztutar?= <enis.soz@gmail.com>
Date: Wed, 2 Mar 2016 14:18:44 -0800
Message-ID: 
 <CAMUu0w83tsyGcZfOWjVOXy-jCLzR2qpH8L6MeovcG+Xc1K=-=w@mail.gmail.com>
Subject: Re: /bin/ls permission issue on precommit tests
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Cc: dev@yetus.apache.org
Content-Type: multipart/alternative; boundary=001a114fc102009b75052d184532

--001a114fc102009b75052d184532
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=B6ztutar <enis.soz@gmail.com> w=
rote:
> > 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=C3=B6ztutar <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=C3=B6ztutar <enis.soz@gmail.co=
m>
> 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 Yet=
us
> >>> >> 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 a=
s
> >>> 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 o=
f
> >>> 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 i=
s
> 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 fixe=
s
> 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
> >>>
> >>
> >>
>

--001a114fc102009b75052d184532--