1 jesse@FSCK.COM: ok. anyone here
2 interested in having RT as a bug tracker integrated with CVS? ()
4 marc: in principle, sure. ()
6 jesse@FSCK.COM: want to write up your
7 ideal of how such a beast would work? ()
9 alex_c: what sort of integration are you thinking of, Jesse? ()
11 jesse@FSCK.COM: well, that's what I want
12 to know, alex. lots of people want their bug trackers tied to their
13 version control. I want to know what people want it to _do_ ;) ()
17 marc: similarly to what the debian bts does.
18 you put a magic string ("rt-closes#123") and it causes the bug in rt to
19 be closed (or appended with a different magic string) with the commit
20 message. also nice would be if rt would then generate links to a
23 jhawk: Hrmm. cvs front-end that strips 'em out?
24 Perhaps with RT: lines instead of CVS: lines in the commit
27 marc: the magic string goes in the commit
28 message, that is. no, use one of the magic post-commit scripts. ()
31 jesse@FSCK.COM: well, there's also the
32 pre-commit script to lock out commits wihtout a ticket id ()
34 jhawk: Personally, I don't want to force special
35 magic strings to the bug-tracking system, some of which may be
36 confidential, to appear in the cvs logs. ()
38 marc: I could see wanting that on a release
41 jhawk: I also think it would be cool to supply
42 template stuff for you to edit. ()
44 jesse@FSCK.COM: I'm not sure cvs can be
45 made to do that. can it? (generate templates) ()
47 jhawk: It would be reasonable, in my model, to
48 turn some kinds of RT: lines into things that fell in the commit
49 message, but not all kinds. ()
51 marc: I don't quite see jhawk's objection. ()
53 ghudson: In my observation, locking out commits
54 without a ticket ID is usually an impediment to development, and leads
55 to developers having the one bug which all commits cite. ()
57 jhawk: If you had a CVS frontend, it could geneate
58 the template and feed it to 'cvs commit -m' ()
60 ghudson: CVS can generate templates and verify
61 that they have been filled in. ()
63 jhawk: What Greg says sounds cool; greg, what do
64 you mean? marc: one sec. ()
66 marc: I think assuming a frontend is a terrible
69 jesse@FSCK.COM: greg: agreed. but people
70 seem to want it. the idea would be only for a locked down release
73 jhawk: marc: So, I might want to close an open
74 ticket as part of a commit message without that showing up in the
75 coommit message. Or to insert a splufty long comment into a ticket
76 while I do the commit but not close or really change the state, and
77 that comment might want to ramble a lot but not include that ramble in
78 the commit message. ()
80 jesse@FSCK.COM: well, then arguably, you
81 might want to not use the commit message for that update, but instead
82 just go straight to the bts ()
84 marc: I think the idea is to force you to
85 mention the ticket closing in the commit message. ()
87 jesse@FSCK.COM: but yeah, state changing
88 and 'update messages' are seperate concepts that should both be
91 jesse@FSCK.COM: part of the idea is to
92 drag the commit message into the BTS ()
94 jhawk: Err, I think it quite frequent that I want
95 to put seperate info in both the commit message and the ticket system,
96 and entering them at the same time seems cool. ()
98 jesse@FSCK.COM: ok. noted. I'll see if
99 that's doable, when i get around to this. ()
101 marc: so I think you want a custom front-end,
102 but I don't think what you want is what jesse is talking about. ()
104 jesse@FSCK.COM: the thing that would be
105 really cool that scare the pants off me is tracking which branches bugs
106 exist in / are fixed in ()
108 jesse@FSCK.COM: what jhawk wants should
109 be doable, now that I understand his reqts. ()
111 marc: that would require the bts to understand
112 branches in some fundamental way. ()
114 jesse@FSCK.COM: yes. see above, about
117 sly: uh oh, not more people losing their pants... ..
120 ghudson: RT needs to know the names of branches
121 and their structure (so that you can tell it "fixed in foo" and it
122 knows that the bug is still fixed in anything that branches off of foo,
123 but not necessarily in other new branches), but nothing more than that.
125 jhawk: So, note that what I'm describing is how
126 I'd like the UI to be, from a generic architectural level, and not
127 really thinking terribly specific. Greg, can you explain the CVS
130 jesse@FSCK.COM: and it needs to know
131 exactly "when" a branch happens. because "fixed in foo" won't fix
132 something that branched off foo yesterday ()
134 marc: jesse was talking about integrating rt
135 with cvs. building a new developent+repository+bts from scratch would
136 be a problem with larger scope :-) ()
138 jesse@FSCK.COM: marc: was that in
139 response to jhawk? ()
141 ghudson: CVS and templates: "rcsinfo" lets you
142 specify a template for log messages, and "commitinfo" lets you check
145 ghudson: Er, sorry, my bad.
146 s/commitinfo/verifymsg/ ()
148 marc: with cvs, if you have the revision number
149 of the fix (which you should). you can use the branch version number to
150 get a date and see when the branch happened relative to the fix. ()
154 jesse@FSCK.COM: Ok. would people
155 consider "integration with CVS" to be subpar or incomplete if it didn't
156 deal with tracking branches? ()
158 marc: incomplete relative to an ideal, but not
159 subpar, as it would still be useful. ()
161 allbery@CS.CMU.EDU: CVS's branch
162 support sucks so much that failure to work with it is hardly a bug ()