Bugzilla – Full Text Bug Listing
| Summary: | [proposal] modeling.xsemantics | ||
|---|---|---|---|
| Product: | Community | Reporter: | Stephanie Swart <stephanie.swart> |
| Component: | Proposals and Reviews | Assignee: | Eclipse Management Organization <emo> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | cydnie.smith, developer, Ed.Merks, lorenzo.bettini, mor-dev, sharon.corbett, sven.efftinge, wayne.beaton, webmaster |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows NT | ||
| URL: | https://projects.eclipse.org/proposals/xsemantics | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | 520383 | ||
| Bug Blocks: | |||
|
Description
Stephanie Swart
We’ve received all of the project requirements and have scheduled the creation review to conclude on MONTH/DAY/YEAR. Please continue to monitor communication channels. Following the creation review, we will initiate the provisioning process. As part of this process, we will bring committers on board. To gain committer status, some paperwork [1] must be completed. The exact nature of that paperwork depends on several factors, including the employment status of the individual and the Eclipse Foundation membership status of the employer. If you can be ready with the paperwork in time for the completion of the creation review, then we can move quickly through the provisioning process. When we initiate provisioning, committers will be sent an email with instructions; please don't send any paperwork in until after you receive those instructions. Please encourage all future project committers to join the incubation mailing list [2]. We use this list to connect committers from new projects to their peers in other projects in the incubation phase and to mentors who can help answer questions and discuss issues related to the project onboarding process. [1] https://www.eclipse.org/projects/handbook/#paperwork [2] https://dev.eclipse.org/mailman/listinfo/incubation (In reply to Stephanie Swart from comment #1) > We’ve received all of the project requirements and have scheduled the > creation review to conclude on August 16, 2017. Please continue to monitor > communication channels. > > Following the creation review, we will initiate the provisioning process. As > part of this process, we will bring committers on board. To gain committer > status, some paperwork [1] must be completed. The exact nature of that > paperwork depends on several factors, including the employment status of the > individual and the Eclipse Foundation membership status of the employer. > > If you can be ready with the paperwork in time for the completion of the > creation review, then we can move quickly through the provisioning process. > When we initiate provisioning, committers will be sent an email with > instructions; please don't send any paperwork in until after you receive > those instructions. > > Please encourage all future project committers to join the incubation > mailing list [2]. We use this list to connect committers from new projects > to their peers in other projects in the incubation phase and to mentors who > can help answer questions and discuss issues related to the project > onboarding process. > > [1] https://www.eclipse.org/projects/handbook/#paperwork > [2] https://dev.eclipse.org/mailman/listinfo/incubation Great news! All project leads and committers of the Xsemantics project are already Eclipse committers, so I assume there is nothing to prepare. (In reply to Jens von Pilgrim from comment #3) > Great news! > > All project leads and committers of the Xsemantics project are already > Eclipse committers, so I assume there is nothing to prepare. Correct Congratulations! Your project review is successful! The project provisioning process is complete! Here you will find all of the information regarding resources allocated to your project: Source Code Management: As your project's main Git repository is hosted at GitHub, we will need to move it to the Eclipse organization and flatten any previous history. This work can begin as soon as you have check in permission from EMO legal. Issue Tracker: https://bugs.eclipse.org/bugs/describecomponents.cgi?product=xsemantics Outbound Communication: Mailing list: https://dev.eclipse.org/mailman/listinfo/xsemantics-dev Project Website repository: ssh://committer_id@git.eclipse.org:29418/www.eclipse.org/xsemantics.git Commits will be published to www.eclipse.org/xsemantics within 5 minutes Downloads: http://download.eclipse.org/xsemantics Archives: http://archive.eclipse.org/xsemantics Builds: You can upload releases to ~committer_id/downloads/xsemantics via SFTP or SCP (to build.eclipse.org) or from a CI instance at Eclipse.org Older builds should be moved to the archives area when they are no longer required. Your next step is to submit an initial contribution [1] for review by the IP Team. Please do not commit any code to an Eclipse Foundation Git repository until after you receive the IP Team's approval. IP requests are referred to as Contribution Questionnaires (CQs). When the initial CQ receives “check in” and/or “full approval” you are now ready to check the initial project code contribution into your project’s repository. [1] https://www.eclipse.org/projects/handbook/#ip-initial-contribution Greetings project team, It looks like your initial contribution was approved (2018-09-18) and you have no open CQs; however, there have been no releases planned. What is the status of this project? Please note, it also appears that no third party IP requests have been entered. If you have any pre-req dependencies, they will need to be cleared prior to release. However, if none are required, you can proceed with your plans. For more information on the release process, please check out our handbook [1]. [1] https://www.eclipse.org/projects/handbook/#release Hi Cindie we don't have external dependencies thus from what I understand we don't need CQs. I personally still haven't got time to work on the whole release process (I mean the bureaucracy behind the release process)... (In reply to Lorenzo Bettini from comment #8) > Hi Cindie > > we don't have external dependencies thus from what I understand we don't > need CQs. I'm pretty sure that this isn't true. The manifest shows that org.eclipse.xsemantics.dsl.ui has a dependency on ANTLR, log4j, and commons.logging. Further, AFAICT, org.eclipse.xsemantics.runtime has requires com.google.inject and log4j. Your references don't include version ranges, but AFAICT approved versions are being resolved by Maven, so we likely have no IP exposure from these libraries. I'm a little concerned, however, that you don't consider these to be external dependencies. Am I missing something? Note that, AFAICT, the project bundles are directly referencing these libraries, not referencing them indirectly via Xtext (which does not require any accounting) [0]. > I personally still haven't got time to work on the whole release process (I > mean the bureaucracy behind the release process)... AFAICT (from reading just the README file), the project has created at least five releases without having engaged in a Release Review as is required by the Eclipse Development Process. I need the project team to validate that all third-party dependencies are properly accounted for, and for the project team to engage in a release review [1]. Note that a recent change in the EDP now permits projects to engage in a single Release Review per year. I further recommend that the best practice of specifying version ranges in the manifest be implemented. [0] https://www.eclipse.org/projects/handbook/#ip-third-party [1] https://www.eclipse.org/projects/handbook/#release-review (In reply to Wayne Beaton from comment #9) > (In reply to Lorenzo Bettini from comment #8) > > Hi Cindie > > > > we don't have external dependencies thus from what I understand we don't > > need CQs. > > I'm pretty sure that this isn't true. > > The manifest shows that org.eclipse.xsemantics.dsl.ui has a dependency on > ANTLR, log4j, and commons.logging. Further, AFAICT, > org.eclipse.xsemantics.runtime has requires com.google.inject and log4j. > Your references don't include version ranges, but AFAICT approved versions > are being resolved by Maven, so we likely have no IP exposure from these > libraries. > > I'm a little concerned, however, that you don't consider these to be > external dependencies. Am I missing something? sorry, by "external dependencies" I meant something that is not taken from Eclipse p2 repositories. All the dependencies of Xsemantics are bundles from Eclipse p2 repositories and I thought we wouldn't need CQs for such dependencies, isn't it true? > Note that, AFAICT, the project bundles are directly referencing these > libraries, not referencing them indirectly via Xtext (which does not require > any accounting) [0]. I'm not sure I understand what you mean by "directly referencing these libraries, not referencing them indirectly via Xtext"... > > I personally still haven't got time to work on the whole release process (I > > mean the bureaucracy behind the release process)... > > AFAICT (from reading just the README file), the project has created at least > five releases without having engaged in a Release Review as is required by > the Eclipse Development Process. but those are milestones not final releases... I seemed to understand that we can publish milestones without release reviews (at least I was told I was allowed to do that in another Eclipse project) > I need the project team to validate that all third-party dependencies are > properly accounted for, and for the project team to engage in a release I still don't understand what further checks I should do on the dependencies... IIRC they are the standard dependencies of typical Xtext-based projects... > review [1]. Note that a recent change in the EDP now permits projects to > engage in a single Release Review per year. > > I further recommend that the best practice of specifying version ranges in > the manifest be implemented. you mean minimal version, or entire range? > > [0] https://www.eclipse.org/projects/handbook/#ip-third-party > [1] https://www.eclipse.org/projects/handbook/#release-review (In reply to Lorenzo Bettini from comment #10) > sorry, by "external dependencies" I meant something that is not taken from > Eclipse p2 repositories. All the dependencies of Xsemantics are bundles from > Eclipse p2 repositories and I thought we wouldn't need CQs for such > dependencies, isn't it true? > Orbit dependencies are generally tracked with CQ. Sometimes it gets a bit fuzzy when the bundle you directly depend upon (require) exports its dependencies so you don't notice that you have a bundle requirement on a non-org.eclipse.* bundle. > I'm not sure I understand what you mean by "directly referencing these > libraries, not referencing them indirectly via Xtext"... > I.e., you have bundle requirements on bundles that are not Xtext bundles (and don't have namespace org.eclipse.*) but rather Orbit bundles with external namespaces. > > > I personally still haven't got time to work on the whole release process (I > > > mean the bureaucracy behind the release process)... > > > > AFAICT (from reading just the README file), the project has created at least > > five releases without having engaged in a Release Review as is required by > > the Eclipse Development Process. > > but those are milestones not final releases... I seemed to understand that > we can publish milestones without release reviews (at least I was told I was > allowed to do that in another Eclipse project) > It's really not so much work! In the portal you can hit the button to produce the IP log. Wayne scans the repo/dependencies. All your external dependencies are Orbit dependencies so they only need a piggyback CQ; those are handled automagically... > > I need the project team to validate that all third-party dependencies are > > properly accounted for, and for the project team to engage in a release > > I still don't understand what further checks I should do on the > dependencies... IIRC they are the standard dependencies of typical > Xtext-based projects... > You personally don't need to do the checks, you just need to ensure that a proper release process is kicked off once a year so that the IP team are prompted to do their part of the work (which is most of the work). > > review [1]. Note that a recent change in the EDP now permits projects to > > engage in a single Release Review per year. > > > > I further recommend that the best practice of specifying version ranges in > > the manifest be implemented. > > you mean minimal version, or entire range? > It's of course generally a good idea to use a version range (lower bound being what you actually tested that you need and upper bounded to the next major version increase, with the assumption that that version will break APIs). Of course the point is not to resolve against some arbitrary version that doesn't actually work. (In reply to Ed Merks from comment #11) > (In reply to Lorenzo Bettini from comment #10) > > sorry, by "external dependencies" I meant something that is not taken from > > Eclipse p2 repositories. All the dependencies of Xsemantics are bundles from > > Eclipse p2 repositories and I thought we wouldn't need CQs for such > > dependencies, isn't it true? > > > > Orbit dependencies are generally tracked with CQ. Sometimes it gets a bit > fuzzy when the bundle you directly depend upon (require) exports its > dependencies so you don't notice that you have a bundle requirement on a > non-org.eclipse.* bundle. Totally correct. But I actually noticed bundle and package dependency references in some of the plug-in manifests. That is, AFAICT, the project code does have some *direct dependencies* on "external dependencies" (the handbook and IP Due Diligence Process refer to this as "third party content"). I'm more concerned that the definition of third-party dependencies might not be well-understood and that there is potential that unintended third party content might leak in. Especially with the version ranges unconstrained (though, that all of the dependencies most likely come from Eclipse Orbit mitigates this concern). Thanks Wayne and Ed for the helpful info! We'll look into this. How urgent is this, though? Would it be ok if we aim to have completed everything that's required on our side (e.g. remaining CQs, etc.) in about 2-3 months from now? This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. We're still working on this The project is up and running, so I'm going to close this tracking issue. The EMO has initiated a progress review; we're tracking it here [1]. Note that EMO-initiated reviews are something that we're just starting to experiment with [2]. > Totally correct. But I actually noticed bundle and package dependency > references in some of the plug-in manifests. That is, AFAICT, the project > code does have some *direct dependencies* on "external dependencies" (the > handbook and IP Due Diligence Process refer to this as "third party > content"). > > I'm more concerned that the definition of third-party dependencies might not > be well-understood and that there is potential that unintended third party > content might leak in. Especially with the version ranges unconstrained > (though, that all of the dependencies most likely come from Eclipse Orbit > mitigates this concern). In the meantime, the IP Due Diligence Policy and Process has changed a bit. CQs are now only used for vetting content, not tracking its use. I've scanned the project code using the Dash License Tool [3], and it appears that everything is in order from an IP Due Diligence POV (at least for what I believe is the primary build in CI). That is, I don't believe that any additional CQs are required. [1] https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/37 [2] https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/1 [3] https://github.com/eclipse/dash-licenses |