so this means for new versions we still need CQs? e.g. the current slf4j 1.7.30
Am 24.01.20 um 17:36 schrieb Wayne Beaton: > Almost. > > So we can use any libary in any version if the license is in the approved >> list > > The library and version needs to have been vetted either by the Eclipse IP > Team (i.e., a CQ exists for that library and version) or in the Clearly > Defined dataset with a high confidence score (we're thinking 80% at this > point). I'm going to assume that most of you don't know what Clearly > Defined is (I talk a bit about it here > <https://waynebeaton.wordpress.com/2019/10/09/revising-the-eclipse-ip-policy-third-party-content/> > ). > > We've had a "service release" exception for a while now; a service release > of a third party library based on a major or minor version that we've > already approved may be used without creating a CQ. > > HTH, > > Wayne > > On Fri, Jan 24, 2020 at 11:30 AM Christian Dietrich < > [email protected]> wrote: > >> 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 >> <[email protected]> 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 >> <[email protected]> <[email protected]> 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 >> >> [email protected] >> https://in.honeywell.com/sites/aero/ENG/advance-tech/crew-intf/Pages/crewhome.aspx >> >> >> >> _______________________________________________ >> cross-project-issues-dev mailing [email protected] >> 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 [email protected] >> 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 [email protected] >> 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 [email protected] >> 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 [email protected] >> 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 [email protected] >> 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 >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
