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]
<mailto:[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 list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
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
