Issues 2010-02-16
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
|
 
Still loading...
ABCDEFG
1
IDVotesType/MemberMilestonePriOwnerSummary/Comments
2
3
Steven's former research issues need to be parceled out (left over from last time)
4
5
19100DEFECT-research-P1issues@sconsRecursive flag ignored in dictionary based scanners
6
consensus: Steven to add test case and other info then assign to Gary 2.x p4 (DONE)
7
8
Bill
9
Brandon
10
David
11
Gary
12
Greg
13
Jim
14
Ken
15
Sohail
16
Stevendone, i uploaded patch(es) and added explanation
17
18
7800DEFECT-research-P3issues@sconsNon-Builder BUILDERS value doesn't generate error
19
consensus: Steven to take back for partial fix as discussed then assign to Gary 2.x p4
20
21
Bill
22
Brandon
23
David
24
Gary
25
Greg
26
Jim
27
Ken
28
Sohail
29
Steveni uploaded patches and explanation, but i'd like to discuss this today
30
31
And now back to the unassigned issues
32
33
25490DEFECTtriageP4issues@sconsDMD tool assumes D v1.0
34
consensus: waiting for more details and patch from OP
35
36
Bill
37
Brandon
38
David
39
GaryLooks like this is in progress; we should wait for Russel to submit a patch that works for him, then just commit it blind. (As long as all current tests pass.)
40
Greg
41
Jim
42
Ken
43
Sohail
44
Stevenwhat Gary said
45
46
25520DEFECTtriageP4issues@sconsipk Package() does not accept postinst overrides
47
consensus: 2.1 p3 Trevor w/ Gary as QA
48
49
Bill2.1p3Trevor
50
Brandon
51
David
52
Gary2.1p3TrevorWorking on it w/ Trevor, who has agreed to help with packaging issues as well!
53
Greg2.1p3TrevorWith Gary as QA
54
Jim
55
Ken
56
Sohail
57
Steven2.1p3Trevor
58
59
25580PATCHtriageP4issues@scons"output" file not deleted for yacc builder
60
consensus: 2.x p3 Bill
61
62
Bill2.xp4bdbaddogI'll take this 2.x timeframe. My clients pretty much always use yacc
63
Brandon
64
David
65
Gary2.xp4I don't particularly like 3.x for this just due to missing testcase, because we'll forget about it til then. I'd rather mark it for 2.x with a note that if nobody can work on it or cares enough to fix, OK to defer.
66
Greg3.xp2No response from OP. The change is small; the impedement is the test case. 3.x p2 unless someone volunteers to take on the test case, in which case 2.1 p3.
67
Jim
68
Ken
69
Sohail
70
Steven2.xp4bdbaddogwhat gary said re: marking as deferrable
71
72
25620DEFECTtriageP4issues@sconsobsolete README.txt
73
consensus 2.1 p4 +Easy Bill
74
75
Bill2.1p4 +EasyAgree w/ Greg; delete it. Ideally replace w/ something more useful, but no point having old dead stuff in such a visible place.
76
Brandon
77
David
78
Gary2.1p4 +EasyAgree w/ Greg; delete it. Ideally replace w/ something more useful, but no point having old dead stuff in such a visible place.
79
GregHe's right; with source control, there's no reason to keep it, but if Steven wants it to hang around. I'll defer to his choice.
80
Jim
81
Ken
82
Sohail
83
Steven2.1p4 +EasyI'll go with the flow; delete it.
84
85
25650DEFECTtriageP4issues@sconsSHCXXCOMSTR and CXXCOMSTR
86
consensus doc 2.1 p3 Steven
87
88
Bill
89
Brandon
90
David
91
GaryFrom looking at the code, none of the *COMSTR vars have any default values. I can see how linking the SH* ones with non-SH* ones might be useful, but I recommend keeping it as is (perhaps a doc note in CXXCOMSTR would suffice?)
92
GregEr, that's not what I said. I said it was unexpected. But then I don't know if using '$CXXCOMSTR' as the default would display the command if CXXCOMSTR was blank. If it will, that's what we should do; if not, leave it as it is.
93
Jim
94
Ken
95
Sohail
96
StevenLeave it as is and document the behavior more prominently. I'm nervous about linking $SHCXXCOMSTR to $CXXCOMSTR this way when we don't similarly link the underlying commands. It might help this one guy's case, but at the risk of confusing other uses.
97
98
25660ENHANCEMENTtriageP4issues@sconsAction with a recursive function
99
consensus Gary to get more info from OP
100
Loading...
 
 
 
Sheet 1