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
|
nor
|
P3
|
alain@xxxxxxx
|
NEW
|
3.0
|
Header file errors => empty tasks
|
|
38197
|
nor
|
P3
|
alain@xxxxxxx
|
NEW
|
3.0
|
wrong tasks shows as result of compilation.
|
|
52676
|
nor
|
P3
|
alain@xxxxxxx
|
NEW
|
3.0
|
I18N: Makefile editor input via alt keystroke
sequence cl...
|
|
59193
|
nor
|
P3
|
alain@xxxxxxx
|
NEW
|
3.0
|
Cannot debug DLLs with DOS slash in path
|
|
59320
|
enh
|
P3
|
alain@xxxxxxx
|
NEW
|
3.0
|
Remove Navigator view from the default C/C++
Perspective
|
|
83566
|
enh
|
P3
|
dinglis@xxxxxxx
|
NEW
|
3.0
|
[CPathEntry] Container content not refreshed
|
|
53174
|
maj
|
P3
|
Mikhailk@xxxxxxx
|
REOP
|
3.0
|
I18N: CDT Debug can't find a non-ascii filename
|
|
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
