[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
