On Fri, Jan 24, 2020 at 5:58 PM Wayne Beaton < [email protected]> wrote:
> - 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/> > . > > 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). > Wayne, how does one maintain the IP log if not doing PB CQs ? It's an honest question as not filing PB CQs will save me so much time. > > 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 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 -- Alexander Kurtakov Red Hat Eclipse Team
_______________________________________________ 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
