yetus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <>
Subject Re: /bin/ls permission issue on precommit tests
Date Wed, 02 Mar 2016 21:33:09 GMT
On Wed, Mar 2, 2016 at 12:24 PM, Sean Busbey <> wrote:

> On Wed, Mar 2, 2016 at 2:04 PM, Enis Söztutar <> wrote:
> > On Wed, Mar 2, 2016 at 11:53 AM, Sean Busbey <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message