Thanks, Pawel, I'll give my two cents here and explain my
position. From our discussions on the CDT call last month, it felt like we
were close to concensus already and we can talk a bit more about it at next
week's call and get even closer.
From my standpoint, I'm looking for one thing mainly, help
with the project managament aspects of running the CDT. As I'm sure you're
aware, I've been pretty busy on other things, particularly in relation to the
platform (p2 internal and external and the upcoming e4 IResource work). And I
have a keen interest in cleaning up the CDT build system. As such, I don't think
I can do the project management side of things justice, particularly as the CDT
is entering a new maturity level and the need for quality is becoming more
important over functionality. I think my help is needed more on the architecture
side of things to clean up the remaining issues we have with CDT
usability.
I'm very much infavor of componentization at this time because
of this. The component leads would help me make sure we drive quality in what we
do. Creating a PMC for the CDT is about sharing that burden amongst more people.
So, yes, I really want to see this happen.
The mechanics of the componentization is going to be tricky. A
lot of it depends on what kind of development we have planned for the future.
What peices are going into maintenance mode, what peices still need some heavy
development effort, what new pieces are coming along? Setting up a component
that only has a couple of people working part time isn't very valuable so I
think there is a practical lower limit on things.
The other thing to take into account is that by my
measurements, we are again on the decline on contributions to the CDT. There
really aren't any new prospective committers on the horizon at this time, and
the volume of contribution from some of the existing committers is declining.
There's nothing wrong with that and it is a sign that the CDT has very
much matured and we're in good shape. But we do need to take that into
account.
I know Pawel's main concern is to
ensure DSF is allowed to continue with its quality processes. I honestly think
that can be done without componentization. And I'd like all
of the CDT committers to take a look at what they are doing. I think we should
all be following these guidelines. And to be honest, I hear we're all open to
this kind of thing anyway, it just needs someone to drive it. And to me that's
where componentization comes in, to have leaders who can drive this better than
I can.
So the conclusion that I come to is that I think we'd be fine
with two components: Debug and Core. Debug is pretty obvious and includes the
new DSF work where I believe most of the churn will be over the next couple of
years. The Core component is pretty much everything else with the Build
rearchitecture work being the biggest churn area (trust me, we've learned our
lessons from the last one). I've always felt build should be part of the core as
it was originally and I want to relate this work to the e4 resources work I'll
also be doing.
How we decide who the component leads are can wait until we
decide what the components are. Eclipse tradition is for PMC members to be
selected, not elected, and I think we'll do that here. But I would very much
appreciate advice you may have on candidates. Feel free to share your opinions
privately with me.
This is a great discussion, please keep it
going.
Cheers,
Doug.
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
|