[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Equinox Subprojects

The different RT projects actually operate as separate projects. Virgo, for example, has its builds, downloads, website, etc.

The Equinox subprojects, however, do not operate as  separate projects. They operate as ACLs. p2 is a bit of an exception, but still leverages much from the parent project (which is fine).

I would like to kill off the inactive project in the short term it appears to provide no value.

I would like to kill off the "website" project as it's existence is an ugly hack that is a bogus project that skews our numbers. However, there's no particular urgency to do this. I'm keen to help sort out a reasonable alternative.

I'm sceptical of the value of the other subprojects (besides p2 and the incubator). But I leave it the project and PMC discretion to decide what to do.

There is no urgency on my part to split p2 from Equinox. Since p2 depends on Equinox for builds and downloads, the split does represent some work. I leave it to the parties involved to decide if it is worth the investment.


On 12/06/2012 03:37 PM, John Arthorne wrote:
By this kind of argument one could argue all of RT should only have one 
committer group and we use social conventions to avoid writing in the 
wrong area. Personally I see p2 and Equinox framework as quite different 
projects. Equinox framework is agnostic of what provisioning technology is 
used to install it, and it has no knowledge or dependency on p2. Similarly 
p2 could be used to provision other OSGi implementations of even non-OSGi 
applications. The two projects have no overlap in active committers that I 
can think of. They share a website repository but have separate web sites. 
I really don't see any violation of the spirit of the EDP in having them 
as separate projects. Just my $0.02...


From:   Wayne Beaton <wayne@xxxxxxxxxxx>
To:     equinox-dev@xxxxxxxxxxx, 
Date:   12/06/2012 01:02 PM
Subject:        Re: [equinox-dev] Equinox Subprojects
Sent by:        equinox-dev-bounces@xxxxxxxxxxx

Is there real need to protect different functional areas within the 

Is there danger that a "website" committer might start hacking p2 code?

I'm having trouble understanding why subprojects are required at all. 
Equinox builds and releases as a single thing. There is a single website. 
All of the subproject repositories are in a single location. The only 
reason that I can think of to have subprojects is so that you can have 
ACLs against different functional areas within the same project. While 
this may align with the wording of the EDP, I think that it violates the 
spirit of it.

Is there any reason why we can't just collapse *all* of the Equinox 
subprojects into the parent and be be left with rt.equinox?

The CDT project, for example, does this. They have one set of committers. 
Within the project they manage who accesses what by social convention 
rather than enforced access control. Is there valid concern that we need 
to keep p2 committers from touching framework stuff?

Collapsing would solve the website problem, wouldn't it?


On 12/06/2012 10:00 AM, John Arthorne wrote: 
+1 on terminating rt.equinox.security. Effectively we did this during the 
Git migration and forgot to do the full process. 

I don't care either way about combining bundles+framework. They do have 
fairly distinct committer lists and they seem to be functioning fine in 
their current form. On the other hand I would trust all the committers to 
only work in their area of expertise so I have nothing against combining 
them. I tend to agree with Wayne that effectively they operate as a single 

On the website, the other big issue is that the Equinox download directory 
is owned by the website project. So between the downloads and web sites I 
do think all the Equinox committers need to have commit rights. Whether 
that is done via a separate project or ACL magic from the webmasters like 
Platform does, I don't mind either way.  When dealing with several 
different directories I tend to think the ACL approach would be a pain to 
manage. Looking at the members of the website ACL, it does look in need of 
some cleanup at least - even McQ is a committer there :) 


From:         Thomas Watson <tjwatson@xxxxxxxxxx> 
To:         Equinox development mailing list <equinox-dev@xxxxxxxxxxx>, 
Date:         12/06/2012 08:38 AM 
Subject:         Re: [equinox-dev] Equinox Subprojects 
Sent by:         equinox-dev-bounces@xxxxxxxxxxx 

rt.equinox.security should have been roled up into rt.equinox.bundles.  At 
least we moved all the security code into the rt.equinox.bundles 
repository and have one commit group for that repository.  So technically 
it is a candidate for termination, but the code did not go away. 

Personally I would be fine with combining rt.equinox.bundles and 
rt.equinox.framework into one project under rt.equinox and leaving 
rt.equinox.p2 as the sole subproject.  This means all rt.equinox.bundles 
committers would gain commit rights to the rt.equinox.framework repo and 
vise-versa.  I'm not sure what to do about rt.equinox.website project.  If 
you have an easy way to also combine it into rt.equinox then that is fine. 
 But we must allow rt.equinox.p2 committers to still have access to the 
web site repository. 

Others have opinions?


Wayne Beaton ---12/05/2012 04:29:34 PM---I just noticed that some of the 
Equinox subprojects do not have any source repositories listed [1]. 

From: Wayne Beaton <wayne@xxxxxxxxxxx> 
To: equinox-dev@xxxxxxxxxxx, 
Date: 12/05/2012 04:29 PM 
Subject: [equinox-dev] Equinox Subprojects 
Sent by: equinox-dev-bounces@xxxxxxxxxxx 

I just noticed that some of the Equinox subprojects do not have any source 
repositories listed [1]. In fact, most of them have no metadata specified 
at all.

Further, upon inspection, it appears that the rt.equinox.security project 
has no resources associated with it (no Git repository, no downloads that 
I can detect, no website). Is this project still viable, or is it a 
candidate for termination?

The rt.equinox.website project is a hold over from the bad-old-days. Is 
that project still required? Can we kill it and assign the website 
repository to rt.equinox?

Is it still valuable to have Equinox subprojects at all? Based on the use 
of the projects, it seems that the only purpose is to keep the committer 
lists distinct. Is this still necessary? AFAICT, only rt.equinox.p2 seems 
to be operating as a separate project. Does it make sense to consider 
rolling the rest of the projects up into the parent?



[1] http://eclipse.org/projects/tools/status.php?cvs=0&git=0&svn=0&top=rt 
_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev

Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects

PNG image