Thank you Doug for the positive feedback and encouragement. I wonder
if you could expand more on why you prefer to keep just two components
rather than having more granular components as I suggested.
>From my point of view: if we were to bring in DSF and DSF-GDB as
individual components, we could do it immediately and essentially at no
cost because the processes and the culture of following them are
already established. If, on the other hand, I we were to bring DSF and
DSF-GDB into a larger Debug component, we would need a long discussion
in agreeing among all committers on how development should be done, and
then we would need an adjustment period in which the new process is
implemented. All this would require considerable effort and time,
which as a volunteer-based organization we're not guaranteed to have.
Also, it's worth pointing out that even within Device Debugging project
DSF and DSF-GDB are separate components along with memory rendering and
IP-XACT editor. While DSF-GDB and DSF follow pretty much the same
process, other components in DD mostly do not.
Another thought that occured to me while reading your post is that
another thing that would be very useful to require of components would
be just a metric of what process is being done by what component. Then
a simple table could be produced with each release that woudl indicate
for example: what was tested (what was not_, which component time to
reviewed and verified bugs, which component followed the ramp-down
policy, etc. Such a requirement would help create some immediate
results out of this componentization effort.
Cheers,
Pawel
Schaefer, Doug wrote:
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
