yetus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: Bringing Java API compliance checker to Hadoop (YETUS-445)
Date Tue, 08 Oct 2019 23:35:50 GMT
Hi Wei-Chiu,

I read back through the comments on YETUS-445 but without looking back
through patches, I’m missing some context. Is there a specific question we
need to bring to legal in order to get progress? Specific examples around
usage or not if category-x licensed software? Shipping source in an Apache
Yetus release vs providing code that downloads binaries at runtime?
Something like that?

Thanks,
Nick

On Mon, Oct 7, 2019 at 09:19 Wei-Chiu Chuang <weichiu@apache.org> wrote:

> Big +1
> We've hit this similar problem at least 3 times this year along.
>
> On Fri, Oct 4, 2019 at 8:14 PM Siyao Meng <smeng@cloudera.com> wrote:
>
> > Hi folks,
> >
> >   Recently our (Cloudera) internal API checker detects an API compat
> issue
> > when backporting a Hadoop commit (HDFS-14564). Though later it turns out
> it
> > isn't an issue (HDFS-14564 adds a new method in an interface, but that
> > interface isn't in any releases yet, so it's safe to do so), *it would be
> > great to have this checker in Yetus*.
> >
> >   Previously, we've also caught another API compatibility issue with our
> > internal checker, which is later solved in HDFS-14595
> > <https://issues.apache.org/jira/browse/HDFS-14595>. If we could have
> this
> > API checker in Yetus, such problem could be caught and solved much
> earlier
> > IMO.
> >
> >   This is why I commented in YETUS-445
> > <https://issues.apache.org/jira/browse/YETUS-445>. Would there be a
> > problem if we use GPL binaries in Yetus? If we are only using the
> binaries,
> > not including the source code, it should be fine? What am I missing here,
> > any suggestions?
> >
> >
> > Thanks!
> > Siyao Meng
> >
>

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