[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-pmc] A request to decouple ACL for core components

"Projects" embody the social and functional structure that we want to have.  Release reviews, approvals process, etc. So it might be that we have too many groups or too few projects.  If projects are cast too broadly then, for example, project leadership has a hard time knowing all the details of what should be approved etc.  Too fine and projects are one or two people and the community aspect is lost.  So the challenge is to get the granularity right so the group and the leadership can be effective.

Social convention can get us a long way and simplification is good.  If we are worried about a committer in some other related area coming along and damaging a different area then we likely should reconsider our committer strategy.

Having said that, there has to be a middle ground otherwise we would reduce this to "Eclipse Committer" and people would get rights across all of Eclipse.

We should strike some middle ground where we *end up* with perhaps a handful of groups in Platform. 

For JDT, it is not clear (to me at least) that there is that much between Core and UI that they need separate groups.

Similarly for PDE.

Jeff

On 2010-07-22, at 9:52 AM, Wayne Beaton wrote:

> Hi Dani.
> 
> I think that you misunderstand me.
> 
> The Eclipse Platform project currently has (I believe) seven different UNIX groups. It's these groups that I believe can be collapsed into a single group with social conventions controlling who mucks around with what within that single project. JDT, PDE, Platform, ... will all remain separate projects with separate committer groups.
> 
> HTH,
> 
> Wayne
> 
> 
> Daniel Megert wrote:
>>> 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
>> 
> 
> -- 
> 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