|
+1. I absolutely agree with you on that Mike. And part of my
hope is that forming smaller teams in the CDT focused on individual areas, we
can start building up this knowledge and start a culture of writing it down. As
you say, we won't fix this over night, but we should start. And my feeling from
some of the discussions on this list and the frustration I read in them, this
would be greatly appreciated by adopters and help immensely recruiting new
contributions.
Thansk!
Doug.
I just want to make a few comments regarding the concern that there is not
enough active contribution going on in CDT.
In my opinion one of the
biggest problems with CDT is that the codebase is overwhelmingly complex
combined with the fact that there is almost no developer documentation. This
is a very bad situation because potential interested contributors don't have
documentation to guide them and may be scared off by the complexity of CDT.
The fact that CDT is complex is probably unavoidable because C++ is a very
complex language, but that just means that documentation is even more
important for CDT to have.
I can say from personal experience that the
lack of docs is a real pain for new contributors, and serves as a huge barrier
to entry. When I first started working for IBM it took me a long time to get
even slightly comfortable working in the core. With no documentation to go on
I had no choice but to just dive into the code. I spent several months just
digging through piles of code and essentially reverse-engineering the core so
that I could understand how it works. This should not be necessary, and most
importantly a hobbyist would probably not do this.
Having good
developer documentation would encourage contributions. Potential contributors
would have a place to start learning how CDT works. CDT is actually a very
interesting piece of software to work on once you get comfortable with it.
Documentation would serve to spark interest, make people feel comfortable and
encourage contributions.
Now back to the question of introducing
processes. Adding new processes starting now is one thing, but we must also
consider that we have not had any processes for a very long time. Some areas
may have to be addressed retroactively. For example if we do add documentation
standards we cannot just simply start writing documentation for new features
that are added from now on, we must go back and document existing code to
bring it up to the standard. Weather people have the time and are willing to
do this is an open question. But I believe that documenting existing code can
only have a positive effect on encouraging new contributions.
Mike
Kucera
Software Developer
IBM Eclipse CDT
Team
mkucera@xxxxxxxxxx
 Chris
Recoskie---09/03/2008 10:36:59 AM---A few points, in no particular order: We
already have the system where in theory every individual committer has a veto
over any
From: |
Chris
Recoskie/Toronto/IBM@IBMCA |
To: |
"CDT General developers list."
<cdt-dev@xxxxxxxxxxx> |
Cc: |
"CDT
General developers list." <cdt-dev@xxxxxxxxxxx>,
cdt-dev-bounces@xxxxxxxxxxx |
Date: |
09/03/2008 10:36 AM |
Subject: |
Re: [cdt-dev] Should we (re)introduce
components in CDT |
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> | |
|
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
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
[attachment "pic10394.gif" deleted by Mike Kucera/Toronto/IBM]
_______________________________________________
cdt-dev mailing
list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
To