Community
Participate
Working Groups
Short answer: they can not. Everything must be released ... s i m u l t a n e o u s l y. But, there are complications. I am opening this bug for general discussion, to hopefully end-up with a reasonable understanding, both on my part, and for the community, on what the rules, procedures, and processes are. This comes up in a specific case because Papyrus is part of the Sim Rel (desired for Juno and was for Indigo) and they depend on XWT from e4, which is not part of the Simultaneous Release. See bug 347239 and bug 370670 for some cases where this issue has surfaced visibly, but ... there are likely unspoken issues, as well. (Apologies in advance if we have talked about this previously, and I have just forgotten or lost the documentation ... if so, pointers welcome). I will use Papyrus and XWT in following discussion to make it concrete, but I mean for this discussion to apply to any Project X and Project Z. The fundamental problem is that there are a list of requirements for projects (and bundles and features) to "satisfy" in order to a) release at all and b) release as part of the simultaneious release. So, for Papyrus to "release", using XWT, it is Papyrus, essentially, that must "release XWT", if XWT does not. Obvious best option: Papyrus to convince XWT to "release" what they need at same time they need it. This really should be the first course of action (and, if it was up to me alone, that would be the only course of action). But, I can imagine cases where, say, XWT "doesn't want to bother", but if Papyrus wants to do the extra work for a bundle or two, then XWT would have no objections. But what does this mean? Seems at a minimum, Papyrus would need explicit (documented) "permission" to do this from XWT? In addition, Papyrus would have to include in _their_ release documentation, all the relevant stuff for an indirect XWT release ... IP Logs, compliance with release rules, etc. and simultaneious release rules? That seems kind of complicated ... after all, if there was a problem, Papyrus committers could not fix it (assuming no overlapping committers, which I do not know about, in this case). So ... what does the community think? And, XWT, and Papyrus? :) I plan to put this on Planning Council agenda for our March meeting, but thought I'd use this "cross-project" bug to gather information, and maybe complications I am not aware of. Are there other cases? Other concerns?
Other then the release train topic, doesnt it also mean that Papyrus needs to make a "release" of XWT? So I think it boils down whether one project can "release" another project, which I believe it cannot. It would be a different story if XWT had a previous release say from 6 month ago and Papyrus would just use that fixed previous release which is not in the release train. Then it already had all the required docs and of course that 6 month old release need to satisfy all the requirements of the release train. Still there is a better chance this might work. just me 2 cents....
interesting question. We ( EEF team ) had similar problem last year, when we decided to provide a extension that use EPF, which don't take part of the release train. After asking to the EPF team if they would like to be part of the release train and provide a p2 repo of their bits, with no luck, we decided to only publish on the release train repository the features that can be installed with the release train. this can be an acceptable solution , because there is no need to provide different repositories, just different features that includes release train dependencies or not. hope i am clear enough,
I have already thought of one complication and one observation: In a case like XWT-Papyrus, is might be hard for "XWT to release" since it is merely one component of an incubating project (I think) and from what I've been told (according to current rules and dev process) ... "only projects can release, not components". The other interesting thing, this might be hard to check for or "enforce" from a technical, automated way. If it wasn't for some bugs that just happened to have popped up, who would notice if Papyrus was including "e4.xwt" packages in their distribution or repository? I mean, how do we know -- easily -- what packages should be there in repo and which not? (I'm not saying we'd have to ... we can trust committers to follow the rules ... just making the observation).
It seems like there are two questions here: 1) Can a project in the simultaneous release make use of *released* content from projects that are not participating in the simultaneous release. -> To this question I would say why not. It is similar to using a third party library that doesn't actively participate in our releases. As long as the required code has gone through the process of having a release, including IP documentation, etc, then it seems like fair game to use it. Eclipse projects release subsets of the bundles from other Eclipse projects all the time. For example if Jetty decided not to participate in the simultaneous release, but had official releases every three months, I think it should be fine for Equinox or Platform to include previously released Jetty bundles in their sim rel contribution (just like they did when Jetty was a 3rd party library). 2) Can a project have a release that includes *unreleased* content from another project. -> This is really a general foundation question rather than specific to the release train. I assume the answer to this is "no".
AFAIK, a release exists for the e4 project, with IP log and all that legal stuff. The way we pick up XWT is a release version of the E4 project. Currently, we use this tool as a third party tool. As it is available within the eclipse community, we believed we have not to do any CQ. We are in case N°1 of previous comment. [We started simultaneously a discussion with the XWT team to check if a release could be done in Juno or if we could do by our side a release of the needed components of XWT.]
(In reply to comment #5) > AFAIK, a release exists for the e4 project, with IP log and all that legal > stuff. The way we pick up XWT is a release version of the E4 project. > Currently, we use this tool as a third party tool. As it is available within > the eclipse community, we believed we have not to do any CQ. We are in case N°1 > of previous comment. > > [We started simultaneously a discussion with the XWT team to check if a release > could be done in Juno or if we could do by our side a release of the needed > components of XWT.] As far as I know, there has been no official Eclipse release of XWT. Do you have any pointers to the review? docuware, etc? And, since XWT is a "component" of e4 incubator, then its really a question if e4 incubator did (or will do) a pre-graduation release.
Here are the pointer I have for the last review (review of e4 0.9, where XWT is active): http://www.eclipse.org/project-slides/e4%200.9%20Release%20Review.pdf There has been no review for the 0.11 release, or no documentation is available for public. http://download.eclipse.org/e4/downloads/drops/R-0.11-201106201631/index.html
(In reply to comment #7) > Here are the pointer I have for the last review (review of e4 0.9, where XWT is > active): > http://www.eclipse.org/project-slides/e4%200.9%20Release%20Review.pdf > > There has been no review for the 0.11 release, or no documentation is available > for public. > http://download.eclipse.org/e4/downloads/drops/R-0.11-201106201631/index.html Thanks. That helps. So there has been one release. That is probably not the version Papyrus wants to use, so e4 Incubator will need to decide if they want to do another release ... or, xwt move to papyrus! :) Or, maybe they did do one for 0.11 and its just not obvious.
(In reply to comment #8) > Or, maybe they did do one for 0.11 and its just not obvious. There was no e4 release in 2011. We had originally intended to do annual releases of e4, but then it was pointed out to us that Incubator Projects such as e4 should not have releases: http://www.eclipse.org/projects/dev_process/development_process_2011.php#4_9_Incubators Quote: "Incubator Projects never have releases; they do not require yearly continuation reviews and they are not part of the annual release train. " We did have an e4 0.9 release. I don't know if the dev process was changed after that, or we just didn't notice this rule when doing the 0.9 release. If XWT wants to do releases, it will need to graduate somewhere. Perhaps as a Technology sub-project?
(In reply to comment #9) > (In reply to comment #8) > > Quote: "Incubator Projects never have releases; they do not require yearly > continuation reviews and they are not part of the annual release train. " > Thanks for the history, John. All projects start off incubating, and I know they can have a pre-graduation review and release, but you are right, the "general purpose" Incubators are never intended to graduate and can not release components from there. I'd assumed that e4 was the former, since the "list of projects" lists both. e4 Project Eclipse Project Incubator http://www.eclipse.org/projects/listofprojects.php So, not sure what the difference between those two are, or maybe they are the same thing, just listed in two different ways? But, yes, sounds like the best way forward (for XWT and Papyrus) would be for XWT to graduate to their own project if they desire to release, so it would not be ambiguous.
(In reply to comment #10) > I'd assumed that e4 was the former, since the "list of projects" lists both. > > e4 Project > > Eclipse Project Incubator > > http://www.eclipse.org/projects/listofprojects.php > > So, not sure what the difference between those two are, or maybe they are the > same thing, just listed in two different ways? Getting off-topic, but this is one of those house-keeping things we've just never tidied up. The "Eclipse Project Incubator" exists only as a record in the Foundation database at this point. It has no source repositories. We intended to merge this into e4 but never went through the formal process (bug 330938). e4 is the Eclipse project perpetual incubator
To summarize what I think is the conclusion here: A project can not be in the Sim. Release, or Released at all, if they include things that are unreleased from other projects (and this is true of any release, not just Sim. Release). A project can include releases from other Eclipse projects, even if that other project is itself not part of the Simultaneous Release. This still requires the "other project's release" meets all the requirements for Release and Sim. Release ... signed jars, about.html file, etc. This is conceptually just like including a third party package from Orbit ... the original authors do not "participate" in the Release, but the bundles meet all the release requirements. Let me know if I have misunderstood or if there is further discussion required. Thanks.
Hi All, Soyatec has contributed XWT during 2 years. For us, it is a mature and only complete declarative solution for eclipse. We can continue working on it. And for sure, we'll use it in another project PMF to generate eclipse UI. Frankly speaking, I'm familiar with the Eclipse Project precess. Could someone help me to graduate XWT somewhere?
(In reply to comment #13) > Frankly speaking, I'm familiar with the Eclipse Project precess. Could someone > help me to graduate XWT somewhere? Sorry, I mean I'm NOT familiar with the Eclipse Project process.
(In reply to comment #14) > (In reply to comment #13) > > Frankly speaking, I'm familiar with the Eclipse Project precess. Could someone > > help me to graduate XWT somewhere? > > Sorry, I mean I'm NOT familiar with the Eclipse Project process. This could give some information: http://www.eclipse.org/projects/dev_process/development_process_2011.php#6_3_8_Restructuring_Review
Yves, I think the first step is to enter a bug against Eclipse Foundation > Community > Proposals and Reviews, stating the desire the graduate XWT. The key question is what destination project, but that can be discussed on the new bug.
Thanks John and Remi, Here is the Bug 373668.
To conclude, this was discussed at the Planning Council meeting on 3/7 and it was agreed the summary given in comment 12 was correct. http://wiki.eclipse.org/Planning_Council/March_07_2012#What_to_do_about_Papyrus_.28and_non_released_XWT_dependency.29 Just to help codify our group knowledge, I have also added a FAQ to wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ Specifically, http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Can_a_Simultaneous_Release_project_include_bundles_or_features_from_a_project_not_in_the_Simultaneous_Release.3F Sounds optimistic that Papyrus and XWT can "work something out" so the end result is as desired. Much thanks to all,
I have created a Bug 373708, to embedd XWT in Papyrus as a temporary solution.
