For example in the IoT PMC due to the different nature of the technologies used by the projects we are tends to be more a first filter to avoid obvious CQ mistakes to be sent to the legal team. We rarely discuss the "why" of the dependency. But we can spot obvious IP problems like direct dependencies to GPL code or bad classification (works-with or not).
-- Julien Vermillard On Tue, Mar 15, 2016 at 5:43 PM, Wayne Beaton <[email protected]> wrote: > Hi David. > > Note that I said that the PMC may "push back" based on license, not > reject. Very often there is a conversation that results in an option that > may have not been immediately obvious. Some projects do, for example, use > GPL-licensed libraries as "works-with" dependencies. An outright rejection > at the point of entry might make that conversation not happen or make it > happen without the right people being engaged (e.g. the IP Team). > > The technical merit question varies by PMC. The Eclipse PMC, for example, > is very involved in the decision making process regarding the use of > third-party libraries to ensure that subprojects consolidate on single > versions (I think so, anyway). The Eclipse Technology Project more-or-less > completely trusts the various projects to make third-party library > decisions that make sense for them. The Eclipse Tools project could > potentially fall somewhere in the middle, but I believe that reality is > that they're pretty hands-off. It's really a PMC's call to determine how > much they will be involved in the technical merit discussion. > > When I push back on a "earlier version" of a library, I regard it as a > sober second look. Did you pick that particular version for sake of > immediate convenience? In the longer term, does it make more sense or make > your (and everybody else's) life easier if you spend the time to just > upgrade? It's really the PMC's call whether or not to accept "no" as an > answer. > > The process for approval of newer versions of already approved libraries > has recently been improved. We don't put nearly as much effort into these > "delta" reviews. I'll see if I can dig up some specifics. > > Wayne > > On 15/03/16 12:20 PM, David Smiley wrote: > > > > On Tue, Mar 15, 2016 at 12:04 PM Wayne Beaton <[email protected]> wrote: > >> The PMC may push back on a CQ if the license is obviously a no-go. >> However, the PMC is not expected to have expertise in licensing matters and >> if there is any doubt, should just punt to the IP Team. >> > > If there is an obvious license no-go, then perhaps the CQ filing screen > could alert the submitter that they shouldn't bother if the license is XYZ? > > >> That is, of course, assuming that a CQ has technical merit. >> > > I'm confused on this... should the PMC be inquiring as to why a project > depends on something (technically for what purpose)? I trust project > committers, particularly with peer review, to not add dependencies that are > of no purpose. Furthermore there is a hurdle to adding dependencies with > the CQ process so adding a dependency will be avoided if the dependency > won't add value. > > Also, I will try and encourage a project to use a more recent version of a >> library when a more recent version has already been approved by the IP Team. >> > > The CQ filing process already brings to one's attention other CQs for > other versions. (I think you were involved in that feature; thank you). > Is that not enough? Perhaps the filing screen could further explicitly > encourage the submitter to simply use a pre-approved version if it's > compatible. > > As a separate matter; it'd be nice if it was easier to get approval for a > new version of something. I'd hope for that to be a fast-tracked thing > assuming no license changed. > > ~ David > -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > http://www.solrenterprisesearchserver.com > > > _______________________________________________ > incubation mailing [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visithttps://dev.eclipse.org/mailman/listinfo/incubation > > > -- > Wayne Beaton > @waynebeaton > The Eclipse Foundation > [image: EclipseCon NA 2016] <http://www.eclipsecon.org/na2015> > > _______________________________________________ > incubation mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/incubation > >
_______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation
