Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Things Committers should know 
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.

Back to the top