[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] CDT 3.0 Closing
|
I absolutely agree with Chris. We definitely need better planning.
Plus, our testing is not sufficient (James is doing a great job, but he's
alone), major issues may come up during the first trials by users.
----- Original Message -----
From: "Recoskie, Chris" <crecoskie@xxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Sent: Friday, July 22, 2005 10:47 AM
Subject: RE: [cdt-dev] CDT 3.0 Closing
I agree with David. Some more active triage would be good. It's a bit
hard to organize on a consistent basis though since the ownace is on all
of us to just do it, and there's no devoted CDT project manager hounding
us for it.
I think part of the problem though is separate. We seem to have a real
problem of not stepping up and saying when the Emperor has no clothes,
i.e. when the plan is too vague or not realistic. For instance, when we
started CDT 3.0 I don't think any of us truly thought that there was a
hope of sticking to the original delta from the Eclipse 3.1 release, and
predictably we moved the date later on. By a similar token, I don't
think any of us believe that we're going to have all the bugs shaken out
(and fixed!) by next Wednesday's build. By another similar token, do we
actually think that we all are going to have the time to properly revamp
the docs for the final build two weeks after that?
Not saying I have the magic answers to everything either, but I think
right now we're sort of kidding ourselves, so if we can all just come
out and admit it maybe we can try to do something about it.
___________________________________________
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
_____
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of David Daoust
Sent: Friday, July 22, 2005 9:44 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] CDT 3.0 Closing
<soapbox>
I wouldn't suggest that we let the release go with major defects.
However, I would go so far as to suggest that we modify our behaviors so
we fix the defects (or decide that they are unimportant) before the
agreed upon date, or make a call early in the RC cycle saying that we
need to re-evaluate the date.
I agree that the committers will decide the dates, however, It is
difficult to proceed if some committers are working towards different
dates than others.
There is a wider community that takes our published dates and makes
plans around them. These plans may include just taking the CDT
unchanged, or they may include scheduling a snapshot + fixes + testing.
Either way, when we are sloppy on our dates, we negatively affect
others.
We cannot control the defects that will be raised between now and GA,
but we should be able to deal with the existing ones. We currently
have a number of defects open on 3.0 -- at this point in time everybody
who looks in bugzilla should assume that EVERY one of these defects will
be fixed. When I look at the list, common sense tells me that some of
them are not as important as others. We should move these off. (If my
assessment is correct -- which is a big if).
This is the list that I believe should not gate the release:
ID
Sev
Pri
Assignee
Status
TargetM
Summary
30365 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=30365>
nor
P3
alain@xxxxxxx
NEW
3.0
Header file errors => empty tasks
38197 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=38197>
nor
P3
alain@xxxxxxx
NEW
3.0
wrong tasks shows as result of compilation.
52676 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=52676>
nor
P3
alain@xxxxxxx
NEW
3.0
I18N: Makefile editor input via alt keystroke sequence cl...
59193 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=59193>
nor
P3
alain@xxxxxxx
NEW
3.0
Cannot debug DLLs with DOS slash in path
59320 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=59320>
enh
P3
alain@xxxxxxx
NEW
3.0
Remove Navigator view from the default C/C++ Perspective
83566 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=83566>
enh
P3
dinglis@xxxxxxx
NEW
3.0
[CPathEntry] Container content not refreshed
53174 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=53174>
maj
P3
Mikhailk@xxxxxxx
REOP
3.0
I18N: CDT Debug can't find a non-ascii filename
60890 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=60890>
nor
P2
Mikhailk@xxxxxxx
NEW
3.0
Accessibility: Can't navigate inside Additional Source Lo...
Going into RC3 with no overall idea about the defect status is a
planning nightmare. How can we predict a GA release if we do not
understand the amount of churn that we are planning?
</soapbox>
- Dave
Alain Magloire <alain@xxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx
07/22/2005 09:15 AM
Please respond to
"CDT General developers list."
To
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject
RE: [cdt-dev] CDT 3.0 Closing
To quote my mentor, Obi-Wan:
"Only Sith deal in absolutes!"
It is my hope we will never be so rigid to let a release go with major
defects because of some rule.
So far committers were doing an amazing job at getting things together.
I'm not quite sure what the fuss is about. We are a heteroclite bunch
with different priorities and sometimes reality will dictates the course
of action i.e. not able to fulfill a commitment.
To answer your question, it is basically the same as Thomas already
posted. Committers that know this piece of code will have to make the
call base on all the factors and when in doubt they usually post for
wider feedbacks to this list. For example, the C formatting code was
drop from the release, some work on the indexer, etc was voted down.
This may sound harsher then intended, but companies shipping major piece
of code, GCC, GDB, Mozilla etc ... will usually take a snapshot/release
and do there own Q/A before incorporating the open source project.
Eclipse, CDT are no exceptions.
_____
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of David Daoust
Sent: Thursday, July 21, 2005 2:02 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] CDT 3.0 Closing
I guess this leads to the question of which defects do you think QNX can
fix after RC3 but before RC4? At IBM we were assuming that ALL the
defects would be addressed by RC3, and we were only doing Doc work after
this.
To me "addressed" means, to evaluate the defect, and fix it if needed,
otherwise move it to a future release. At this late stage of the
release we should know exactly which of the existing defects will be
fixed before the final release.
- Dave
Alain Magloire <alain@xxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx
07/21/2005 11:59 AM
Please respond to
"CDT General developers list."
To
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject
RE: [cdt-dev] CDT 3.0 Closing
-----Original Message-----
<snip>
The reason I ask is that we have a large number of bugs still open on
3.0, the vast majority owned by the gang at QNX. I just want to make
sure we're all on the same page.
Yes, we've been so tied up; things have a surprising way of coming
together
at the wrong moment. How about to see after RC3 if an RC4 is needed?
8-)
Note: July/August release cycles are no-nos, recipe for trouble.
_______________________________________________
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
