Hello Wayne,
thanks for that explanation.
So we can use any libary in any version if the license is in the approved
list
and there is no tracking of which libary in which version
is used by which projects?
~Christian
Am 24.01.20 um 17:24 schrieb Wayne Beaton:
I'm working on some updates to the handbook and we're rolling out some
(relatively minor) updates to the "Create a CQ" functionality on the PMI.
My apologies to all that this is taking longer than I'd hoped.
The short version is that you don't need any tools to not create a CQ.
In this particular case, we know that the libraries in question have been
approved by the IP due diligence process, so just don't create any new CQs.
The challenging bit is how we make it easier for committers to know that
they don't need to create a CQ; I'm working on a solution to that problem
that I've committed to rolling out this quarter (at least part of which
will be contributed to Eclipse Dash, so you all can help maintain it). I
need you to be patient for a little while longer for this.
The slightly longer version is that I've spent a lot of effort to get our
existing IP data into a state where we can do more in an automated manner.
Over the years we've collected a lot of data, but--as you likely already
know--it's not been collected in a form that makes it consistently
queryable. I've got that (mostly) sorted out. We're also starting to
leverage license data from Clearly Defined, a project which crowd sources
license data from open source projects. My expectation is that we will
still need to create CQs for third party content, we'll just have to create
a lot fewer of them. Those that we do create will follow the same process
that we do today. Again, I owe a longer explanation.
Regarding IP Logs, I've been experimenting using build tools to fill in the
gaps. This works pretty well for Maven-, Gradle- and NPM-based builds,
where you can build an accurate dependency list right out of the tool
(e.g., "mvn dependency:list"). FWIW, the tools that I referred to have
evolved from scripts that I've been using for a few months to map the
results from that dependency list to license and CQ information. I'll start
attaching the output from the scripts to IP Log CQs as a stop gap.
HTH,
Wayne
On Fri, Jan 24, 2020 at 11:02 AM Christian Dietrich <christian.dietrich@xxxxxxxxx> wrote:
but where is then new tooling for that ?
the portal still creates cqs
Am 24.01.20 um 16:58 schrieb Wayne Beaton:
- the bureaucracy
I assume that you mean IP due diligence. There should be no Eclipse
Foundation bureaucracy required. All of the libraries in question have
already been approved, so the project team can just start using them.
Following the Eclipse Foundation's Board of Directors approval of our new
IP Policy in October, Piggyback CQs are no longer required. I owe the
community a much longer discussion about all of the changes. There is some
discussion on by blog<https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/> <https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/> <https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/> <https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/>
.
You will still have to submit your IP Log for review, but only the next
time that you actually have to do a release review. Note that changes made
to the EDP in December 2018 make it so that you can do releases for an
entire year following a successful release review (i.e., we no longer
require a review for every single release).
I hope that this knocks at least one thing off of the list (I understand
that the other things on the list are harder
HTH,
Wayne
On Fri, Jan 24, 2020 at 3:07 AM Christian Dietrich <christian.dietrich@xxxxxxxxx> <christian.dietrich@xxxxxxxxx> wrote:
Hi,
we (Xtext) currently have no capacity to do
- the bureaucracy
- analyze impacts on logging customization points in Xtext
- analyze who else uses what logging and how that change would affect them
and indirectly us
Regards
Christian
Am 23.01.20 um 15:05 schrieb Ed Willink:
Hi
If there is a conflict hazard then it already exists. Examining one of my
workspaces...
Good (SLF4J) - jgit, m2e
Bad (LOG4J) - mwe, ocl, qvtd, xtend, xtext
This is complete news to me. I continue to use log4j since it avoids
changing code styles that have been unchanged for many many years. Other
projects probably just copy prevailing practice.
I presume changing is rather easy, and of no consequence to the exported
API, since the use of log4j is by import package.
However without a commitment to change by Xtext, I would be reluctant to
change any Xtext-based project.
Regards
Ed Willink
On 23/01/2020 13:09, Hickman, Steve (AdvTech) wrote:
Log4j 1.x reached end of life in 2015. The documentation for it now
appears to have gone offline. There are some Eclipse projects (call them L1
projects) that currently use Log4j 1.x directly rather than SLF4J. That
means that any projects that depend on L1 projects cannot use Log4J 2.x
without risking dependency collisions from attempting to load multiple
versions of Log4J.
SLF4J was created precisely to eliminate dependencies on specific logging
implementations.
It is important that libraries like those that plug into Eclipse not
unintentionally force a specific logging implementation on their users.
Those library developers have no way of knowing – and probably no way of
satisfying – all the requirements of their various sets of users.
Given that, it seems that Eclipse should make SLF4J the ‘official’ logging
API for all Eclipse libraries.
*Steve Hickman*
Software Architect
*Honeywell* | Aerospace
Office: 480-236-8367
steve.hickman@xxxxxxxxxxxxx
https://in.honeywell.com/sites/aero/ENG/advance-tech/crew-intf/Pages/crewhome.aspx
_______________________________________________
cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
