For what reason are some committers restricted from some parts of the
code?
The Eclipse top-level project is big and covers a large amount of code
which requires quite different knowledge. A JDT committer does not know
about PDE and the other way around. Therefore commit rights need to be
earned separately. Yes, of course one could manage that via social
convention/control but the question is what causes more overhead to the
(component) leads.
Dani
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Wayne Beaton
<wayne@xxxxxxxxxxx>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|eclipse-pmc@xxxxxxxxxxx
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|21.07.2010
20:14
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [eclipse-pmc] A request to decouple ACL for core
components
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
As Boris suggests, there is a great deal of back-and-forth created by
the current structure, resulting in confusion for the webmasters,
committers, and the community.
I'd like you to seriously consider this as an opportunity to simplify.
We have been working over the past few years to reduce the number of
UNIX groups for each project. In fact, we intend to work toward a state
where we have exactly one UNIX group per project. FWIW, collapsing your
group structure does not require any kind of community review; you can
just work with the webmaster to get it done.
The CDT project has, for example, been very successful in collapsing
their group structure into a single group and managing finer-grained
access using social convention. Many other projects have had similar
success.
I'm curious to understand the "new committers usually end up in most but
not all of these groups" part. For what reason are some committers
restricted from some parts of the code?
Thanks,
Wayne
Boris Bokowski wrote:
If we go ahead with the required project creations/moves/removals
(most of which would be to merge a number of existing unix groups),
would it make sense to merge other Unix groups at the same time?
Just to be clear, I don't want to complicate things and would be fine
with just doing what's necessary to do the split suggested by Szymon.
But I am wondering if this may be a good opportunity to merge all of
(plat-ui-home, plat-rcp, plat-ui-nav, plat-jfaces, plat-ui-bindings,
plat-ui-present, plat-ui-tabbed, carbon-ui) into plat-ui. All these
groups exist only for historical reasons, and new committers usually
end up in most but not all of these groups, leading to unnecessary
back-and-forth between the new committers, myself, the PMC, and the
webmaster.
Boris
On Wed, Jul 21, 2010 at 1:08 PM, John Arthorne
<John_Arthorne@xxxxxxxxxx <mailto:John_Arthorne@xxxxxxxxxx>> wrote:
Thinking more about this, I believe this will be a fairly
complicated change. I suggest that Szymon write up a wiki page or
similar describing the proposed changes in detail, and we can all
review it before asking the foundation to make the changes. There
are currently the following ACL's on eclipse.org
<http://eclipse.org> related to platform core: plat-core,
plat-testsboot, plat-core-mac, plat-core-photon, plat-rel-core,
plat-core-hpux, core-variables. We need to know what the new
groups are called (probably eclipse.platform.runtime and
eclipse.plaform.resources), and what projects map to each ACL.
Hopefully we can completely replace the seven existing ACL's with
just two. From the Foundation perspective this is effectively a
set of project creations/moves/removals but hopefully we can do it
without too much process overhead.
*Daniel Megert <daniel_megert@xxxxxxxxxx
<mailto:daniel_megert@xxxxxxxxxx>>*
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
<mailto:eclipse-pmc-bounces@xxxxxxxxxxx>
07/21/2010 12:18 PM
Please respond to
eclipse-pmc@xxxxxxxxxxx <mailto:eclipse-pmc@xxxxxxxxxxx>
To
"eclipse-pmc@xxxxxxxxxxx
<mailto:eclipse-pmc@xxxxxxxxxxx
"
<eclipse-pmc@xxxxxxxxxxx <mailto:eclipse-pmc@xxxxxxxxxxx>>
cc
Subject
re: [eclipse-pmc] A request to decouple ACL for core
components
We discussed this today in the PMC call and approve this change.
Please
file a bug to request the new groups along with their members.
Dani
>I think that due to recent committer nominations in the core
components,
it
>would make sense to split the commit groups
>to better match the reality.
>
>There should be at least split into core.resources and core.runtime.
>
>Thanks
>--
>Szymon Brandys
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx <mailto:eclipse-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx <mailto:eclipse-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
------------------------------------------------------------------------
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
--
Wayne Beaton, The Eclipse Foundation
http://www.eclipse.org
--
Join me at Eclipse Summit Europe 2010!
http://eclipsesummit.org/
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc