Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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:
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

Back to the top