Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:MDT/Papyrus-Proposal"
| Line 18: | Line 18: | ||
* [Kenn] These seem more like features than components. There should be one roadmap into which the plans for each of these features will fit... | * [Kenn] These seem more like features than components. There should be one roadmap into which the plans for each of these features will fit... | ||
| − | + | ||
* [raphaël] in that case those would be really huge features ;-) the backbone, for instance, will provide multi-editor layout, multi-diagrams model, collaborative work support... | * [raphaël] in that case those would be really huge features ;-) the backbone, for instance, will provide multi-editor layout, multi-diagrams model, collaborative work support... | ||
The idea of presenting those "large features" as components is based on two ideas : parallel work and modularity. By creating them as components we ensure that there be one leader and one roadmap for each, in addition to an integration planning to reach the global tool level. With such a structure, it gives immediately the rules of efficient parallel work (different teams can work on different components at the same time when interfaces are clearly defined) and promotes modularity through potential reuse of each group of features. | The idea of presenting those "large features" as components is based on two ideas : parallel work and modularity. By creating them as components we ensure that there be one leader and one roadmap for each, in addition to an integration planning to reach the global tool level. With such a structure, it gives immediately the rules of efficient parallel work (different teams can work on different components at the same time when interfaces are clearly defined) and promotes modularity through potential reuse of each group of features. | ||
* [Kenn] OK, that makes sense, then. There are no restrictions on how the functionality/code within a project/component is organized - we should impose whatever structure makes sense. Currently, only projects and sub-projects are officially recognized at Eclipse (components are "second class" entities), but if/when the proposed changes to the development process are approved (see http://www.eclipse.org/projects/dev_process/development_process.php#), nesting of projects (each with its own leadership and associated list of committers) can take place at any level... | * [Kenn] OK, that makes sense, then. There are no restrictions on how the functionality/code within a project/component is organized - we should impose whatever structure makes sense. Currently, only projects and sub-projects are officially recognized at Eclipse (components are "second class" entities), but if/when the proposed changes to the development process are approved (see http://www.eclipse.org/projects/dev_process/development_process.php#), nesting of projects (each with its own leadership and associated list of committers) can take place at any level... | ||
| + | |||
| + | * [raphaël] commitee and initial committers | ||
| + | The idea of a Project Management Committee was a way to give special representation to the parties the most involved in development and in specification of the tool through initial and future contributions. | ||
| + | As PMC is reserved for high level project it can not be used in our case and we have to rely on the committer vote to provide representation. It seems we have two options : | ||
| + | a) minimalist list of initial committers : each party investing at least 2 FTE could have one initial committer. Parties with at least 3 FTE would have two committers (CEA for instance). This option strongly limits the number of initial committers (probably 4 or 5) and so gives a better start for the project (easier to ensure coherency and good-quality commits if there are a few committers). After some months, other committers could be promoted through the Eclipse well-known meritocracy process. | ||
| + | b) Open list of intitial committers : each party could have one initial commiter for each FTE provided (with a limitation of 3 initial committers by party). According to the first estimation of efforts provided by the different interested parties, this second option would lead to 6 to 9 committers. | ||
| + | |||
| + | My preference is for option a)... | ||
Revision as of 10:18, 22 April 2008
- Precise the content of the initial contribution
- Refine the component architecture
- Choose an organization and a leader: a kind of PMC + one leader ? Due to the relative investment of the developers (to be detailed ?), I suggest to choose Sébastien to lead the component, with the other candidates in this committee.
- Detail the planning
- Change "project" into "component"
- [Kenn] : I’ll take a closer look at the proposal soon, but in the meantime note that we need to more consistently use “component” instead of “project”, and that we should identify one lead for this component (instead of two or three).
- [raphaël] : in fact we need 5 components and two levels.
Papyrus is the UML tool and the final deliverable for UML end users (higl level component with a dedicated roadmap) Papyrus is composed of several lower-level components (each of them having a roadmap):
a) backbone (the diagram container) with an API to integrate diagrams into, b) MTD diagram adaptor : a layer on top of MDT diagrams to make them conform to the backbone API c) other UML diagrams outside of MDT : contributions of other diagrams that will be developed directly in Papyrus Eclipse component d) facilities (EMFCompare, outline, properties...) : all things to integrate to have full-featured tool e) XMIDI reference implementation, with import and export commands.
- [Kenn] These seem more like features than components. There should be one roadmap into which the plans for each of these features will fit...
- [raphaël] in that case those would be really huge features ;-) the backbone, for instance, will provide multi-editor layout, multi-diagrams model, collaborative work support...
The idea of presenting those "large features" as components is based on two ideas : parallel work and modularity. By creating them as components we ensure that there be one leader and one roadmap for each, in addition to an integration planning to reach the global tool level. With such a structure, it gives immediately the rules of efficient parallel work (different teams can work on different components at the same time when interfaces are clearly defined) and promotes modularity through potential reuse of each group of features.
- [Kenn] OK, that makes sense, then. There are no restrictions on how the functionality/code within a project/component is organized - we should impose whatever structure makes sense. Currently, only projects and sub-projects are officially recognized at Eclipse (components are "second class" entities), but if/when the proposed changes to the development process are approved (see http://www.eclipse.org/projects/dev_process/development_process.php#), nesting of projects (each with its own leadership and associated list of committers) can take place at any level...
- [raphaël] commitee and initial committers
The idea of a Project Management Committee was a way to give special representation to the parties the most involved in development and in specification of the tool through initial and future contributions. As PMC is reserved for high level project it can not be used in our case and we have to rely on the committer vote to provide representation. It seems we have two options :
a) minimalist list of initial committers : each party investing at least 2 FTE could have one initial committer. Parties with at least 3 FTE would have two committers (CEA for instance). This option strongly limits the number of initial committers (probably 4 or 5) and so gives a better start for the project (easier to ensure coherency and good-quality commits if there are a few committers). After some months, other committers could be promoted through the Eclipse well-known meritocracy process. b) Open list of intitial committers : each party could have one initial commiter for each FTE provided (with a limitation of 3 initial committers by party). According to the first estimation of efforts provided by the different interested parties, this second option would lead to 6 to 9 committers.
My preference is for option a)...