I agree with the proposed process in
general, it seems to be the way to go. Here are my 2 cents (or pennies,
whichever currency you prefer)
The hierarchy of components should follow the
simple rule: from generic to more specific. For instance, the
following would be the ideal structure for Debug
(I understand it would require some serious efforts to implement
it):
Common core and UI: used by all debug models, includes
support for generic breakpoints, common views and menu actions, common
launch configuration parts
Model level components:
standard model/CDI, DSF, etc
Implementation
level components: CDI/GDB, DSF/GDB, etc
The proposal to have a PMC and component leaders is
very good, but it would take a lot of time from the persons involved. Is it
realistic to expect this type of commitment from companies? The first
step would be to find out who is committed to take these
roles.
Regards,
Mikhail
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel
Piech Sent: Friday, August 29, 2008 12:38 AM To: CDT General
developers list. Subject: [cdt-dev] Should we (re)introduce components
in CDT
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
|