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: 
 <CAMUu0w-95qqj=+PoZeg_yaZBL+kH0Z2edX_YK9hxPaixAEHTVQ@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>
From: Sean Busbey <sean.busbey@gmail.com>
Date: Wed, 2 Mar 2016 14:24:24 -0600
Message-ID: 
 <CAN5cbe7OGr+585TDJ9Ko5Y2Kv-RuwKfQPcXOUdH7X9wNJEaPKA@mail.gmail.com>
Subject: Re: /bin/ls permission issue on precommit tests
To: dev@yetus.apache.org
Cc: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 2, 2016 at 2:04 PM, Enis S=C3=B6ztutar <enis.soz@gmail.com> wro=
te:
> 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 ar=
e
> not releasing yetus together with HBase. We can depend on any snapshot ta=
g
> 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 attempt=
ing
to use semantics to avoid the root cause of yetus needing to release more o=
ften.
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 f=
or
ASF internal belly-itching).


>
>>
>> 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 de=
sire.

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.


--=20
Sean