--- /dev/null
+jesse@FSCK.COM: ok. anyone here
+ interested in having RT as a bug tracker integrated with CVS? ()
+
+marc: in principle, sure. ()
+
+jesse@FSCK.COM: want to write up your
+ ideal of how such a beast would work? ()
+
+alex_c: what sort of integration are you thinking of, Jesse? ()
+
+jesse@FSCK.COM: well, that's what I want
+ to know, alex. lots of people want their bug trackers tied to their
+ version control. I want to know what people want it to _do_ ;) ()
+
+alex_c: weird. :) ()
+
+marc: similarly to what the debian bts does.
+ you put a magic string ("rt-closes#123") and it causes the bug in rt to
+ be closed (or appended with a different magic string) with the commit
+ message. also nice would be if rt would then generate links to a
+ webcvs server. ()
+
+jhawk: Hrmm. cvs front-end that strips 'em out?
+ Perhaps with RT: lines instead of CVS: lines in the commit
+ interaction? ()
+
+marc: the magic string goes in the commit
+ message, that is. no, use one of the magic post-commit scripts. ()
+
+
+jesse@FSCK.COM: well, there's also the
+ pre-commit script to lock out commits wihtout a ticket id ()
+
+jhawk: Personally, I don't want to force special
+ magic strings to the bug-tracking system, some of which may be
+ confidential, to appear in the cvs logs. ()
+
+marc: I could see wanting that on a release
+ branch. ()
+
+jhawk: I also think it would be cool to supply
+ template stuff for you to edit. ()
+
+jesse@FSCK.COM: I'm not sure cvs can be
+ made to do that. can it? (generate templates) ()
+
+jhawk: It would be reasonable, in my model, to
+ turn some kinds of RT: lines into things that fell in the commit
+ message, but not all kinds. ()
+
+marc: I don't quite see jhawk's objection. ()
+
+ghudson: In my observation, locking out commits
+ without a ticket ID is usually an impediment to development, and leads
+ to developers having the one bug which all commits cite. ()
+
+jhawk: If you had a CVS frontend, it could geneate
+ the template and feed it to 'cvs commit -m' ()
+
+ghudson: CVS can generate templates and verify
+ that they have been filled in. ()
+
+jhawk: What Greg says sounds cool; greg, what do
+ you mean? marc: one sec. ()
+
+marc: I think assuming a frontend is a terrible
+ idea. ()
+
+jesse@FSCK.COM: greg: agreed. but people
+ seem to want it. the idea would be only for a locked down release
+ branch. ()
+
+jhawk: marc: So, I might want to close an open
+ ticket as part of a commit message without that showing up in the
+ coommit message. Or to insert a splufty long comment into a ticket
+ while I do the commit but not close or really change the state, and
+ that comment might want to ramble a lot but not include that ramble in
+ the commit message. ()
+
+jesse@FSCK.COM: well, then arguably, you
+ might want to not use the commit message for that update, but instead
+ just go straight to the bts ()
+
+marc: I think the idea is to force you to
+ mention the ticket closing in the commit message. ()
+
+jesse@FSCK.COM: but yeah, state changing
+ and 'update messages' are seperate concepts that should both be
+ supported. ()
+
+jesse@FSCK.COM: part of the idea is to
+ drag the commit message into the BTS ()
+
+jhawk: Err, I think it quite frequent that I want
+ to put seperate info in both the commit message and the ticket system,
+ and entering them at the same time seems cool. ()
+
+jesse@FSCK.COM: ok. noted. I'll see if
+ that's doable, when i get around to this. ()
+
+marc: so I think you want a custom front-end,
+ but I don't think what you want is what jesse is talking about. ()
+
+jesse@FSCK.COM: the thing that would be
+ really cool that scare the pants off me is tracking which branches bugs
+ exist in / are fixed in ()
+
+jesse@FSCK.COM: what jhawk wants should
+ be doable, now that I understand his reqts. ()
+
+marc: that would require the bts to understand
+ branches in some fundamental way. ()
+
+jesse@FSCK.COM: yes. see above, about
+ the pants. ()
+
+sly: uh oh, not more people losing their pants... ..
+
+
+ghudson: RT needs to know the names of branches
+ and their structure (so that you can tell it "fixed in foo" and it
+ knows that the bug is still fixed in anything that branches off of foo,
+ but not necessarily in other new branches), but nothing more than that.
+
+jhawk: So, note that what I'm describing is how
+ I'd like the UI to be, from a generic architectural level, and not
+ really thinking terribly specific. Greg, can you explain the CVS
+ template thing? ()
+
+jesse@FSCK.COM: and it needs to know
+ exactly "when" a branch happens. because "fixed in foo" won't fix
+ something that branched off foo yesterday ()
+
+marc: jesse was talking about integrating rt
+ with cvs. building a new developent+repository+bts from scratch would
+ be a problem with larger scope :-) ()
+
+jesse@FSCK.COM: marc: was that in
+ response to jhawk? ()
+
+ghudson: CVS and templates: "rcsinfo" lets you
+ specify a template for log messages, and "commitinfo" lets you check
+ them. ()
+
+ghudson: Er, sorry, my bad.
+ s/commitinfo/verifymsg/ ()
+
+marc: with cvs, if you have the revision number
+ of the fix (which you should). you can use the branch version number to
+ get a date and see when the branch happened relative to the fix. ()
+
+marc: jesse: yes. ()
+
+jesse@FSCK.COM: Ok. would people
+ consider "integration with CVS" to be subpar or incomplete if it didn't
+ deal with tracking branches? ()
+
+marc: incomplete relative to an ideal, but not
+ subpar, as it would still be useful. ()
+
+allbery@CS.CMU.EDU: CVS's branch
+ support sucks so much that failure to work with it is hardly a bug ()
+
+
projects / freeside.git / blobdiff