Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] EE4J projects with dependencies on other EE4J projects...

Yes, your assumption is valid. Just to clarify, you suggesting not adding CQs for components which are or will be migrated to EE4J and planned to be released as part of EE4J_8 platform release? If so, I would suggest still adding CQ requests, mark them somehow and not process them until the platform release is ready. When all components are released it’s quick to check all these kind of CQs and close them. Doing it guarantees that we don’t miss anything.

— Dmitry 

On 26 Feb 2018, at 21:37, Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:

I want to run something past you before trying to disseminate it out to the community.

For background, please see my recent blog post on Third Party Content.

According to the IP Policy, an Eclipse project can just make use of the content produced by an other Eclipse project without having to connect with the Eclipse IP Team (i.e. a "Contribution Questionnaire" (CQ) is not required).

Many of the EE4J projects have other current and future EE4J projects as dependencies. We're in a bit of a weird state right (corner case) right now, were some of these dependencies are currently third-party, but will eventually be Eclipse projects.

At this point, I assume that the first release of the EE4J projects will use content produced by other EE4J projects where possible. 

I assume that either upstream projects will release before their EE4J consumers, or that related groups of projects (all?) will coordinate the timing of their first release.

Further, I assume that we prefer for downstream projects to consume the content produced by their EE4J siblings rather than the content as it exists today.

Are my assumptions valid?

I'd like to optimize everybody's time. It takes energy to create a CQ and energy to process it. In this spirit, we can accept an "invalid intermediate state" while we're bootstrapping.

Let's think about this in terms of the projected state at the time of the first release. If, at the time of release (as defined by the Eclipse Development Process), a dependency for an EE4J project will be served by a release version from another EE4J project, then no CQ is required.

e.g. Let's assume that Eclipse Grizzly has a dependency on content produced by Eclipse Project for JAX-RS (I have no idea whether or not his makes sense). If the Eclipse Project for JAX-RS engages in a successful release before (or concurrent with) Grizzly, Grizzly does not require a CQ for any version of JAX-RS.

Does this make sense?

Wayne

--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-pmc


Back to the top