----- Original Message -----
Sent: Saturday, September 20, 2003 12:21
PM
Subject: RE: [cdt-dev] 1.2
branching
I'm
glad the branching proposal caused so much pushback... I was kind
of
expecting this :-)
Anyways, as we move towards the Oct 3rd release
candidate, we do have to focus on
critical bugs, code stability and minimize any new
features going in. The vacation this summer,
combined with the recent split of the builders, has
resulted in lots of last minutes changes, which
unfortunately are hard to avoid to meet the
feature/usability objectives of 1.2. However,
I
think we also have to be sensitive to Tanya and
others who are working very hard at
making the user docs reflect the 1.2 features and UI.
We also have to be aware to the test
efforts and allot enough time for this, and make sure
we don't invalidate
any
previous testing with last-minute changes.
Here's a proposal for the procedure for the next two
weeks:
-
focus on fixing critical bugs; Kleo to regularly post the list of defects from
bugzilla, which we'll
use
to track progress
-
other non-critical bugs can be fixed, but commiters will have to use their
judgement on the risk
level associated. If any of them have unintended side
effects, we may have to reverse them.
-
any new code changes, minor features or cleanups would have to be posted to
the list ahead of
time
for feedback/rejection. This would provide a "gates" to ensure we minimize the
risk of what's
going in, as well as give others
visibility into changes that could affect their area (e.g. docs,
testing).
-
branching will be done before the RC -- likely a few days before. We can
discuss the timing
on
the list and ensure everyone is in agreement.
What
do people think? I'm not trying to create too heavy a process, but just want
to ensure we're all
aware of the fixes and changes going in to minimize
the churn leading to the RC. As a start to this,
maybe everyone could email the list of things they
might have in progress for 1.2 (that is not part of the
defect
list
below) so we're all aware of them.
Sebastien
I agree that we
might be more productive if we delayed creating the branch...
We have already had a discussion and a
proposal on how to manage the content going into the stream in these last
couple of weeks, which was as follows:
We talked about creating (and regularly posting) a list of defects
that we would consider "gating" (i.e. serious enough to potentially delay
the release). That list would consist of all defects with a severity of
"blocking", "critical", or "major". If people agree that this is a
reasonable criteria for what gets patched into the release going forward and
what doesn't, then I could easily keep this list up to date and post it
regularly as we head into the last couple of weeks. If there are defects
that should be fixed but are not in the list, all it would take to get them
there is to set the appropriate severity and target release fields.
At the moment, such a list
currently contains 29 defects (1 blocking, 10 critical & 18 major)
attached below.
So what do
people think? Would seeing this list once every couple of days help focus
attention on stabilizing the release?
Kleo
------------------------------------------------------------------------------------------------------------------------------
List of currently unresolved Blocking,
Critical and Major defects
-------------------------------------------------------------------------------------------------------------------------------
ID Sev
Pri Plt
Owner
Reporter
State Result
Comp
Vers TargetM
Summary
42916
cri P3
PC alain@xxxxxxx
twolff@xxxxxxxxxx
NEW Core
1.2
--- c/c++ task tags not recognized
42929 cri
P3 PC
gheorghe@xxxxxxxxxx kesselhaus@xxxxxxx
NEW
CDT-pars 1.2
--- "log gets filled when parser throws on
standard headers, i..."
43099
cri P3
PC gheorghe@xxxxxxxxxx
gheorghe@xxxxxxxxxx NEW
Core
2 ---
Dep Tree Persistence
43100 cri P3
PC gheorghe@xxxxxxxxxx
gheorghe@xxxxxxxxxx
NEW Core
2
--- Dep Tree/Indexer concurrency
problem
43372
cri P3 PC
Mikhailk@xxxxxxx
twolff@xxxxxxxxxx NEW
Debug
1.2 ---
Cannot debug managed c++ project
43220 cri P3
PC sevoy@xxxxxxxxxx
twolff@xxxxxxxxxx NEW
Core
1.2 ---
Cannot link an object file in managed c/c++
project
43292
cri P3 PC
sevoy@xxxxxxxxxx
twolff@xxxxxxxxxx NEW
Core
1.2 ---
Cannot manage configurations in build properties page
41282 maj
P3 PC
alain@xxxxxxx
twolff@xxxxxxxxxx NEW
Core
1.2 ---
Can't build from C/C++ Projects view
43129 maj P3
PC aniefer@xxxxxxxxxx
bnicolle@xxxxxxxxxx
NEW CDT-pars
1.2 ---
Search: Cannot search for definitions of global
variables
43105
maj P3 All
dschaefe@xxxxxxxxxx
dschaefe@xxxxxxxxxx NEW
Cpp-Exte
1.2 --- Fix
update site to point to the right location
43348 maj P3
PC gheorghe@xxxxxxxxxx
dinglis@xxxxxxx NEW
Core 1.2
--- Long workbench shutdown
times
43215
maj P3 PC
gheorghe@xxxxxxxxxx
gheorghe@xxxxxxxxxx NEW
UI
2 ---
C/C++ Perspective rename
41275 maj P3
PC sevoy@xxxxxxxxxx
twolff@xxxxxxxxxx NEW
Core
1.2 ---
Dependent project is not rebuilt by
Dependee
42522
maj P3 PC
sevoy@xxxxxxxxxx
twolff@xxxxxxxxxx NEW
Core
1.2 ---
Managed make doesn't refresh CProject view properly
35461 blo
P3 PC
alain@xxxxxxx
fernando@xxxxxxxxxxxxx NEW
Core
1.2 1.2
Can't install latest CDT relase (1.0.1) on Linux GTK+
25816 cri
P3 PC
alain@xxxxxxx
d92-jwa@xxxxxxxxxxx NEW
Core
1.2 1.2
"Pressing ""+"" in the Navigator on a binary hangs
Eclipse"
36859
cri P3 PC
alain@xxxxxxx
compiler@xxxxxxxxxxxxxx NEW
UI
1.2 1.2
eclipse hangs after closing a project
41720 cri
P3 PC
sevoy@xxxxxxxxxx twolff@xxxxxxxxxx
NEW
Core 1.2
1.2 library added to a
project not included in makefile
41826 cri P3
PC sevoy@xxxxxxxxxx
twolff@xxxxxxxxxx NEW
Core
1.2 1.2
Incremental builds for managed projects must be
implemented
43106
maj P3 PC
aniefer@xxxxxxxxxx
hamer@xxxxxxxxxx REOP
CDT-pars 1.2
1.2 Symbol Table
support needed to resolve types
43156 maj P3
All aniefer@xxxxxxxxxx
jcamelon@xxxxxxxxxx
NEW CDT-pars
1.2 1.2
require ability to add in implicit inheritance copy
const...
41751
maj P3 PC
gheorghe@xxxxxxxxxx
twolff@xxxxxxxxxx NEW
Core
1.2 1.2
Cannot search on cpp files
42865 maj P3
All
gheorghe@xxxxxxxxxx jcamelon@xxxxxxxxxx
NEW
Core 1.2
1.2 remove the Indexer
tab from the Project property page
43021 maj P3
PC jcamelon@xxxxxxxxxx
bnicolle@xxxxxxxxxx
NEW CDT-pars
1.2 1.2
Search: cannot find things in stdio.h
43051 maj
P3 PC
jcamelon@xxxxxxxxxx bnicolle@xxxxxxxxxx
NEW
CDT-pars 1.2
1.2 Search: cannot specify relative search
paths
43053
maj P3 PC
jcamelon@xxxxxxxxxx
jcamelon@xxxxxxxxxx NEW
CDT-pars
1.2 1.2 require
reference cleanup for expressions
43084 maj P3
All
jcamelon@xxxxxxxxxx jcamelon@xxxxxxxxxx
NEW
CDT-pars 1.2
1.2 need to restructure TypeId to allow
dynamic_cast<> type e...
38896
maj P3
PC Mikhailk@xxxxxxx
hb@xxxxxxxxxxxxxxxx NEW
Debug
1.1 1.2
watching a global variable dont work in debug
mode
42904
maj P3 PC
sevoy@xxxxxxxxxx
twolff@xxxxxxxxxx NEW
Core
1.2 1.2
"Managed build path properties don't recognize ""\"""
Douglas
Schaefer/Ottawa/IBM@IBMCA Sent by: cdt-dev-admin@xxxxxxxxxxx
09/19/2003 01:56 PM
Please respond
to cdt-dev@xxxxxxxxxxx |
|
To
| cdt-dev@xxxxxxxxxxx
|
cc
|
|
Subject
| RE: [cdt-dev] Re:
[cdt-debug-dev] CDT 1.2.0.50 success story for
arm JTAG eCos |
|
I would only agree with creating the branch now if we felt that
merging
fixes from the 1.2 branch to HEAD will be relatively painless.
I get the
feeling there will still be a good chunk of churn
leading up to "code
freeze" at the end of Sept and would prefer we get
to that point before
branching.
Doug Schaefer, Senior Software
Developer
IBM Rational Software, Ottawa, Ontario,
Canada
Sebastien Marineau <sebastien@xxxxxxx>
Sent
by: cdt-dev-admin@xxxxxxxxxxx
09/19/2003 12:50 PM
Please respond
to
cdt-dev@xxxxxxxxxxx
To
"'cdt-dev@xxxxxxxxxxx'"
<cdt-dev@xxxxxxxxxxx>
cc
Subject
RE: [cdt-dev] Re:
[cdt-debug-dev] CDT 1.2.0.50 success story for arm JTAG
eCos
> Please don't die on me Alain.
You're quite valuable to this
> project, I
> don't want
to give you a coronary.
>
> Today is supposed to be feature
freeze date. Thus, from
> Monday on (since
> the weekend
still counts as today :-) ) we are only supposed
> to be fixing
> bugs.
> There is no reason why we couldn't cut the branch on
Monday
> and thus put
> things that we weren't counting on as
being in 1.2 (like this
> feature,
> IMO) in the HEAD.
>
> Otherwise, what criteria should we be using for screening
new
> features/patches for 1.2? Who will be testing it or
> supplying docs upon
> it?
I'd suggest we cut the
branch for 1.2 ASAP (e.g. Monday) to allow us
to ship 1.2 on schedule.
You are absolutely correct that we need to
stabilize and focus on
bugfixing over the next few weeks.
+1 on branching
Monday.
Sebastien
>
> JohnC
>
>
cdt-dev-admin@xxxxxxxxxxx wrote on 09/19/2003 11:55:55 AM:
>
>
> >
> > > Sent to cdt-dev rather than
debug-dev:=20
> > > Should we cut a 1.2 branch soon? Is
this feature going
> into 1.2?=20
> > >
> >
> > Do you want to give me a heart attack?
> >
>
> Folks here was under the impression that the freeze/branch is at
the
> > end of Steptember.
> > Did we get our wires cross
?
> >
> >
> >
_______________________________________________
> > cdt-dev mailing
list
> > cdt-dev@xxxxxxxxxxx
> >
http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
_______________________________________________
> cdt-dev mailing
list
> cdt-dev@xxxxxxxxxxx
>
http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing
list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev
mailing
list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev