[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Should we (re)introduce components in CDT
|
+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.
________________________________
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mike Kucera
Sent: Wednesday, September 03, 2008 1:56 PM
To: CDT General developers list.
Cc: CDT General developers list.; cdt-dev-bounces@xxxxxxxxxxx
Subject: Re: [cdt-dev] Should we (re)introduce components in CDT
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 <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 <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
<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
