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/> > . > > 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]> 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 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 -- Wayne Beaton Director of Open Source Projects | Eclipse Foundation, Inc.
_______________________________________________ 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
