[
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 agree in principle with what you are saying. I just
think we need to take the reality of the situation into account.
We have lots of room on the agenda to figure out how we want to
organize. We need to keep the big picture in mind and do what's best to ensure
the quality and functionality and volume of contributions to the CDT
continue to improve and grow.
Cheers,
Doug
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
