RE: [cdt-dev] Progressing towards 2.0 GA

[Douglas Schaefer <dschaefe@xxxxxxxxxx>]

On the subject of the 2.0 branch, I guess we should do it as soon as the 
RC build is done on Monday. As we have mentioned, we will be doing 
performance work on the parser and that is likely to blow everything up 
right away. The sooner we get started on this the more time we will have 
to recover. We will likely do this work on the 2.0 branch and merge it 
back to head once we're stable again. That'll let the 2.1 guys march 
ahead.

An interesting discussion also revolves around the 3.0 work and where that 
would go. Having too many streams will kill us, but I would love to see 
the managed build work march ahead as soon as we can. I'm not sure we can 
get that all done and stable by the end of October, tough.

Doug Schaefer, IBM's Eclipse CDT Architect
Ottawa (Palladium), Ontario, Canada



Sebastien Marineau <sebastien@xxxxxxx> 
Sent by: cdt-dev-admin@xxxxxxxxxxx
06/23/2004 12:04 PM
Please respond to
cdt-dev


To
"'cdt-dev@xxxxxxxxxxx'" <cdt-dev@xxxxxxxxxxx>
cc

Subject
RE: [cdt-dev] Progressing towards 2.0 GA






Hi Kleo,
 
thanks for driving this -- I absolutely agree with your suggestion.The 
proposal would be to:
 
- Target the first CDT release candidate for Monday, June 28th. Between 
now and then, all 
CVS commits would have to be for identified 2.0-gating defects and would 
have to be reported to the CDT 
dev list. As of Monday, all commits would stop along and everyone would 
hammer away on the CDT RC.
One open question is whether we should branch the CDT tree at this 
point.My suggestion would be to
do so.
 
- After Monday, only gating critical defects would be fixed. We would 
follow the same process as
Eclipse for code checkins - Any checkin would have to be submitted to the 
CDT dev list (as a patch)
for review, along with rationale, criticality, and bug ID. Commiters could 
veto the fixes if we deem them too
risky or inappropriate.
 
- We spin a second release candidate (if needed) on Wednesday, soak in it, 
and declare it GA if
no stoppers are found, else we go through the RC cycle again.
 
How would this work for everyone? There is definitely a lot of interest 
and desire from everyone to have CDT
GA at the same time as Eclipse 3.0, and this would put us within a few 
days. While CDT 2.0 will not be
perfect, we can document known issues and limitations and address them in 
upcoming releases.
 
As a follow-up, we can have a separate discussion on the definition and 
timing of what will go into 2.0.1 and 2.1.
I'll send a follow-up to your email, Kleo, with some proposals and we can 
discuss from there.
 
Thanks,
 
Sebastien
-----Original Message-----
From: Kleanthis Hapitas [mailto:khapitas@xxxxxxxxxx]
Sent: Tuesday, June 22, 2004 12:02 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Progressing towards 2.0 GA


Hi all, 

I thought we should go around and see how we are progressing towards the 
GA milestone targeted for the end of the month. 

The Eclipse platform declared RC3 just this past weekend, and they have 
identified about 25 defects that they will still want to fix before going 
GA. So, they are planning to have RC4 built by the middle of this week, 
and once those 25 fixes have been tested and verified, and assuming no 
further regressions, they will announce GA likely before the end of this 
week (June 25). 

Given that Eclipse will be done by June 25, we should think about drawing 
a line for when the CDT could build our (first) release candidate. Once we 
do that, the goal would be that everyone takes a good look at the build to 
make sure we have no further show stoppers. If we don't we could declare 
GA after a few days of soak. If we do, we would do another release 
candidate build, and so on... 

So, what say you? What's a reasonable target for an initial release 
candidate? End of the week? Early next week? 

Cheers, 

Kleo Hapitas