Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Should we (re)introduce components in CDT

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

I like the general idea behind your proposal and think it would improve quality and let Doug focus on project wide issues. Your component list is OK with me but how well it works in practice will be driven by the level of participation by the committers. I’m sure we can work this out if we can clearly define what the roles will involve and how they will combine into a team effort on CDT.

Thanks for getting this conversation started,

Ken


From: ext Pawel Piech <pawel.piech@xxxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Fri, 29 Aug 2008 11:43:50 -0700
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Should we (re)introduce components in CDT

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.

 
 
 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
 Sent: Thursday, August 28, 2008 7:38 PM
 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 <http://wiki.eclipse.org/CDT/calls/Aug0608>  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
  



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top