Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Projects releasing other projects unreleased code .... ?

We actually build the bundles in question as part of the EMF build but don't intended for them to be installed from a repository (instead, their source is embedded in the examples installer, to be extracted as projects into a user's workspace). The bundles are in fact available in the EMF repository, so I'm not sure why they couldn't be consumed from there by AMP.

The about.html files have been in place in the EMF codebase all along. The reason they didn't appear in the aggregated bundles must have to do with a difference in the AMP build. There are other subtle differences with the way these bundles are built by EMF and AMP (e.g., the way the qualifiers are generated) which suggests another potential concern with code being redistributed by another project...

Kenn

On Thu, Jun 9, 2011 at 9:25 AM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
This isn't explicitly covered by the EDP. In practice, however, this is generally considered acceptable.

If the project is copying the code from another project's repository into their own repository, then a fork has occurred, and the IP team needs to be informed (primarily for tracking purposes). In a general sense, projects are permitted to take the output from other projects and include it in their own distributions. If the project they are consuming is in the incubation phase (does not apply here), then they are obligated to include incubation branding in their own downloads.

FWIW, almost every project distributes something from another project at some level or another.

There is no formal requirement to call this out in release review documentation. But that would definitely be nice to see.

As for responsibilities, I respectfully suggest that AMP and EMF share responsibility to resolve the issues. I include AMP in this because they have taken on code with no implicit warranty (this is based on assumptions stemming from the statement that "it wasn't available from EMF"). I include EMF because, well, it's their code. It seems to me that a patch submitted to EMF by the AMP team should clear an "about files" problem up pretty quickly.

Hopefully this doesn't turn into one of those hard lessons. If, ultimately, EMF cannot provide the necessary assistance to resolve issues, AMP is left with the responsibility. A project not shipping pieces of their code is a huge red flag for consumers. Early and ongoing communication is important in this sort of situation.

In terms of detection, there's only so much that we can do. We depend very heavily on committers and project leads to do the right thing (and provide assistance where we can).

HTH,

Wayne




On 06/09/2011 08:44 AM, David M Williams wrote:
I find something disconcerting about one project releasing another project's (otherwise unreleased) code. Beside these e4 cases, Miles recently explained AMP is releasing o.e.emf.java.

" We use..emf.java to do Java->AMF M2M mapping because it provides a good working ecore model for  arbitrary Java. (We should probably move to MoDisco or something at some point.) We needed to build it because it wasn't available from EMF. "

Don't get me wrong ... on one level it's "cool". Good to see code being (re) used. But it does seem to raise some questions. How's this covered by EDP? How is it called out in Release Review documentation? Who is "responsible" for the code, doing the CQ/IP work? ... for example, this case of missing "about.html" files is normally a stop ship problem ... who's to fix it now? What kind of project-to-project communication should go on? Must go on?  Sounds like there was none (until just now) for these two cases. Plus, these two cases came to our attention because there were some routine, "easy to spot" issues. I wonder .... how much does this go on and its just never really known about? How would we normally "detect" it?

I'm not saying there is a problem that has to be solved right now. But seems long term there should be some guidelines created to improve communication and be explicit about expectations. Some of this might covered in this process bug?

Bug 331397 - EDP should say more about project namespaces

Or, maybe its just me that's surprised by this and all the right people already do know what's going on ... in which case, never mind me.






From:         Mariot Chauvin <mariot.chauvin@xxxxxxx>
To:         cross-project-issues-dev@xxxxxxxxxxx
Date:         06/09/2011 08:12 AM
Subject:         Re: [cross-project-issues-dev] aggregation builds have been turned off
Sent by:         cross-project-issues-dev-bounces@xxxxxxxxxxx



They are redistributed by papyrus, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=347239#c10


Le 09/06/2011 12:33, Paul Webster a écrit :
On Thu, Jun 9, 2011 at 3:39 AM, David M Williams < david_williams@xxxxxxxxxx > wrote:
Missing about.html in file: org.eclipse.e4.xwt.pde_0.9.1.v20101119-0800.jar
Missing about.html in file: org.eclipse.e4.xwt_0.9.1.v20101119-0800.jar


I've opened a bug for these, but we don't plan to look at it until Juno.   I'm not even sure why they're in the release repo as e4 and XWT are not in the release train.

Bug 348742 - Missing about.html

--
Paul Webster
Hi floor.  Make me a sammich! - GIR


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



Back to the top