Re: [eclipse.org-architecture-council] Things Committers should know

[Wayne Beaton <wayne@xxxxxxxxxxx>]

Comments inline.

Oberhuber, Martin wrote:
> Hi Wayne,
>
>   
> >  Links to non-eclipse.org content
> >     
>
> Great posting!
>
> Could you add a hyperlink into the devprocess or wiki where
> the original reference text of that requirement is to be found?
>
>   
Nope. AFAIK, this isn't captured anywhere.
> >  Component == Project
> >     
>
> I apologize for not reading all the dev.process for this, but
> some things of what you write here seem odd and/or may need some
> more clarification:
>
> 1. To what extent is the new model executed already? At least
>    from the Platform I know there's tons of components.
>   
Well... the entry comes from my own recent experience with the Examples 
project. I had originally intended for each example to be it's own 
component, but the development process now makes that too heavyweight.  
This is the reason why I innovated the "Project Flattening Review" that 
just passed.
> 2. How does an existing project (==leaf node) add a new subproject
>    or turn an existing component into a project? Looks like that
>    would turn it into a container thus making its existing content
>    void? What's the turnaround time for the project proposal?
>    Is there a streamlined process for the existing component -> 
>    project case? Where do I turn to asking such questions?
>   
If you add a subproject to a leaf node, then the leaf node has to become 
a container. The existing code in the leaf node would have to be moved 
to a new subproject. So... when you create that first subproject, you 
actually end up making two subprojects. You can do that one operation 
with a single review.

The subproject creation process is the same as the project creation 
process. You start by creating a proposal, which needs to indicate 
committers, mentors, scope, etc. It is made available to the community 
for a time (3 weeks minimum), and then a creation review occurs. Like I 
said, you can include some additional project refactoring as part of the 
proposal/review.
> 3. This message seems to apply to project leads only, does it 
>    actually make sense to send that under the "committers should
>    know" label?
>   
I think committers should know a little something about this stuff.
> Thanks,
> Martin
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
>