Another solution is to make p2 a project in of itself.
From: [email protected] [mailto:[email protected]] On Behalf Of Wayne Beaton Sent: December-06-12 1:02 PM To: [email protected] Subject: Re: [equinox-dev] Equinox Subprojects Is there real need to protect different functional areas within the project? 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? Wayne 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 project. 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 :) John From: Thomas Watson <[email protected]><mailto:[email protected]> To: Equinox development mailing list <[email protected]><mailto:[email protected]>, Date: 12/06/2012 08:38 AM Subject: Re: [equinox-dev] Equinox Subprojects Sent by: [email protected]<mailto:[email protected]> 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? Tom [Inactive hide details for Wayne Beaton ---12/05/2012 04:29:34 PM---I just noticed that some of the Equinox subprojects do not h]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 <[email protected]><mailto:[email protected]> To: [email protected]<mailto:[email protected]>, Date: 12/05/2012 04:29 PM Subject: [equinox-dev] Equinox Subprojects Sent by: [email protected]<mailto:[email protected]> 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? Thanks, Wayne [1] http://eclipse.org/projects/tools/status.php?cvs=0&git=0&svn=0&top=rt -- Wayne Beaton The Eclipse Foundation Twitter: @waynebeaton Explore Eclipse Projects <http://www.eclipse.org/projects> [EclipseCon 2013]<http://www.eclipsecon.org/2013>_______________________________________________ equinox-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Wayne Beaton The Eclipse Foundation Twitter: @waynebeaton Explore Eclipse Projects<http://www.eclipse.org/projects> [EclipseCon 2013]<http://www.eclipsecon.org/2013>
<<inline: image001.gif>>
<<inline: image002.png>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
