[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Should we (re)introduce components in CDT
|
Pawel, your proposal seems sound to me. I have no concerns or
recommendations. There are details missing (e.g., is a unanimous vote in
the PMC required to carry out a veto, or just majority? What implications
does this have for Doug's role? Will each component have its own WIKI
page, where component-specific processes will be documented? I would
imagine so.). But as a starting point, I think this is a good
plan.
John
At 06:38 PM 8/28/2008, you wrote:
Hi All,
This email is a follow up to the discussion we started at the
last CDT conference
call meeting. At this meeting I proposed that CDT project
should introduce some level of componentization as a prerequisite to
migrating the DSF framework and GDB implementation from Device Debugging
into the CDT project. My idea was pretty simple: carve up CDT into
logical components where each component can designate a leader and agree
on its own set of required processes. This way if we brought in DSF
into CDT we could maintain the planning/bug fixing/testing processes that
we worked hard to create. Unfortunately, it seems that CDT
participation is heavily lopsided towards one component, also the CDT
architecture does not make a clean separation between components with the
clear exception of Debug.
Non the less, I still believe that defining some form of components and a
leadership structure would help the CDT establish better process that
many people have expressed a desire for. So my revised proposal for
CDT components is the following:
1) Define an initial flat list components that follow the architectural
separation in the code today, which as I understand it would result
in:
- a) Core - including: project managment, build, as well as
editor.
- b) Searching/Indexing
- c) Debug - including CDI, stanandard debug model implementation,
launch, and UI
- d) CDI-GDB
If we all agree to contribute DSF to CDT we would create additional
components
- e) DSF
- f) DSF-GDB
If there is a need and as architecture permits, existing components
could be split further. but the new components would still need to
meet a certain level of autonomy.
2) What components would and would not be:
- a) It should be wholly contained in one or more plugins. I.e.
components should not share plugins.
- b) It would optionally have a leader who's role would be to document
and enforce the process of that component.
- A component leader would NOT have any kind of a veto power over code
commits or changes to the component process, that would be the role of
the PMC.
- c) It would define a plan for that component which would be pulled
into the project plan for CDT.
- d) It would maintain a list of "new and improved" which
would also be pulled into the overall CDT new and improved.
- e) It would optionally define a process for assigning, fixing, and
verifying bugs
- f) It would optionally have a test plan such as information of
automatic test coverage, procedures for manutal tests, a sign up list for
milestone tests, etc.
- g) It would NOT have a restricted list of committers. I.e. any
CDT committers could commit changes to any CDT component.
3) Create a CDT PMC
The PMC would be made up of any component leaders plus any other
committers elected into the PMC. As mentioned above, the PMC would
have veto power over commits and process changes in any component, which
would dilute the power of any component leader. The PMC's role
would also be to enforce API and feature freezes, and approve checkins
during ramp down.... which I guess is pretty much standard in other
projects.
We still have about three weeks until the CDT summit. If by then we
could reach some kind of consensus on a CDT component strategy, including
who would like to contribute their time to lead a component, it would
make the CDT Summit a whole lot more productive for everyone
involved.
-Pawel
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev