Re: [cdt-dev] Should we (re)introduce components in CDT

[Chris Recoskie <recoskie@xxxxxxxxxx>]

A few points, in no particular order:

• We already have the system where in theory every individual committer has a veto over any changes, so assuming your PMC is made up of committers, they do have a veto.
• Should indexing really be a separate component from the rest of core? It is pretty intimitely threaded throughout the other features. Although admittedly, if you don't split it out, under the remains of your proposal you are left with esstentially Debug and Not-Debug, which is probably not granular enough.
  • As another point to keep in mind, factoring out the indexer into its own plugin (to meet your criteria that plugins do not overlap) would make for a lot of API churn. Not saying it can't be done, but it's a significant issue that would have to be kept in mind, as there are many clients using these interfaces.
• There is already a certain amount of "keep your toys out of my sandbox" behaviour that happens as is. We have to be careful to make sure our process doesn't encourage this further. We want components, not empires.
• While I support the concept in theory, I think in practice it's going to fall down
  • The components that would most benefit by the addition of some process are generally in that state because the people working on those components eschew processes. If we are going to rely on those components to self organize and adopt a process then we are probably in for disappointment.
  • Time, as Mikhail has already brought up. While all of the activities you list are important and I agree that things would be better if they were done, it more or less assumes that someone is going to devote enough of their time to do them. Given people could already be doing these activities now, I doubt anything is going to magically change that will suddenly convince them (or their managers) to start spending time on these activities, especially when most people are part-time.
  • Accountability. If there is no reporting structure between a committer and their component lead, there is no real way for them to enforce bug assignments, or any other part of the process. The committer can always say no. What's the recourse if that happens? Should there even be a recourse?

I am not trying to rain on the parade here. I agree with your plan, so don't misread me. We need this. I'm trying to be realistic here though. I'm not sure it can be pulled off.

I will make some bold statements here and not pull any punches, which may irk people, but some of this needs to be said IMHO. Our history of poor process has significantly hurt development and adoption of CDT. While CDT has a very diverse committer community, for which we are rightly applauded, our process is a train wreck compared to many other Eclipse projects. Much of even the most basic software development and software engineering process does not happen (or perhaps some of them do, but not in public, e.g. testing), and as a result, a lot of things fall through the cracks. I am not trying to preach from an ivory tower here as I fully acknowledge that I am not without sin either. In any case, despite our shortcomings, it is not to say that a lot of good work is not also done either, and I don't want to take away from that. But, with every release it is becoming harder for people to consume CDT, and harder to contribute and coordinate efforts in any meaningful way. If we don't start enacting some process to help support it, CDT is going to eventually collapse under its own weight.
===========================

Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt

Pawel Piech <pawel.piech@xxxxxxxxxxxxx>

Pawel Piech <pawel.piech@xxxxxxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

08/28/2008 07:38 PM

Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

To	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev