Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incubation] Adding dependencies -- abbreviated instructions
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 <wayne@xxxxxxxxxxx> 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 


_______________________________________________
incubation mailing list
incubation@xxxxxxxxxxx
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

Back to the top