From dswegen at software.plasmon.com Tue Jun 1 10:47:26 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Tue, 1 Jun 2004 11:47:26 +0100 Subject: Scmbug In-Reply-To: <1085962119.1380.0.camel@syd.mkgnu.net> References: <1085962119.1380.0.camel@syd.mkgnu.net> Message-ID: <20040601104726.GQ30765@software.plasmon> As the main code-bodger of the bz->cvs integration stuff on Steve's page I'd like to make a few comments: 1) (And this is the one that really annoyed me) If you want people to use a tool that you've written, at least put a descriptive page up. Just pointing to a tarball and saying "Abandon all the work you've done, this is much better" just isn't going to work. I very nearly didn't bother looking any further at that point... 2) To be honest, I've pretty much gone off the idea of having the scm system fiddling directly with the bz DB. The main problem is that as bz starts working with more DB backends, and schemas change, the script is going to have to keep up. More maintainance overhead, and you also miss out on nice things like sanity checking the SQL. FWIW, the next version of the cvs->bz integration will probably talk via the bz web ui (which is going to need some work). 3) Using a daemon is potentially a nice solution. But how useable is fork() on win32 systems? This is a consideration, as there are plenty of bz users on win boxes (I know, sounds mad, doesn't it ;) 4) (Related to the one above): Having an intermediary step that sits between cvs and bz has two problems: One is that it is one extra step which the user can muck up installing (though your solution is far nicer than ours), and it may make things awkward from a networking POV (think firewalls). 5) A common request we have is that when a single commit that covers files in multiple directories is made, only one message will be placed in bz. I couldn't see anything in your code that dealt with this, but if it isn't there you might want to keep that in mind. I still havn't come up with a nice clean solution to this. 6) Potential bug: I believe that the parsing of files,dirs and versions in Glue.pm/prepare_activity_commit_from_CVS doesn't cope with files or dirs with whitespace in them (it won't cope with commas either, but then there is very little that can be done about that). We had this very problem with windows users who added documentation... Give me a shout and I'll dig up the new regexp I came up with that copes with this. 7) You might want to think about nicking our bz->viewcvs autolinking stuff, and modifying it to cope with the format of your commit messages. For a lot of the users of our stuff this a major nice feature. The only thing that I believe your system improves on over ours is the delivery method, which looks much, much easier to set up and configure. As I said in point 2 I think talking directly to the DB is wrong, but the real problem is how to solve the issues that raises, which is a different discussion :) Cheers Dave From jth at mikrobitti.fi Tue Jun 1 10:59:07 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Tue, 01 Jun 2004 13:59:07 +0300 Subject: Scmbug In-Reply-To: <20040601104726.GQ30765@software.plasmon> References: <1085962119.1380.0.camel@syd.mkgnu.net> <1085962119.1380.0.camel@syd.mkgnu.net> Message-ID: <5.1.0.14.2.20040601135501.032eb7a8@mikrobitti.fi> At 11:47 1.6.2004 +0100, you wrote: >3) Using a daemon is potentially a nice solution. But how useable is >fork() on win32 systems? This is a consideration, as there are plenty of >bz users on win boxes (I know, sounds mad, doesn't it ;) Not very, although it depends on what we're talking about. Having multiple processes/threads is, of course, fine in Windows. Using ActiveState Perl's fork() emulation isn't that good; you can read the comments in for some insight and links to additional information. Jouni From kiko at async.com.br Tue Jun 1 14:41:30 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 1 Jun 2004 11:41:30 -0300 Subject: Scmbug In-Reply-To: <20040601104726.GQ30765@software.plasmon> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> Message-ID: <20040601144130.GH813@async.com.br> On Tue, Jun 01, 2004 at 11:47:26AM +0100, Dave Swegen wrote: > is much better" just isn't going to work. I very nearly didn't bother > looking any further at that point... C'mon, Dave. It's a first announcement. :-) > 2) To be honest, I've pretty much gone off the idea of having the scm > system fiddling directly with the bz DB. The main problem is that as bz > starts working with more DB backends, and schemas change, the script is > going to have to keep up. More maintainance overhead, and you also miss > out on nice things like sanity checking the SQL. FWIW, the next version > of the cvs->bz integration will probably talk via the bz web ui (which > is going to need some work). I'm probably available to do the backend work to help you here. Do you have an idea of what sort of interface you need? It's nothing more than adding a comment to a bug, which requires credentials but not much more. Note that Justdave has [secretly?] written a bugzilla-change script (in the line of bugzilla-submit) that already changes a bug report from the commandline, so I guess you could at least harness some of the posting code from there. Probably not too hard, I think. > 5) A common request we have is that when a single commit that covers > files in multiple directories is made, only one message will be placed in > bz. I couldn't see anything in your code that dealt with this, but if it > isn't there you might want to keep that in mind. I still havn't come up > with a nice clean solution to this. This isn't a very easy thing to do. My immediate suggestion is grouping checkins by time and userid and somehow storing it temporarily "somewhere" (file storage somewhere?), and then periodically sweeping through that file and adding comments that are, let's say, five minutes old, to the bug. That requires something daemon-like and isn't a very clean solution, but then again, lack of atomic commits in CVS is a dirty problem. > 7) You might want to think about nicking our bz->viewcvs autolinking > stuff, and modifying it to cope with the format of your commit messages. > For a lot of the users of our stuff this a major nice feature. What about some bz->bonsai autolinking while we're at that? :-) > The only thing that I believe your system improves on over ours is the > delivery method, which looks much, much easier to set up and configure. Delivery method? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From preed at sigkill.com Tue Jun 1 14:48:00 2004 From: preed at sigkill.com (J. Paul Reed) Date: Tue, 1 Jun 2004 07:48:00 -0700 Subject: Scmbug In-Reply-To: <20040601144130.GH813@async.com.br> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> <20040601144130.GH813@async.com.br> Message-ID: <20040601144800.GA21423@sigkill.com> On 01 Jun 2004 at 11:41:30, Christian Robottom Reis arranged the bits on my disk to say: > > 7) You might want to think about nicking our bz->viewcvs autolinking > > stuff, and modifying it to cope with the format of your commit messages. > > For a lot of the users of our stuff this a major nice feature. > > What about some bz->bonsai autolinking while we're at that? :-) That makes a bit more sense. Did I mention I was poking around with Bonsai? It's been slow(er) going than I'd like, but... isn't it always... Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed Math, my dear boy, is nothing more than the lesbian sister of biology. -- Peter Griffin, Family Guy I use PGP; you should use PGP too... if only to piss off John Ashcroft From dswegen at software.plasmon.com Tue Jun 1 16:13:54 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Tue, 1 Jun 2004 17:13:54 +0100 Subject: Scmbug In-Reply-To: <20040601144130.GH813@async.com.br> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> <20040601144130.GH813@async.com.br> Message-ID: <20040601161353.GT30765@software.plasmon> On Tue, Jun 01, 2004 at 11:41:30AM -0300, Christian Robottom Reis wrote: > On Tue, Jun 01, 2004 at 11:47:26AM +0100, Dave Swegen wrote: > > is much better" just isn't going to work. I very nearly didn't bother > > looking any further at that point... > > C'mon, Dave. It's a first announcement. :-) You're right. I apologise for the grumpy tone. It must be the joy at being back at work after a three day weekend that got the better of me :) > > > 2) To be honest, I've pretty much gone off the idea of having the scm > > system fiddling directly with the bz DB. The main problem is that as bz > > starts working with more DB backends, and schemas change, the script is > > going to have to keep up. More maintainance overhead, and you also miss > > out on nice things like sanity checking the SQL. FWIW, the next version > > of the cvs->bz integration will probably talk via the bz web ui (which > > is going to need some work). > > I'm probably available to do the backend work to help you here. Do you > have an idea of what sort of interface you need? It's nothing more than > adding a comment to a bug, which requires credentials but not much more. > > Note that Justdave has [secretly?] written a bugzilla-change script (in > the line of bugzilla-submit) that already changes a bug report from the > commandline, so I guess you could at least harness some of the posting > code from there. Probably not too hard, I think. I had a look at it a while back, and the main bit that needs doing is cleaning up the interface (the --dont_change-- stuff is somewhat grotty, and I seem to recall that adding comments wasn't working). I haven't really had time to get the hang of what is going on in process_bug.cgi. Also, if an error is encountered while submitting changes to multiple bugs the process stops as soon as the error is encountered, rather than printing an error and continuing. For the purposes of the cvs->bz script, this would be bad (mainly for performance reasons). I got partway through hacking things to work - I need some more time to get it working properly. The horrible truth is that we can hack all sorts of stuff into bz, but what it really needs is a nice, consistent and defined interface that can deal with non-interactive external programs. > > > 5) A common request we have is that when a single commit that covers > > files in multiple directories is made, only one message will be placed in > > bz. I couldn't see anything in your code that dealt with this, but if it > > isn't there you might want to keep that in mind. I still havn't come up > > with a nice clean solution to this. > > This isn't a very easy thing to do. My immediate suggestion is grouping > checkins by time and userid and somehow storing it temporarily > "somewhere" (file storage somewhere?), and then periodically sweeping > through that file and adding comments that are, let's say, five minutes > old, to the bug. That requires something daemon-like and isn't a very > clean solution, but then again, lack of atomic commits in CVS is a dirty > problem. This is a hard problem to do right. Somebody mailed the CVS list with a system that apparently almost worked, but I couldn't be asked to look at some 'normal' perl code at the time ;) But that feature is something that could wait. The upside of doing it is that the CVS commit would be instantaneous, rather than having to wait for the script to finish talking to bz (which as we all know can take a while). It would also cope better with bz being down or otherwise unavailable. The downside is that the user wouldn't get to see error messages, and that it might take a while before comments appear in the relevant bugs. > > > 7) You might want to think about nicking our bz->viewcvs autolinking > > stuff, and modifying it to cope with the format of your commit messages. > > For a lot of the users of our stuff this a major nice feature. > > What about some bz->bonsai autolinking while we're at that? :-) Shouldn't be too hard. Surely it should just be a case of coming up with what links you want for files and versions and changing the URLs we use to something else. Then again, I know very little about bonsai, apart from that it makes bz look pretty by comparison. > > > The only thing that I believe your system improves on over ours is the > > delivery method, which looks much, much easier to set up and configure. > > Delivery method? The delivery method from cvs to the script that bungs things into bz: We use email, and this new method uses a custom server. Otherwise the functionailty is pretty much the same. It has one or two features that we don't do, such as optionally adding a new version to a product based on the tag of the comment. I've actually got a semi-written RFC on how to proceed, but I haven't got round to finishing it or posting it. Maybe one day... My unrealistic aim is that one should be able to make an intial commit of the entire linux 2.6 source tree without too much pain ;) Cheers Dave From tree at basistech.com Tue Jun 1 16:14:26 2004 From: tree at basistech.com (Tom Emerson) Date: Tue, 1 Jun 2004 12:14:26 -0400 Subject: Scmbug In-Reply-To: <20040601104726.GQ30765@software.plasmon> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> Message-ID: <16572.43874.368185.954336@tiphares.basistech.net> Dave Swegen writes: > 2) To be honest, I've pretty much gone off the idea of having the scm > system fiddling directly with the bz DB. The main problem is that as bz > starts working with more DB backends, and schemas change, the script is > going to have to keep up. More maintainance overhead, and you also miss > out on nice things like sanity checking the SQL. FWIW, the next version > of the cvs->bz integration will probably talk via the bz web ui (which > is going to need some work). This is where having an XML-RPC or SOAP interface to Bugzilla functionality would be a Big Win: external tools could work with Bugzilla nicely without having to track changes to the schemata. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From dswegen at software.plasmon.com Tue Jun 1 16:30:40 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Tue, 1 Jun 2004 17:30:40 +0100 Subject: Scmbug In-Reply-To: <16572.43874.368185.954336@tiphares.basistech.net> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> <16572.43874.368185.954336@tiphares.basistech.net> Message-ID: <20040601163040.GV30765@software.plasmon> On Tue, Jun 01, 2004 at 12:14:26PM -0400, Tom Emerson wrote: > Dave Swegen writes: > > 2) To be honest, I've pretty much gone off the idea of having the scm > > system fiddling directly with the bz DB. The main problem is that as bz > > starts working with more DB backends, and schemas change, the script is > > going to have to keep up. More maintainance overhead, and you also miss > > out on nice things like sanity checking the SQL. FWIW, the next version > > of the cvs->bz integration will probably talk via the bz web ui (which > > is going to need some work). > > This is where having an XML-RPC or SOAP interface to Bugzilla > functionality would be a Big Win: external tools could work with > Bugzilla nicely without having to track changes to the schemata. Yes! I got away with not being the first one in this discussion to mention either of those words :) Seriously though, having either of those would be nice, and is what I was referring to in my reply to Christian when I said that we can hack things in, but a nice consistent interface would be better. So yes, I agree. Cheers Dave From Gary.Beckmann at TycoHealthCare.com Tue Jun 1 16:47:03 2004 From: Gary.Beckmann at TycoHealthCare.com (Beckmann, Gary) Date: Tue, 1 Jun 2004 12:47:03 -0400 Subject: What happened to the name queries on in search/knob.html.tmpl Message-ID: <16572.45831.420349.989273@radionics.com> I was going to report this as a bug (and if you tell me to, I shall), but thought I'd query here. Why were the named queries removed from the template/en/default/search/knob.html.tmpl from 2.16 going into 2.17? The functionality is still described in the "The Rest of the Form" section of queryhelp.cgi -- and a number of users here would like it back. Before I hack it back in on our local copy (and file the Bugzilla entry): why was this removed? gary From tree at basistech.com Tue Jun 1 17:02:59 2004 From: tree at basistech.com (Tom Emerson) Date: Tue, 1 Jun 2004 13:02:59 -0400 Subject: Scmbug In-Reply-To: <20040601163040.GV30765@software.plasmon> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> <16572.43874.368185.954336@tiphares.basistech.net> <20040601163040.GV30765@software.plasmon> Message-ID: <16572.46787.884144.191641@tiphares.basistech.net> Dave Swegen writes: > Yes! I got away with not being the first one in this discussion to > mention either of those words :) Seriously though, having either of > those would be nice, and is what I was referring to in my reply to > Christian when I said that we can hack things in, but a nice consistent > interface would be better. So yes, I agree. :-) A while back someone said that porting the RedHat XML-RPC code to the current mainline was trivially done. Does any own that? Has anyone reviewed the API to see that it is complete, or at least serves the needs of those wanting to integrate with BZ? I want an external interface that exposes more, or at least lower-level, functionality than the web interface. For example, I want to be able to programmatically add the same milestone to multiple products. Right now I do this in raw SQL. I shouldn't have to. In the past I had a Python library that provided a lot of this functionality for me, but the schema changed and I never updated it (a prime example of the maintainability problem.) With appropriate abstraction, the Bugzilla CGI would use the same underlying mechanisms that the XML-RPC/SOAP bindings would, minimizing duplication and ensuring consistency. Go ahead Gerv, flame on. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From gerv at mozilla.org Tue Jun 1 18:04:01 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 01 Jun 2004 19:04:01 +0100 Subject: Scmbug In-Reply-To: <16572.46787.884144.191641@tiphares.basistech.net> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> <16572.43874.368185.954336@tiphares.basistech.net> <20040601163040.GV30765@software.plasmon> <16572.46787.884144.191641@tiphares.basistech.net> Message-ID: <40BCC511.60903@mozilla.org> Tom Emerson wrote: > With appropriate abstraction, the Bugzilla CGI would use the same > underlying mechanisms that the XML-RPC/SOAP bindings would, minimizing > duplication and ensuring consistency. > > Go ahead Gerv, flame on. Er, what? When have I ever disagreed with this idea (apart from writing things in Python ;-) ? I'd love to see Bugzilla have a clean scriptable interface (as long as it doesn't bind us to keeping constant stuff we want to change.) Gerv From gerv at mozilla.org Tue Jun 1 18:06:22 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 01 Jun 2004 19:06:22 +0100 Subject: What happened to the name queries on in search/knob.html.tmpl In-Reply-To: <16572.45831.420349.989273@radionics.com> References: <16572.45831.420349.989273@radionics.com> Message-ID: <40BCC59E.6040308@mozilla.org> Beckmann, Gary wrote: > Why were the named queries removed from the > template/en/default/search/knob.html.tmpl from 2.16 going into 2.17? Because it's moved, in an effort to simplify the search form. You now create queries from the buglist screen, and manage them either once you've run them, or from a new preferences tab. Gerv From kiko at async.com.br Tue Jun 1 21:10:51 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 1 Jun 2004 18:10:51 -0300 Subject: Scmbug In-Reply-To: <20040601161353.GT30765@software.plasmon> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> <20040601144130.GH813@async.com.br> <20040601161353.GT30765@software.plasmon> Message-ID: <20040601211051.GB647@async.com.br> On Tue, Jun 01, 2004 at 05:13:54PM +0100, Dave Swegen wrote: > I had a look at it a while back, and the main bit that needs doing is > cleaning up the interface (the --dont_change-- stuff is somewhat grotty, > and I seem to recall that adding comments wasn't working). I haven't > really had time to get the hang of what is going on in process_bug.cgi. As I said, I think justdave's script might already handle this part. > Also, if an error is encountered while submitting changes to multiple > bugs the process stops as soon as the error is encountered, rather than > printing an error and continuing. For the purposes of the cvs->bz > script, this would be bad (mainly for performance reasons). What sort of error? > The horrible truth is that we can hack all sorts of stuff into bz, but > what it really needs is a nice, consistent and defined interface that > can deal with non-interactive external programs. /me shrugs. I don't find the CGI interface so bad to deal with; of course, parsing the returned data is sucky, but parsing XML is sucky as well and the upside is that it works now. Of course, a real interface would be much better, but we don't have one right now (and I'm not volunteering to work on one ATM either). > The upside of doing it is that the CVS commit would be instantaneous, > rather than having to wait for the script to finish talking to bz (which > as we all know can take a while). It would also cope better with bz > being down or otherwise unavailable. Well, you say below you're using an email interface, so the CVS commit would have to wait, at the most, for email to be dispatched, right? > > What about some bz->bonsai autolinking while we're at that? :-) > > Shouldn't be too hard. Surely it should just be a case of coming up with > what links you want for files and versions and changing the URLs we use > to something else. Then again, I know very little about bonsai, apart > from that it makes bz look pretty by comparison. To be honest, the links should probably have the same syntax and just point to different servers depending on which system you have installed. A simple param could configure if we've got bonsai, viewcvs or cvsweb, for instance. > The delivery method from cvs to the script that bungs things into bz: We > use email, and this new method uses a custom server. How does the CVS loginfo script talk to the custom server? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From mkgnu at gmx.net Tue Jun 1 21:58:29 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Tue, 01 Jun 2004 14:58:29 -0700 Subject: Scmbug In-Reply-To: <20040601211051.GB647@async.com.br> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> <20040601144130.GH813@async.com.br> <20040601161353.GT30765@software.plasmon> <20040601211051.GB647@async.com.br> Message-ID: <1086127109.1395.65.camel@syd.mkgnu.net> > > The delivery method from cvs to the script that bungs things into bz: We > > use email, and this new method uses a custom server. > > How does the CVS loginfo script talk to the custom server? It transports a message such as the following: [=======================] mkgnu 61,62 activity_verify Verification test now.. Affected files: --------------- test/test_file.txt 1.34 --> 1.22 SCMBUG_QUIT_END_TOKEN [=======================] Note that the username of the user commiting is transported (a better security scheme is needed). The custom server maps usernames to actual email addresses (bugzilla usernames) and calls functions provided in globals.pl. The custom server reads the mysql database username/password from a configuration file, and uses that with globals.pl. From jth at mikrobitti.fi Wed Jun 2 07:45:19 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Wed, 02 Jun 2004 10:45:19 +0300 Subject: Scmbug In-Reply-To: <20040601211051.GB647@async.com.br> References: <20040601161353.GT30765@software.plasmon> <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> <20040601144130.GH813@async.com.br> <20040601161353.GT30765@software.plasmon> Message-ID: <5.1.0.14.2.20040602104502.03d67c30@mikrobitti.fi> At 18:10 1.6.2004 -0300, you wrote: >course, parsing the returned data is sucky, but parsing XML is sucky >as well and the upside is that it works now. What do you mean by "parsing XML is sucky"? Jouni From dswegen at software.plasmon.com Thu Jun 3 08:01:48 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Thu, 3 Jun 2004 09:01:48 +0100 Subject: Scmbug In-Reply-To: <20040601211051.GB647@async.com.br> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> <20040601144130.GH813@async.com.br> <20040601161353.GT30765@software.plasmon> <20040601211051.GB647@async.com.br> Message-ID: <20040603080147.GW30765@software.plasmon> On Tue, Jun 01, 2004 at 06:10:51PM -0300, Christian Robottom Reis wrote: > On Tue, Jun 01, 2004 at 05:13:54PM +0100, Dave Swegen wrote: > > I had a look at it a while back, and the main bit that needs doing is > > cleaning up the interface (the --dont_change-- stuff is somewhat grotty, > > and I seem to recall that adding comments wasn't working). I haven't > > really had time to get the hang of what is going on in process_bug.cgi. > > As I said, I think justdave's script might already handle this part. Ah, sorry, didn't realise you meant that part. I'll try and get round to looking at it again. > > > Also, if an error is encountered while submitting changes to multiple > > bugs the process stops as soon as the error is encountered, rather than > > printing an error and continuing. For the purposes of the cvs->bz > > script, this would be bad (mainly for performance reasons). > > What sort of error? As soon as an attempt is made to modify a non-existant bug for instance, processing will stop. For this sort of thing it would be better if it spat out the error, but continued. That way the cvs->bz script would only have to be run once, and not have to be restarted after every error. I have got part of the way to modifying process_bug to do this, but got stuck when trying to figure out how to actually display the errors. > > > The horrible truth is that we can hack all sorts of stuff into bz, but > > what it really needs is a nice, consistent and defined interface that > > can deal with non-interactive external programs. > > /me shrugs. I don't find the CGI interface so bad to deal with; of > course, parsing the returned data is sucky, but parsing XML is sucky > as well and the upside is that it works now. > > Of course, a real interface would be much better, but we don't have one > right now (and I'm not volunteering to work on one ATM either). Same goes here, so I'll try and work with the current interface. > > > The upside of doing it is that the CVS commit would be instantaneous, > > rather than having to wait for the script to finish talking to bz (which > > as we all know can take a while). It would also cope better with bz > > being down or otherwise unavailable. > > Well, you say below you're using an email interface, so the CVS commit > would have to wait, at the most, for email to be dispatched, right? I want to get shut of the email interface. It's a pain to set up, a potential DoS route, and doesn't work on win32 (depends on procmail, which I understand is nigh-on impossible to emulate on win32). > > > > What about some bz->bonsai autolinking while we're at that? :-) > > > > Shouldn't be too hard. Surely it should just be a case of coming up with > > what links you want for files and versions and changing the URLs we use > > to something else. Then again, I know very little about bonsai, apart > > from that it makes bz look pretty by comparison. > > To be honest, the links should probably have the same syntax and just > point to different servers depending on which system you have installed. > A simple param could configure if we've got bonsai, viewcvs or cvsweb, > for instance. ATM the param is simply a URL. Should be simple enough to change. Cheers Dave From mkgnu at gmx.net Thu Jun 3 17:15:56 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Thu, 03 Jun 2004 10:15:56 -0700 Subject: Scmbug In-Reply-To: <20040603080147.GW30765@software.plasmon> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> <20040601144130.GH813@async.com.br> <20040601161353.GT30765@software.plasmon> <20040601211051.GB647@async.com.br> <20040603080147.GW30765@software.plasmon> Message-ID: <1086277144.1266.3.camel@syd.mkgnu.net> > > /me shrugs. I don't find the CGI interface so bad to deal with; of Just something that's not clear to me yet: are you directly hitting the webserver (what you casually mention the CGI interface) to enter those cvs commit messages in bz using the email gateway? How do you "login" as the user that submitted the email? Or is this CGI interface a collection of functions that depend on reading the mysql username/password? From tgottlieb at atrc.sytexinc.com Thu Jun 3 19:13:55 2004 From: tgottlieb at atrc.sytexinc.com (tgottlieb) Date: 03 Jun 2004 15:13:55 -0400 Subject: configuring Message-ID: <1086290034.4685.4.camel@bug> When I run mozilla against IP/index.cgi, I gt a listing of the file not its execution. can somebody point me in the right direction? Tony From tgottlieb at atrc.sytexinc.com Thu Jun 3 19:20:59 2004 From: tgottlieb at atrc.sytexinc.com (tgottlieb) Date: 03 Jun 2004 15:20:59 -0400 Subject: PROBLEMS!! Message-ID: <1086290458.4882.1.camel@bug> Bugzilla has suffered an internal error. Please save this page and send it to THE MAINTAINER HAS NOT YET BEEN SET with details of what you were doing at the time this message appeared. URL: http://192.168.123.12/query.cgi Template->process() failed twice. First error: file error - cache failed to write search.html.tmpl: Error in tempfile() using data/template/en/default/search/XXXXXXXXXX: Parent directory (data/template/en/default/search/) is not writable at /usr/lib/perl5/site_perl/5.8.0/Template/Document.pm line 280 Second error: file error - cache failed to write code-error.html.tmpl: Error in tempfile() using data/template/en/default/global/XXXXXXXXXX: Parent directory (data/template/en/default/global/) is not writable at /usr/lib/perl5/site_perl/5.8.0/Template/Document.pm line 280 I get this msg when I: IP/query.cgi from Mozilla HELP!!!!!!! Tony From mabomail at libero.it Thu Jun 3 20:02:38 2004 From: mabomail at libero.it (MaboMail) Date: Thu, 03 Jun 2004 22:02:38 +0200 Subject: Perl_Tstack_sp_ptrI Message-ID: <200406032202380593.0073B9CB@mail.tin.it> I try to install BugZilla into a debian machine! When i run checksetup.pl i obtain this error "Checking user setup ... /usr/bonsaitools/bin/perl: relocation error: /usr/lib/perl5/auto/Template/Stash/XS/XS.so: undefined symbol: Perl_Tstack_sp_ptr" I have link /usr/bonsai/lib/perl with myperl executable! Some of you can help me? Wat i mus to do? Thanks Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Thu Jun 3 22:24:14 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 03 Jun 2004 23:24:14 +0100 Subject: PROBLEMS!! In-Reply-To: <1086290458.4882.1.camel@bug> References: <1086290458.4882.1.camel@bug> Message-ID: <40BFA50E.9090109@mozilla.org> tgottlieb wrote: > Template->process() failed twice. > First error: file error - cache failed to write search.html.tmpl: Error > in tempfile() using data/template/en/default/search/XXXXXXXXXX: Parent > directory (data/template/en/default/search/) is not writable at Are the permissions on the directory in the error message set so that the webserver user can write to it? Gerv From kristis.makris at asu.edu Tue Jun 1 18:57:04 2004 From: kristis.makris at asu.edu (Kristis Makris) Date: Tue, 01 Jun 2004 11:57:04 -0700 Subject: On Scmbug Message-ID: <1086116224.1394.41.camel@syd.mkgnu.net> Hello everyone, Thank to David Miller for suggesting I should signup in this mailing list. Here are some of my comments: > 1) (And this is the one that really annoyed me) If you want people to > use a tool that you've written, at least put a descriptive page up. Just Sadly, I share the same view. What have I become! I'm sorry, I didn't want this work to go to waste, and I'm awfully busy at the moment. This glue was in use for over 2 months and I just got around to at least announcing it. > 2) To be honest, I've pretty much gone off the idea of having the scm > system fiddling directly with the bz DB. The main problem is that as bz Whatever bz officially offers as an interface, I'll gladly use -- just name what that is. Including globals.pl and calling functionality from there seemed like the right thing to do. I was planning on emailing this list to request for the extra functions I wrote for Bugzilla to be included in globals.pl. I noticed there's a WWW::Bugzilla Perl module(with which I've experimented for a while), but that requires logging in through the web gui with the user credentials, and I'm not sure how I should retrieve the user password in an automated way. > 3) Using a daemon is potentially a nice solution. But how useable is > fork() on win32 systems? This is a consideration, as there are plenty of > bz users on win boxes (I know, sounds mad, doesn't it ;) Then I'll have to consider using threads -- thanks for the heads up. http://bugzilla.mkgnu.net/show_bug.cgi?id=264 > > 5) A common request we have is that when a single commit that covers > > files in multiple directories is made, only one message will be placed in > > bz. I couldn't see anything in your code that dealt with this, but if it > > isn't there you might want to keep that in mind. I still havn't come up > > with a nice clean solution to this. Hey I noticed that! I thought of waiting for a few seconds before a commit to group multiple checkins with the same message. I'll look into this at some point. Thanks. The real solution would be introducing atomic commits in CVS, but ... http://bugzilla.mkgnu.net/show_bug.cgi?id=265 > 4) (Related to the one above): Having an intermediary step that sits > between cvs and bz has two problems: One is that it is one extra step > which the user can muck up installing (though your solution is far nicer > than ours), and it may make things awkward from a networking POV (think > firewalls). I find this step required to support a generic scm -> bugtracking tool. Problem 2, can be solved through an ssh tunnel, or vpn, which is the real solution to the problem. > 6) Potential bug: I believe that the parsing of files,dirs and > versions in Glue.pm/prepare_activity_commit_from_CVS doesn't cope with > files or dirs with whitespace in them (it won't cope with commas either, but A solution to the commas problem was provided in: http://www.einval.com/~steve/software/cvs-bugzilla/ CVS was patched to handle them. I will look into this. http://bugzilla.mkgnu.net/show_bug.cgi?id=267 > 7) You might want to think about nicking our bz->viewcvs autolinking Thanks, I will. Are there any functions in globals.pl I can use ? http://bugzilla.mkgnu.net/show_bug.cgi?id=266 Thanks for the feedback and your time guys. Kristis From kristis.makris at asu.edu Thu Jun 3 19:22:05 2004 From: kristis.makris at asu.edu (Kristis Makris) Date: Thu, 03 Jun 2004 12:22:05 -0700 Subject: Scmbug Message-ID: <1086290525.1705.1.camel@syd.mkgnu.net> Hello, It looks like this message didn't get through the first time, so I'm resending. > 1) (And this is the one that really annoyed me) If you want people to > use a tool that you've written, at least put a descriptive page up. Just I'm sorry, I didn't want this work to go to waste, and I'm awfully busy at the moment. This glue was in use for over 2 months and I just got around to at least announcing it. > 2) To be honest, I've pretty much gone off the idea of having the scm > system fiddling directly with the bz DB. The main problem is that as bz Whatever bz officially offers as an interface, I'll gladly use -- just name what that is. Including globals.pl and calling functionality from there seemed like the right thing to do. I was planning on emailing this list to request for the extra functions I wrote for Bugzilla to be included in globals.pl. I noticed there's a WWW::Bugzilla Perl module(with which I've experimented for a while), but that requires logging in through the web gui with the user credentials, and I'm not sure how I should retrieve the user password in an automated way. > 3) Using a daemon is potentially a nice solution. But how useable is > fork() on win32 systems? This is a consideration, as there are plenty of > bz users on win boxes (I know, sounds mad, doesn't it ;) Then I'll have to consider using threads -- thanks for the heads up. http://bugzilla.mkgnu.net/show_bug.cgi?id=264 > > 5) A common request we have is that when a single commit that covers > > files in multiple directories is made, only one message will be placed in > > bz. I couldn't see anything in your code that dealt with this, but if it > > isn't there you might want to keep that in mind. I still havn't come up > > with a nice clean solution to this. Hey I noticed that! I thought of waiting for a few seconds before a commit to group multiple checkins with the same message. I'll look into this at some point. Thanks. The real solution would be introducing atomic commits in CVS, but ... http://bugzilla.mkgnu.net/show_bug.cgi?id=265 > 4) (Related to the one above): Having an intermediary step that sits > between cvs and bz has two problems: One is that it is one extra step > which the user can muck up installing (though your solution is far nicer > than ours), and it may make things awkward from a networking POV (think > firewalls). I find this step required to support a generic scm -> bugtracking tool. Problem 2, can be solved through an ssh tunnel, or vpn, which is the real solution to the problem. > 6) Potential bug: I believe that the parsing of files,dirs and > versions in Glue.pm/prepare_activity_commit_from_CVS doesn't cope with > files or dirs with whitespace in them (it won't cope with commas either, but A solution to the commas problem was provided in: http://www.einval.com/~steve/software/cvs-bugzilla/ CVS was patched to handle them. I will look into this. http://bugzilla.mkgnu.net/show_bug.cgi?id=267 > 7) You might want to think about nicking our bz->viewcvs autolinking Thanks, I will. Are there any functions in globals.pl I can use ? http://bugzilla.mkgnu.net/show_bug.cgi?id=266 Thanks for the feedback and your time guys. Kristis From paulo.casanova at link.pt Fri Jun 4 09:35:39 2004 From: paulo.casanova at link.pt (Paulo Casanova) Date: Fri, 04 Jun 2004 10:35:39 +0100 Subject: configuring In-Reply-To: <1086290034.4685.4.camel@bug> Message-ID: Are you accessing a local file ou though the web server? If you acess through a web server (you have an http://... URL) you should check you apache configuration (see if you can execute CGIs -- if you need help on this just say) and whether index.cgi has executable permissions. Can you execute it on a shell? (I'm assuming you're running on UNIX) Paulo On 6/3/04 20:13, "tgottlieb" wrote: > When I run mozilla against IP/index.cgi, I gt a listing of the file > > not its execution. can somebody point me in the right direction? > > Tony > > - > To view or change your list settings, click here: > From dswegen at software.plasmon.com Fri Jun 4 10:04:05 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Fri, 4 Jun 2004 11:04:05 +0100 Subject: On Scmbug In-Reply-To: <1086116224.1394.41.camel@syd.mkgnu.net> References: <1086116224.1394.41.camel@syd.mkgnu.net> Message-ID: <20040604100405.GH30765@software.plasmon> On Tue, Jun 01, 2004 at 11:57:04AM -0700, Kristis Makris wrote: > Hello everyone, > > Thank to David Miller for suggesting I should signup in this mailing > list. Here are some of my comments: > > > 1) (And this is the one that really annoyed me) If you want people to > > use a tool that you've written, at least put a descriptive page up. Just > > Sadly, I share the same view. What have I become! I'm sorry, I didn't want this work to go to waste, and I'm awfully busy at the moment. This glue was in use for over 2 months and I just got around to at least announcing it. Once again apologies for being so grumpy. I'm not normally _that_ bad. The bz->cvs integration could really do with more people, and scaring them off by being a miserable Monday morning grumpo is never a good idea. Welcome aboard :) > > > 2) To be honest, I've pretty much gone off the idea of having the scm > > system fiddling directly with the bz DB. The main problem is that as bz > > Whatever bz officially offers as an interface, I'll gladly use -- just > name what that is. Including globals.pl and calling functionality from > there seemed like the right thing to do. I was planning on emailing > this list to request for the extra functions I wrote for Bugzilla to > be included in globals.pl. I noticed there's a WWW::Bugzilla Perl > module(with which I've experimented for a while), but that requires > logging in through the web gui with the user credentials, and I'm not > sure how I should retrieve the user password in an automated way. The way I was going to this was by having a admin user who owns all commit messages. It's not as nice as having the comments owned by the respective commiters, but you get all the sql checking and db abstraction for free. It also solves one of the other big problems - mapping cvs usernames to bz logins. Your solution is workable, but I think the correct way of doing that sort of thing is by adding an extra field to the user table. Just putting the cvs login name, and also whatever username info the script at the cvs end can obtain from the system into the comment seems to me at least a reasonable compromise, at least until I feel brave enough to mess about with the bz schema. > > 4) (Related to the one above): Having an intermediary step that sits > > between cvs and bz has two problems: One is that it is one extra > > step which the user can muck up installing (though your solution is > > far nicer than ours), and it may make things awkward from a > > networking POV (think firewalls). > > I find this step required to support a generic scm -> bugtracking > tool. Problem 2, can be solved through an ssh tunnel, or vpn, which is > the real solution to the problem. Do you have a list of other bug trackers that you'd like to see supported? The only one I can think of that is worth pondering is gnats, but lets not give gnats users any more reason to stay with it ;) The other question is how many setups are actually going to have multiple SCMs talking to one bug tracker (or even more unlikely - the other way round)? And once you've solved the problem of a) getting the data from the scm, and b) getting it into the tracker anything in the middle that doesn't need to be there is simply potential maintainance and support problems. In the case of cvs->bz or svn->bz it gives you nothing. I also feel quite wary of having a long-running deamon process written in a scripting language (been there, done that). > > > 6) Potential bug: I believe that the parsing of files,dirs and > > versions in Glue.pm/prepare_activity_commit_from_CVS doesn't cope > > with files or dirs with whitespace in them (it won't cope with > > commas either, but > > A solution to the commas problem was provided in: > http://www.einval.com/~steve/software/cvs-bugzilla/ CVS was patched to You might want to use http://bugzilla.mozilla.org/show_bug.cgi?id=199116 instead, which is the canonical location for all work on the cvs->bz patches that I do. > handle them. I will look into this. > http://bugzilla.mkgnu.net/show_bug.cgi?id=267 That was a hacky solution that was the only thing we could think of at the time. Again, it simply adds to the complexity of getting the system set up, and that is something I quite desperatly want to get away from. Having people patch and recompile CVS is Wrong. It also breaks if there are quotes in filenames. By using the {Vsv} in the loginfo script this can be worked around. I've attached a version of the script I was working on that shows how to get the necessary information out. I believe it is at least as robust as the CVS patched version (I believe only a file consistsing of dots, numbers, and commas will break this method). To add to my points above about supporting multiple SCMs/bug trackers, I'd rather have a solution that supports a very limited (but common) selection setups, but which is as easy as is possibly to set up and maintain. > > > 7) You might want to think about nicking our bz->viewcvs autolinking > > Thanks, I will. Are there any functions in globals.pl I can use ? > http://bugzilla.mkgnu.net/show_bug.cgi?id=266 To get that working we added one new function to globals.pl, added some code to another function, and added some code to the parameters page. The patch should be straightforward enough. You will obviously have to modify the various regexps to match the format of your commit comments, but it shouldn't be too hard. > > Thanks for the feedback and your time guys. Kristis It's been very useful. I've been wanting to get some discussion on how to progress the integration bit for some time. Even if we don't end up working on the same system, it has allowed me to clarify some of my ideas, so thanks for your time :) I would love to see this stuff go into 2.20, if for no other reason that I can stop maintaining a pile of patches at that point (which reminds me - I really have to get the patches working with 2.18). I should also perhaps mention that my reason for doing this work in the first place was so that we could use bz at work: When we were looking at tracking systems the choice was between the god-awful TestTrack Pro (which mgmt loved) and bz. Bz won out because of the work we did. So my interest in handing the sort of serious vote-winning ammo that scm integration gives to inferior tracking systems is very limited. The next time I end up having to fight that battle I'd like to have a trump card up my sleeve, thankyou very much ;) Cheers Dave -------------- next part -------------- #!/usr/bin/perl -w # -*- Mode: perl; indent-tabs-mode: nil -*- # # The contents of this file are subject to the Mozilla Public # License Version 1.1 (the "License"); you may not use this file # except in compliance with the License. You may obtain a copy of # the License at http://www.mozilla.org/MPL/ # # Software distributed under the License is distributed on an "AS # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or # implied. See the License for the specific language governing # rights and limitations under the License. # # The Original Code is the Bugzilla Bug Tracking System. # # The Initial Developer of the Original Code is Plasmon Data Ltd # Portions created by Plasmon Data Ltd are Copyright (C) 2003 Plasmon # Data Ltd. All Rights Reserved. # # Contributor(s): Dave Swegen # Description: # Grotty script that takes a CVS log entry and mangles it into a comment # that is appended to the specified bug(s) in bugzilla. # The entry in CVSROOT/loginfo looks as follows: # ALL (echo ""; echo "Date: "`date`; cat) | $CVSROOT/CVSROOT/bugzilla-watcher $USER %{Vsv} # # $Id: bugzilla-watcher,v 1.1 2004/01/23 16:01:41 dsw Exp $ use strict; use DBI; my $db_host = 'localhost'; my $db_name = 'bugs'; my $db_port = ''; my $db_user = 'bugs'; my $db_pass = 'password'; my %userdict = ( 'dsw'=>'dswegen at software.plasmon.com' ); # Nicked from Bugzilla/DB.pm sub connect_main { my $dsn = "DBI:mysql:host=$db_host;database=$db_name;port=$db_port"; #$dsn .= ";mysql_socket=$db_sock" if $db_sock; return _connect($dsn); } # Nicked from Bugzilla/DB.pm sub _connect { my ($dsn) = @_; # connect using our known info to the specified db # Apache::DBI will cache this when using mod_perl my $dbh = DBI->connect($dsn, $db_user, $db_pass, { RaiseError => 1, PrintError => 0, ShowErrorStatement => 1, HandleError => \&_handle_error, FetchHashKeyName => 'NAME_lc', TaintIn => 1, }); return $dbh; } # Nicked from Bugzilla/DB.pm sub _handle_error { require Carp; $_[0] = Carp::longmess($_[0]); return 0; # Now let DBI handle raising the error } # Checks to see if user is known, and if so returns login to use sub validate_userid { my $user = $_[0]; if (! exists $userdict{$user}) { print "No matching login for user id $user.\n"; exit(0); } my $sql = 'SELECT userid FROM profiles WHERE login_name=?'; if (undef ($dbh->selectrow_array($sql, undef, $userdict{$user})) { print "Login for user id $userdict{$user} not found\n"; exit(0); } return $userdict{$user}; } sub validate_bugs { foreach my $bug (@bugslist) { #"SELECT userid FROM profiles WHERE login_name = \'$SenderShort\';") # Handle input from CVS. The command line looks something like this: # user module/dir1/dir2 1.1,file1,1.2 ,, ... my $cvsuser = shift @ARGV; my ($moddir, $rest) = ($ARGV[0] =~ / ^(.*?) # Directory name \s+ ([\d\.]+,.*) # Rest of input $ /x); # DEBUG print "argv = $ARGV[0]\n"; # If it simply a new directory being added we can quit out # Of course we're buggered if someone decides to call a file # '- New directory' ;) if ($rest =~ /- New directory/) { exit (0) } #DEBUG print "moddir= $moddir rest = $rest\n"; # Filearr is a list of 'oldversion,filename,newversion' my @filearr = ($rest =~ /([\d\.]+,.*?,[\d\.]+)/g); my (@lines) = readline(*STDIN); chomp @lines; my ($bug, $tag, $i, @rawlog); my $done = 0; # Process everything before actual log while (! $done) { if ($lines[0] =~ /Log Message/) { $done = 1; shift @lines; } elsif ($lines[0] =~ s/^\s*Tag:\s*(.*)$/$1/) { $tag = shift @lines; chomp $tag; } else { shift @lines; } } if (! $tag) { $tag = "HEAD"; } my $pad = ' '; while (@lines) { my (%bugdict); # Grab and handle the bug id if ($lines[0] =~ s/ ^BugID # This is a bug id line :? # Optional ':' \s* # Optional whitespace \#? # Optional '#' ([\d,\s]+) # One or more bug ids, separated by commas and or whitespace \s*/$1/xi) { my @bugids = ($lines[0] =~ /(\d+)/g); # Make sure there are no dupes in there foreach my $i (@bugids) { $bugdict{$i} = 1; } $bug = join(' ', keys %bugdict); print "Appending log to bug(s) $bug\n"; shift @lines; } elsif ($lines[0] =~ /^BugID:?\s*.*$/i) { print "BugID line found, but invalid entry. Ignoring.\n"; push @rawlog, $pad . shift @lines; } else { push @rawlog, $pad . shift @lines; } } if (! $bug) { print "No bugID found. Not appending log message."; exit 0; } # Put all the lines in the logmessage into one string my $log = join("\n", at rawlog); my $filelines = ""; my $filename = ""; my (@line, $file, @files); # Process filenames and versions foreach my $arg (@filearr) { print "arg = $arg\n"; @line = split(",", $arg); # Commas in filenames screw things up:( $file = "$moddir/$line[1]\t$line[0] $line[2]"; # Get rid of whitespace-in-filename preserving quotes $file =~ s/\"//g; push @files, $file; } while (@files) { $filelines = $filelines . $pad . (shift @files) . "\n"; } # Remove trailing empty lines $/=""; # Remove various forms of whitespace $log =~ s/^\s+//s; $log =~ s/\s+$//s; $filelines =~ s/^\s+//s; $filelines =~ s/\s+$//s; $log = SqlQuote($log); my $clogmesg = "CVS COMMIT\nLOG MESSAGE:\n$pad$log\nBRANCH: $tag\nFILES CHECKED IN:\n$pad$filelines"; # Must work to here before proceeding # DEBUG print $clogmesg; # Try to connect my $dbh; $dbh = connect_main(); if (! defined $dbh) { print "Connection to DB failed\n"; exit 0; } # Check to see if user is known my $login = validate_user($cvsuser); my @bugs = validate_bugs(); From mkgnu at gmx.net Fri Jun 4 21:11:50 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Fri, 04 Jun 2004 14:11:50 -0700 Subject: On Scmbug In-Reply-To: <20040604100405.GH30765@software.plasmon> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> Message-ID: <1086383502.1338.4.camel@syd.mkgnu.net> > Once again apologies for being so grumpy. I'm not normally _that_ bad. I just spend 1:30 hours replying to this email and accidentally deleted it. Evolution my **#$% you piece of #$%)(**%^#@... ehem. I know you feel! This time my response is a lot shorter. > idea. Welcome aboard :) :) Mark and John, feel free to jump in here. > > > > > 2) To be honest, I've pretty much gone off the idea of having the scm > > > system fiddling directly with the bz DB. The main problem is that as bz > > > It also solves one of the other big problems - mapping cvs usernames to > bz logins. Your solution is workable, but I think the correct way of > doing that sort of thing is by adding an extra field to the user table. I do think its the right think to do. Where do you draw the line ? Will you add a one-to-many relation of files affected per bug and their version numbers ? What happens if gnats does not offers an extra field ? scmbugd can support either methods, or even do so according to the bugzilla version (what I have works for 2.14, but could be changed to behave differently for 2.20 if you add such a feature). What happens when some of us move a directory by hacking directly a CVS repository, and then decide they want that change reflected in bz. This a hack around a hack scenario, but I'm just throwing some ideas out there. > Do you have a list of other bug trackers that you'd like to see > supported? The only one I can think of that is worth pondering is gnats, > but lets not give gnats users any more reason to stay with it ;) Between you and me I agree, but I still want to keep this a generic "change management" activity with "logging" integration. This could be svn->bz, cvs->clearquest, rcs->blog or webpage, router config change -> bz, etc. Mark likes RCSing all configuration files in /etc, and I'm sure wouldn't oppose to some RCS to bz integration. > The other question is how many setups are actually going to have > multiple SCMs talking to one bug tracker (or even more unlikely - the I don't know, but why limit people's options when we don't have to ? (I can swear I had a stronger argument for this). I'd like to add support for once scmbugd supporting multiple glue->bugtracking connections, so that one daemon can integrate cvs->bz for some products, and svn->gnats for others (if that's what your new high-paying client uses!). (http://bugzilla.mkgnu.net/show_bug.cgi?id=279) > other way round)? And once you've solved the problem of a) getting the > data from the scm, and b) getting it into the tracker anything in the > middle that doesn't need to be there is simply potential maintainance > and support problems. Not quite simply. I've experienced such maintainance and support problems in the past by not having this middle man: 1 - setting the minimum characters of a log message is done once in the daemon, rather than in 17 glued repositories. Same for changing various checking policies, such as the status of the bug before you commit (may want to allow commits against "closed" or "confirmed" bugs). Same for changing the format of your commit messages, and adding other daemon features (emulate atomic cvs commits, moin-moin autolinking, etc.) 2 - What happens when you setup your own cvs repository on your laptop for testing, but your laptop username does not match the one used in your LAN for bz ? Having this extra authentication layer would permit Joe Schmoe to authenticate against his custom text file, or through other mechanisms, or not at all (in testing maybe ??)! 3 - Extracting changelog information should happen through scmbugd (http://bugzilla.mkgnu.net/show_bug.cgi?id=80 - I'm still thinking about this). Windows users would not be prohibited from getting such logs, only because they are missing a bunch of Perl libraries, and neither should Linux users need some graph drawing libs in their local workstations to create a changelog and make a product release. Scmbugd should take solve this problem in a central location. 4 - The glue code should generally be immutable, and have the backend daemon upgraded for newer functionality (I need to fix http://bugzilla.mkgnu.net/show_bug.cgi?id=213). Eg fixing a single 'quotes' bug on the daemon is better than fixing it in 17 repositories! 5 - You can hide your mysql database behing port filtering on the same machine scmbugd runs, rather than directly hit it from any repository location. 6 - I tried setting up the bz email gateway when I desperately needed it. My ISP was blocking port 25. With scmbugd I can configure the glue to connect to any port I want, and run scmbugd at any port I want. 7 - You get integration logs in /var/log/scmbug rather than look in sendmail or whathaveyou logs to see if your integration went through, and if not what the problem was. > In the case of cvs->bz or svn->bz it gives you nothing. I also feel It gives you a common source of upgrades (and everything mentioned above). scmbugd is also a common source for blocking development, but then so is bugzilla. At least you know that you are down, which is better than sending email without any notification of whether the bz commit succeeded. Notification from Scmbug is synchcronous. Worst case scenario, you can disable the glue. But at least you are conscious that you did that! It also permits scmbugd to solve some problems bz shouldn't have to deal with (and neither should gnats, or anybody else), such as cvs's lack of atomic commits. > quite wary of having a long-running deamon process written in a > scripting language (been there, done that). I haven't. What should I be careful of? > You might want to use http://bugzilla.mozilla.org/show_bug.cgi?id=199116 > instead, which is the canonical location for all work on the cvs->bz > patches that I do. Hey thanks! > That was a hacky solution that was the only thing we could think of at > the time. Again, it simply adds to the complexity of getting the system > set up, and that is something I quite desperatly want to get away from. > Having people patch and recompile CVS is Wrong. It also breaks if there > are quotes in filenames. Why isn't this fixed in the CVS codebase yet? > To add to my points above about supporting multiple SCMs/bug trackers, > I'd rather have a solution that supports a very limited (but common) > selection setups, but which is as easy as is possibly to set up and > maintain. There's an installation script for the glue, and the glue includes an "enabled" flag if you want to disable it. The scmbugd requires 1 configuration file, and the bugzilla source. You start it, it runs. Lets face it. You shouldn't have to provide a custom solution to a generic problem. You should use a generic solution, and customize it to your own environment. You shouldn't be providing such integration in bz. It's very much needed, but that's not where it belongs. > > > 7) You might want to think about nicking our bz->viewcvs autolinking ***Never***. I'd rather "reuse" one of your functions. I consider globals.pl your official interface, until you tell me otherwise! > To get that working we added one new function to globals.pl, added some > code to another function, and added some code to the parameters page. > The patch should be straightforward enough. Is this in 2.16 ? 2.18 ? What's the name of the function ? > I should also perhaps mention that my reason for doing this work in > the first place was so that we could use bz at work I needed this integration desperately, but frankly cvszilla, McIntere's work, and the email gateway just didn't work for me. Plus I could not reuse any of their source at all. Everybody assumed a certain schema, certain bz version, provided certain features I did not want and could not disable (cvszilla modified the bz schema!) or had some dirty code tangled up in blue. Lets solve this problem once and for all. Standardize on an integration protocol and interface. I was aiming for a svn -> bz integration (which is part of Mark's bigger plan for a change request tool), but wanted to get cvs working first, since that's what I was mostly familiar with and used John's integration before. Practically I just changed the design. The ideas for most of the goodies are his. > So my interest in handing the sort of serious vote-winning ammo that scm > integration gives to inferior tracking systems is very limited. The next > time I end up having to fight that battle I'd like to have a trump card > up my sleeve, thankyou very much ;) Thanks. I'd better get to work then! From mkgnu at gmx.net Sat Jun 5 01:11:46 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Fri, 04 Jun 2004 18:11:46 -0700 Subject: On Scmbug In-Reply-To: <20040604100405.GH30765@software.plasmon> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> Message-ID: <1086397906.1719.6.camel@syd.mkgnu.net> > The way I was going to this was by having a admin user who owns all > commit messages. It's not as nice as having the comments owned by the Any plans on handling the case where someone adds a directory, and CVS captures that activity with a commit trigger, but no opportunity for providing a log message is offered ? It probably shouldn't be handled, but I thought I might ask. From mkgnu at gmx.net Sat Jun 5 02:34:17 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Fri, 04 Jun 2004 19:34:17 -0700 Subject: On Scmbug In-Reply-To: <20040604100405.GH30765@software.plasmon> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> Message-ID: <1086402857.1799.37.camel@syd.mkgnu.net> > By using the {Vsv} in the loginfo script this can be worked around. I've > attached a version of the script I was working on that shows how to get > the necessary information out. I believe it is at least as robust as the > CVS patched version (I believe only a file consistsing of dots, numbers, > and commas will break this method). How about {Vvs} and [\d\.]+,[\d\.]+,.* ?? From mkgnu at gmx.net Sat Jun 5 03:15:05 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Fri, 04 Jun 2004 20:15:05 -0700 Subject: On Scmbug In-Reply-To: <1086402857.1799.37.camel@syd.mkgnu.net> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086402857.1799.37.camel@syd.mkgnu.net> Message-ID: <1086405305.1719.43.camel@syd.mkgnu.net> > > CVS patched version (I believe only a file consistsing of dots, numbers, > > and commas will break this method). > > How about {Vvs} and [\d\.]+,[\d\.]+,.* ?? Nevermind. We could get fancy thought and verify if new_version is = old_version + 1, and account for the case where either is NONE. Should at least give the user an error message letting them know whitespaces and commas will screw things up. If the synchronous nature of the glue forbids users from ever commiting such files, then it will no longer be a problem! From kristis.makris at asu.edu Sat Jun 5 03:48:12 2004 From: kristis.makris at asu.edu (Kristis Makris) Date: Fri, 04 Jun 2004 20:48:12 -0700 Subject: On Scmbug In-Reply-To: <1086405305.1719.43.camel@syd.mkgnu.net> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086402857.1799.37.camel@syd.mkgnu.net> <1086405305.1719.43.camel@syd.mkgnu.net> Message-ID: <1086407292.1797.46.camel@syd.mkgnu.net> Also, in the current bugzilla-watcher script, this regex fails to capture the case where new files are added: my @filearr = ($rest =~ /([\d\.]+,.*?,[\d\.]+)/g); eg the case where cvs passes: 'test NONE,test,1.1 NONE,test2,1.1' From dswegen at software.plasmon.com Mon Jun 7 07:05:49 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Mon, 7 Jun 2004 08:05:49 +0100 Subject: On Scmbug In-Reply-To: <1086405305.1719.43.camel@syd.mkgnu.net> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086402857.1799.37.camel@syd.mkgnu.net> <1086405305.1719.43.camel@syd.mkgnu.net> Message-ID: <20040607070549.GL30765@software.plasmon> (I'm dealing with the short easy replies first :) On Fri, Jun 04, 2004 at 08:15:05PM -0700, Kristis Makris wrote: > > > CVS patched version (I believe only a file consistsing of dots, numbers, > > > and commas will break this method). > > > > How about {Vvs} and [\d\.]+,[\d\.]+,.* ?? > > Nevermind. We could get fancy thought and verify if new_version is = > old_version + 1, and account for the case where either is NONE. Should > at least give the user an error message letting them know whitespaces > and commas will screw things up. If the synchronous nature of the glue > forbids users from ever commiting such files, then it will no longer be > a problem! Try explaining that to some PHB who insists on committing his powerpoint opus for posterity... Also, does CVS guarantee that version numbers will increment in a predictable fashion? This hurts my brain too much. Cheers Dave From dswegen at software.plasmon.com Mon Jun 7 07:20:03 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Mon, 7 Jun 2004 08:20:03 +0100 Subject: On Scmbug In-Reply-To: <1086407292.1797.46.camel@syd.mkgnu.net> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086402857.1799.37.camel@syd.mkgnu.net> <1086405305.1719.43.camel@syd.mkgnu.net> <1086407292.1797.46.camel@syd.mkgnu.net> Message-ID: <20040607072003.GM30765@software.plasmon> On Fri, Jun 04, 2004 at 08:48:12PM -0700, Kristis Makris wrote: > Also, in the current bugzilla-watcher script, this regex fails to > capture the case where new files are added: > > my @filearr = ($rest =~ /([\d\.]+,.*?,[\d\.]+)/g); > > eg the case where cvs passes: > > 'test NONE,test,1.1 NONE,test2,1.1' I haven't tried it, but this may work: my @filearr = ($rest =~ /(([\d\.]+|NONE),.*?,[\d\.]+))/g); Otherwise simply doing a sub of '\sNONE,' for ' 0.0,' or somesuch before splitting the input would probably do the trick (Yay! Another icky hack!). 0.0 would then be shorthand for no version. Cheers Dave From dswegen at software.plasmon.com Mon Jun 7 07:22:21 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Mon, 7 Jun 2004 08:22:21 +0100 Subject: On Scmbug In-Reply-To: <1086397906.1719.6.camel@syd.mkgnu.net> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086397906.1719.6.camel@syd.mkgnu.net> Message-ID: <20040607072221.GN30765@software.plasmon> On Fri, Jun 04, 2004 at 06:11:46PM -0700, Kristis Makris wrote: > > > The way I was going to this was by having a admin user who owns all > > commit messages. It's not as nice as having the comments owned by the > > Any plans on handling the case where someone adds a directory, and CVS > captures that activity with a commit trigger, but no opportunity for > providing a log message is offered ? > > It probably shouldn't be handled, but I thought I might ask. As I recall we simply ignore any added files/dirs in the script at the CVS end. Cheers Dave From asmodai at wxs.nl Mon Jun 7 07:44:18 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Mon, 7 Jun 2004 09:44:18 +0200 Subject: On Scmbug In-Reply-To: <20040607070549.GL30765@software.plasmon> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086402857.1799.37.camel@syd.mkgnu.net> <1086405305.1719.43.camel@syd.mkgnu.net> <20040607070549.GL30765@software.plasmon> Message-ID: <20040607074418.GF42455@nexus.ninth-circle.org> -On [20040607 09:12], Dave Swegen (dswegen at software.plasmon.com) wrote: >Try explaining that to some PHB who insists on committing his powerpoint >opus for posterity... *groan* >Also, does CVS guarantee that version numbers will >increment in a predictable fashion? This hurts my brain too much. At least Perforce and Subversion have repository wide changeset numbers. CVS gets real fun with branches. So you start with 1.1, you branch, you get 1.1.1.1. Of course, we also have imports, so 1.1.1 is possible too. At one point you create a branchpoint, so 1.57 for example, and when you then branch you could get 1.57.4.1. :S I am sure there's some logic there somewhere... -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Imitation is the sincerest form of flattery... From asmodai at wxs.nl Mon Jun 7 08:26:04 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Mon, 7 Jun 2004 10:26:04 +0200 Subject: Scmbug In-Reply-To: <16572.43874.368185.954336@tiphares.basistech.net> References: <1085962119.1380.0.camel@syd.mkgnu.net> <20040601104726.GQ30765@software.plasmon> <16572.43874.368185.954336@tiphares.basistech.net> Message-ID: <20040607082604.GG42455@nexus.ninth-circle.org> -On [20040601 18:22], Tom Emerson (tree at basistech.com) wrote: >This is where having an XML-RPC or SOAP interface to Bugzilla >functionality would be a Big Win: external tools could work with >Bugzilla nicely without having to track changes to the schemata. Just for educating the people on the list (heck, I haven't done anything with either SOAP or XML-RPC yet) just what the differences are between the two: How does XML-RPC differ from SOAP? o SOAP is asynchronous, XML-RPC is not o SOAP supports request routing and pre-processing of requests via SOAP headers o XML-RPC is lighter, taking up less bandwith, and requiring less processing power o SOAP is namespace-aware (in fact every element must be namespace-qualified) o SOAP has a heavy-weight, robust data typing mechanism based on XML Schemas o XML-RPC is easily sent and consumed, and is easily readable by humans o SOAP messages have a considerable amount of packaging contained in the envelope, but this allows for flexibility in the messaging paradigm used (publish-subscribe, point-to-point, etc.) When should I use XML-RPC vs using SOAP? Use XML-RPC when... o Speed is of greater importance than flexibility o Memory usage is a critical factor o Program size must be very small ( < 8kb ) o The data being exchanged is simple, or at very least the relationships between the data are simple o You need a neutral, standardized, lightweight mechanism for exchanging data, or remotely invoking some network service Use SOAP when... o Flexibility and a robust feature-set are a high priority o Program size and memory usage are less important than advanced networking features o The data being exchanged is complicated, the relationships between the data are complicated, or is it important to define custom data types o If you are uncertain which protocol will be used by potential clients and partners (SOAP is more popular, and thus a better bet in an uncertain situation) (source: http://kxmlrpc.enhydra.org/project/faq/) Furthermore: see http://www.xmlrpc.com/ and http://www.soaprpc.com/ Apache supports both XML-RPC as well as SOAP: http://ws.apache.org/xmlrpc/ http://ws.apache.org/soap/ -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Nobilitas sola est atque unica virtus... From benwei at veriwave.com Mon Jun 7 01:46:40 2004 From: benwei at veriwave.com (Ben) Date: Sun, 6 Jun 2004 18:46:40 -0700 Subject: Charts - empty image files Message-ID: <20040606184640.28df1ebc.benwei@veriwave.com> Hi, I have been using bugzilla 2.17.4 for a while, and the charts have always worked. However, after moving the installation to a new box, I am unable to see any charts. It turns out the gif files being created are just empty files. I have also upgraded to 2.17.6 and have experienced the same problem here. I don't think it is a permission issue because the files are being created, just not having anything written into them. Could it be some issue with the GD library on the new box, or is there something else that I'm missing? Thanks, Ben From kristis.makris at asu.edu Mon Jun 7 19:32:29 2004 From: kristis.makris at asu.edu (Kristis Makris) Date: Mon, 07 Jun 2004 12:32:29 -0700 Subject: Problem of commas/whitespaces in files/directories Message-ID: <1086636749.1262.1.camel@syd.mkgnu.net> I have a solution to the parsing problem that will allow commits of files and directories that include multiple commas or spaces with the maximum degree of tolerance CVS permits. I had to go with {Vvs} in loginfo: http://bugzilla.mkgnu.net/show_bug.cgi?id=286 An example of files/directories that were correctly parsed is at the end of http://bugzilla.mkgnu.net/show_bug.cgi?id=61 A test script for this is also available: http://bugzilla.mkgnu.net/showattachment.cgi?attach_id=28 From gerv at mozilla.org Mon Jun 7 22:38:26 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 07 Jun 2004 23:38:26 +0100 Subject: Charts - empty image files In-Reply-To: <20040606184640.28df1ebc.benwei@veriwave.com> References: <20040606184640.28df1ebc.benwei@veriwave.com> Message-ID: <40C4EE62.3020508@mozilla.org> Ben wrote: > Hi, I have been using bugzilla 2.17.4 for a while, and the charts > have always worked. However, after moving the installation to a new > box, I am unable to see any charts. You probably forgot to bring the "data" directory with you. That contains all the historical data. Gerv From benwei at veriwave.com Mon Jun 7 05:43:00 2004 From: benwei at veriwave.com (Ben) Date: Sun, 6 Jun 2004 22:43:00 -0700 Subject: Charts - empty image files In-Reply-To: <40C4EE62.3020508@mozilla.org> References: <20040606184640.28df1ebc.benwei@veriwave.com> <40C4EE62.3020508@mozilla.org> Message-ID: <20040606224300.399fee03.benwei@veriwave.com> Actually, I had thought of that, so I copied over the data dir, and also later tried doing a ./collectstats.pl --regenerate, but ended up with the same problem. On Mon, 07 Jun 2004 23:38:26 +0100 Gervase Markham wrote: > Ben wrote: > > Hi, I have been using bugzilla 2.17.4 for a while, and the charts > > have always worked. However, after moving the installation to a new > > box, I am unable to see any charts. > > You probably forgot to bring the "data" directory with you. That > contains all the historical data. > > Gerv > - > To view or change your list settings, click here: > From bruce.armstrong at teamsybase.com Tue Jun 8 02:19:52 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Mon, 7 Jun 2004 19:19:52 -0700 (PDT) Subject: Charts - empty image files In-Reply-To: <20040606224300.399fee03.benwei@veriwave.com> Message-ID: <20040608021952.45013.qmail@web12508.mail.yahoo.com> What version of GD and what version of Chart are you using? Support for the GIF chart format was taken out of those some time back, but you may be using a version of one that still support it and one that doesn't. Ben wrote:Actually, I had thought of that, so I copied over the data dir, and also later tried doing a ./collectstats.pl --regenerate, but ended up with the same problem. On Mon, 07 Jun 2004 23:38:26 +0100 Gervase Markham wrote: > Ben wrote: > > Hi, I have been using bugzilla 2.17.4 for a while, and the charts > > have always worked. However, after moving the installation to a new > > box, I am unable to see any charts. > > You probably forgot to bring the "data" directory with you. That > contains all the historical data. > > Gerv > - > To view or change your list settings, click here: > - To view or change your list settings, click here: Bruce Armstrong [TeamSybase] --------------------------------- http://www.teamsybase.com Preach the gospel at all times. If necessary, use words. -- Francis of Assisi http://www.needhim.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From benwei at veriwave.com Tue Jun 8 06:43:56 2004 From: benwei at veriwave.com (Ben Weintraub) Date: Mon, 07 Jun 2004 23:43:56 -0700 Subject: Charts - empty image files In-Reply-To: <20040608021952.45013.qmail@web12508.mail.yahoo.com> References: <20040608021952.45013.qmail@web12508.mail.yahoo.com> Message-ID: <1086677035.875.6.camel@pufferfish> GD is version 1.8.4, and the Chart module appears to be version 0.99. Another interesting thing that I just noticed is that I can get an image to appear if I use the 'New Charts' feature of 2.17.6 and I leave the date range blank. However, on the X-axis there is only one date (today) and no data points, so this is not very useful. Ben On Mon, 2004-06-07 at 19:19, Bruce Armstrong [TeamSybase] wrote: > What version of GD and what version of Chart are you using? Support > for the GIF chart format was taken out of those some time back, but > you may be using a version of one that still support it and one that > doesn't. > > Ben wrote: > Actually, I had thought of that, so I copied over the data > dir, and also later tried doing a ./collectstats.pl > --regenerate, but ended up with the same problem. > > On Mon, 07 Jun 2004 23:38:26 +0100 > Gervase Markham wrote: > > > Ben wrote: > > > Hi, I have been using bugzilla 2.17.4 for a while, and the > charts > > > have always worked. However, after moving the installation > to a new > > > box, I am unable to see any charts. > > > > You probably forgot to bring the "data" directory with you. > That > > contains all the historical data. > > > > Gerv > > - > > To view or change your list settings, click here: > > > - > To view or change your list settings, click here: > > > Bruce Armstrong [TeamSybase] > > ______________________________________________________________________ > http://www.teamsybase.com > > Preach the gospel at all times. > If necessary, use words. -- Francis of Assisi http://www.needhim.org From bruce.armstrong at teamsybase.com Tue Jun 8 13:57:56 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Tue, 8 Jun 2004 06:57:56 -0700 (PDT) Subject: Charts - empty image files In-Reply-To: <1086677035.875.6.camel@pufferfish> Message-ID: <20040608135756.34289.qmail@web12503.mail.yahoo.com> It actually matters what subversion of 0.99. Support for GIF was dropped and support for JPEG and PNG added with 0.99c: http://cpan.uwinnipeg.ca/htdocs/Chart/README.html Meanwhile, GD dropped support for GIF around 1.19: http://cpan.uwinnipeg.ca/htdocs/GD/README.html I'd suggest trying it with a later version of Chart. However, are you able to do non-date based charts? Perhaps the issue is you don't have the collectstats script running daily and that no data is being collected on a time basis. Ben Weintraub wrote: GD is version 1.8.4, and the Chart module appears to be version 0.99. Another interesting thing that I just noticed is that I can get an image to appear if I use the 'New Charts' feature of 2.17.6 and I leave the date range blank. However, on the X-axis there is only one date (today) and no data points, so this is not very useful. Ben On Mon, 2004-06-07 at 19:19, Bruce Armstrong [TeamSybase] wrote: > What version of GD and what version of Chart are you using? Support > for the GIF chart format was taken out of those some time back, but > you may be using a version of one that still support it and one that > doesn't. > > Ben wrote: > Actually, I had thought of that, so I copied over the data > dir, and also later tried doing a ./collectstats.pl > --regenerate, but ended up with the same problem. > > On Mon, 07 Jun 2004 23:38:26 +0100 > Gervase Markham wrote: > > > Ben wrote: > > > Hi, I have been using bugzilla 2.17.4 for a while, and the > charts > > > have always worked. However, after moving the installation > to a new > > > box, I am unable to see any charts. > > > > You probably forgot to bring the "data" directory with you. > That > > contains all the historical data. > > > > Gerv > > - > > To view or change your list settings, click here: > > > - > To view or change your list settings, click here: > > > Bruce Armstrong [TeamSybase] > > ______________________________________________________________________ > http://www.teamsybase.com > > Preach the gospel at all times. > If necessary, use words. -- Francis of Assisi http://www.needhim.org - To view or change your list settings, click here: Bruce Armstrong [TeamSybase] --------------------------------- http://www.teamsybase.com Preach the gospel at all times. If necessary, use words. -- Francis of Assisi http://www.needhim.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From benwei at veriwave.com Mon Jun 7 23:37:11 2004 From: benwei at veriwave.com (Ben) Date: Mon, 7 Jun 2004 16:37:11 -0700 Subject: Charts - empty image files In-Reply-To: <20040608135756.34289.qmail@web12503.mail.yahoo.com> References: <1086677035.875.6.camel@pufferfish> <20040608135756.34289.qmail@web12503.mail.yahoo.com> Message-ID: <20040607163711.36751880.benwei@veriwave.com> Hmm, well I'm not sure what subversion of Chart I have, but it does appear to work for non date-based charts, and for the new type of charts if I don't specify a date range, so it seems that this is not the problem. I'm sure the data for the charts is there, I just ran collectstats with the --regenerate option and manually checked the files. They have data going back almost 2 years. When doing the new charts I tried viewing just the image and adding the debug parameter onto ther URL, and here is what I got: Bugzilla::Chart object: $VAR1 = bless( { '_data' => [ [], [] ], 'lines' => [ [ bless( { 'frequency' => '1', 'subcategory' => '-All-', 'creator' => '0', 'query' => 'bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED', 'public' => '1', 'name' => 'All Open', 'category' => '-All-', 'series_id' => '320' }, 'Bugzilla::Series' ) ] ], 'datefrom' => '1041408000', 'cumulate' => 0, 'gt' => 0, 'labelgt' => undef, 'dateto' => '1072944000', 'labels' => [ 'All Open' ] }, 'Bugzilla::Chart' ); Content-Type: image/png I notice that the data part is empty, and I'm assuming this is the source of my trouble Ben On Tue, 8 Jun 2004 06:57:56 -0700 (PDT) "Bruce Armstrong \[TeamSybase\]" wrote: > It actually matters what subversion of 0.99. Support for GIF was dropped and support for JPEG and PNG added with 0.99c: > > http://cpan.uwinnipeg.ca/htdocs/Chart/README.html > > Meanwhile, GD dropped support for GIF around 1.19: > > http://cpan.uwinnipeg.ca/htdocs/GD/README.html > > I'd suggest trying it with a later version of Chart. > > However, are you able to do non-date based charts? Perhaps the issue is you don't have the collectstats script running daily and that no data is being collected on a time basis. From mkgnu at gmx.net Tue Jun 8 18:11:06 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Tue, 08 Jun 2004 11:11:06 -0700 Subject: On Scmbug In-Reply-To: <1086673263.1276.173.camel@hellcat.home.reibert.com> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086383502.1338.4.camel@syd.mkgnu.net> <1086673263.1276.173.camel@hellcat.home.reibert.com> Message-ID: <1086718266.10798.101.camel@syd.mkgnu.net> > Hmmm, I want to see how you get RCS->bz integration w/o the ability to > trigger in RCS! (I suppose you could wrap all the client commands, but > who wants to maintain that?) One could modify the RCS source to add support for consulting an RCS.conf that is local to a directory (or maybe from /etc). When such a file is present, the rcs commands could execute triggers as specified an that file. I'm coming to you with solutions, not problems! > As I wrote above, you lose flexibility in this sort of centralization. > Maybe I want different minimum-length comments and checkin policies for > each repository ... I think you need both. You should have that flexibility, by specifying a minimum-length size in each repository. You should also have the option to override this collectively for all repositories. > > 3 - Extracting changelog information should happen through scmbugd > I need to think about this too, but my gut feeling is this should not be > the domain of the integration tool. However, I reserve the right to > change my mind! I think there's room for a separate "release tool" that creates Changelog information, verifies all the files you are packaging in a tar.gz have been tagged, verify all source files include the appropriate license, verify all bugs worked are in a closed/fixed state (or according to some other policy) etc. I have a separate script I use to release scmbug that may be of interest. > In my perfect world the integration glue uses only the published API of > the change-request tool (web service, socket connection, etc.). Hacking How do you handle in your perfect world upgrades in the published API when the glue has not been upgraded in the repository ? > CVS's lack of atomic commits will be rendered irrelevant when Subversion > replaces it as the de-facto standard for open-source projects. I am not > being religious here, I just can't see the world sticking with CVS when > there is a better tool available. (Of course, there is quite a bit of > inertia to overcome ...) I agree here. But this may not be an option for everyone. > difficult in, say, Subversion as "tags" are simply tree copies. The > point here is the intersection between the revision-control and > change-request tools varies with the products and can drive the design > of the integration code. > >From the technical side, why a daemon? As I mentioned above, scmbugd is Primarily because Bugzilla's current public API is the globals.pl file, and I'm assuming other tools also lack a publicly accessible API. I'm calling functions out of globals.pl, rather than sent sql statements that assume a certain schema. I had to add some new functions I'm planning on submitting for inclusion to Bugzilla as part of their API. I prefer to wrap around other people's APIs with what you call a "glue to change-request API" today, rather than wait for everyone else to make theirs truly public (ala WebDAV). Since the assumption that the bugzilla source is uncompressed on each machine that hosts a CVS repository is a little far-fetched, I'm requiring that source only on the machine scmbugd runs. This seems to work in practise. I have various integrated local repositories on my laptop, and some publicly hosted for joint work with others. I have one publicly accessible Bugzilla instance, and its mysql datatabase behind port filtering. As to why I picked a TCP daemon rather than a different service (e.g. WebDAV)... there's no WebDAV chapter in my Perl book, and with minimum research a barebones daemon was coded in less than a couple of hours (I was coding this over Spring break, needed it desperately and had the whole thing working over a weekend). I think some separation of a "glue to change-request API" is valuable, but the daemon could be replaced with a WebDAV service. > Some day I will send you a diagram of my high-level architecture ideas. Hehe. My "today" argument is gaining momentum! Also, John's integration was never publicly released, but an equivalent solution should be available, and cvszilla just didn't work. From benwei at veriwave.com Tue Jun 8 01:34:18 2004 From: benwei at veriwave.com (Ben) Date: Mon, 7 Jun 2004 18:34:18 -0700 Subject: Charts - empty image files In-Reply-To: <20040607163711.36751880.benwei@veriwave.com> References: <1086677035.875.6.camel@pufferfish> <20040608135756.34289.qmail@web12503.mail.yahoo.com> <20040607163711.36751880.benwei@veriwave.com> Message-ID: <20040607183418.57bda11b.benwei@veriwave.com> Solved. It appears that there were two seperate problems here. For the old style charts, the problem really was my version of the Chart module, despite the fact that the non-date-based charts worked fine. For the new style, the problem was a lack of understanding on my part. I didn't realized that the method for collecting stats had changed. Thanks for your help Bruce and Gerv. Ben On Mon, 7 Jun 2004 16:37:11 -0700 Ben wrote: > Hmm, well I'm not sure what subversion of Chart I have, but it does appear to work for non date-based charts, and for the new type of charts if I don't specify a date range, so it seems that this is not the problem. I'm sure the data for the charts is there, I just ran collectstats with the --regenerate option and manually checked the files. They have data going back almost 2 years. When doing the new charts I tried viewing just the image and adding the debug parameter onto ther URL, and here is what I got: > > Bugzilla::Chart object: > $VAR1 = bless( { > '_data' => [ > [], > [] > ], > 'lines' => [ > [ > bless( { > 'frequency' => '1', > 'subcategory' => '-All-', > 'creator' => '0', > 'query' => 'bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED', > 'public' => '1', > 'name' => 'All Open', > 'category' => '-All-', > 'series_id' => '320' > }, 'Bugzilla::Series' ) > ] > ], > 'datefrom' => '1041408000', > 'cumulate' => 0, > 'gt' => 0, > 'labelgt' => undef, > 'dateto' => '1072944000', > 'labels' => [ > 'All Open' > ] > }, 'Bugzilla::Chart' ); > > Content-Type: image/png > > I notice that the data part is empty, and I'm assuming this is the source of my trouble > Ben > > On Tue, 8 Jun 2004 06:57:56 -0700 (PDT) > "Bruce Armstrong \[TeamSybase\]" wrote: > > > It actually matters what subversion of 0.99. Support for GIF was dropped and support for JPEG and PNG added with 0.99c: > > > > http://cpan.uwinnipeg.ca/htdocs/Chart/README.html > > > > Meanwhile, GD dropped support for GIF around 1.19: > > > > http://cpan.uwinnipeg.ca/htdocs/GD/README.html > > > > I'd suggest trying it with a later version of Chart. > > > > However, are you able to do non-date based charts? Perhaps the issue is you don't have the collectstats script running daily and that no data is being collected on a time basis. > > - > To view or change your list settings, click here: > From mark at reibert.com Tue Jun 8 05:41:03 2004 From: mark at reibert.com (Mark Reibert) Date: Mon, 07 Jun 2004 22:41:03 -0700 Subject: On Scmbug In-Reply-To: <1086383502.1338.4.camel@syd.mkgnu.net> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086383502.1338.4.camel@syd.mkgnu.net> Message-ID: <1086673263.1276.173.camel@hellcat.home.reibert.com> On Fri, 2004-06-04 at 14:11, Kristis Makris wrote: > > idea. Welcome aboard :) > > :) > > Mark and John, feel free to jump in here. Kristis et. al., I am obviously picking up the pieces of this thread, so I'll just kick in some random thoughts as I read along. > > It also solves one of the other big problems - mapping cvs usernames to > > bz logins. Your solution is workable, but I think the correct way of > > doing that sort of thing is by adding an extra field to the user table. > > I do think its the right think to do. Where do you draw the line ? Will > you add a one-to-many relation of files affected per bug and their > version numbers ? What happens if gnats does not offers an extra field ? > scmbugd can support either methods, or even do so according to the > bugzilla version (what I have works for 2.14, but could be changed to > behave differently for 2.20 if you add such a feature). What happens when some of us move a directory by hacking directly a CVS repository, and then decide they want that change reflected in bz. This a hack around a hack scenario, but I'm just throwing some ideas out there. The only hope for versatility is not to require changes in the change-request tool (such as name mapping, etc.). I realize the necessity of something like this can be successfully argued under certain scenarios, but it should be resisted at all costs. The same can be written for the revision-control tool. The integration glue should not be concerned with, for example, CVS repository hacks. If you start down that path you will find there is no end to the vicious cycle. (Of course, if you find the need to hack around the tool too often then you should consider another tool! BTW, did you see the Samba guys have moved to Subversion?) > > Do you have a list of other bug trackers that you'd like to see > > supported? The only one I can think of that is worth pondering is gnats, > > but lets not give gnats users any more reason to stay with it ;) > > Between you and me I agree, but I still want to keep this a generic > "change management" activity with "logging" integration. This could be > svn->bz, cvs->clearquest, rcs->blog or webpage, router config change -> > bz, etc. Mark likes RCSing all configuration files in /etc, and I'm sure wouldn't oppose to some RCS to bz integration. Hmmm, I want to see how you get RCS->bz integration w/o the ability to trigger in RCS! (I suppose you could wrap all the client commands, but who wants to maintain that?) > > The other question is how many setups are actually going to have > > multiple SCMs talking to one bug tracker (or even more unlikely - the > > I don't know, but why limit people's options when we don't have to ? (I > can swear I had a stronger argument for this). I'd like to add support > for once scmbugd supporting multiple glue->bugtracking connections, so > that one daemon can integrate cvs->bz for some products, and svn->gnats > for others (if that's what your new high-paying client uses!). > (http://bugzilla.mkgnu.net/show_bug.cgi?id=279) Postponing for the moment the larger discussion on whether or not the integration glue should run in a daemon, I don't see the need to have a one-size-fits-all scmbugd. scmbugd is just a piece of the glue. You still need glue between the revision-control tool and scmbugd (usually in the form of triggers) and between scmbugd and the change-request tool (in the form of some kind of code to map the scmbugd requests onto requests the change-request tool understands). What do we gain by running this for every combination of revision-control and change-request tool in one instance of the daemon? Generally this sort of centralization eases maintenance at the expense of flexibility, reliability, and "robustness". > > other way round)? And once you've solved the problem of a) getting the > > data from the scm, and b) getting it into the tracker anything in the > > middle that doesn't need to be there is simply potential maintainance > > and support problems. > > Not quite simply. I've experienced such maintainance and support > problems in the past by not having this middle man: > 1 - setting the minimum characters of a log message is done once in the > daemon, rather than in 17 glued repositories. Same for changing various > checking policies, such as the status of the bug before you commit (may > want to allow commits against "closed" or "confirmed" bugs). Same for > changing the format of your commit messages, and adding other daemon > features (emulate atomic cvs commits, moin-moin autolinking, etc.) As I wrote above, you lose flexibility in this sort of centralization. Maybe I want different minimum-length comments and checkin policies for each repository ... > 2 - What happens when you setup your own cvs repository on your laptop > for testing, but your laptop username does not match the one used in > your LAN for bz ? Having this extra authentication layer would permit > Joe Schmoe to authenticate against his custom text file, or through > other mechanisms, or not at all (in testing maybe ??)! Not another passwd file to maintain ... > 3 - Extracting changelog information should happen through scmbugd > (http://bugzilla.mkgnu.net/show_bug.cgi?id=80 - I'm still thinking about > this). Windows users would not be prohibited from getting such logs, > only because they are missing a bunch of Perl libraries, and neither > should Linux users need some graph drawing libs in their local > workstations to create a changelog and make a product release. Scmbugd > should take solve this problem in a central location. I need to think about this too, but my gut feeling is this should not be the domain of the integration tool. However, I reserve the right to change my mind! > 5 - You can hide your mysql database behing port filtering on the same > machine scmbugd runs, rather than directly hit it from any repository > location. In my perfect world the integration glue uses only the published API of the change-request tool (web service, socket connection, etc.). Hacking directly in a DB is just asking for problems. > 7 - You get integration logs in /var/log/scmbug rather than look in sendmail or whathaveyou logs to see if your integration went through, and if not what the problem was. Yeah, whatever ... I get (administrative) logs somewhere. The real point is the client should be notified (by the means of the underlying revision-control tool) if the commit failed. Developers work in a revision-control tool - don't make anything that changes the implicit expectations. > > In the case of cvs->bz or svn->bz it gives you nothing. I also feel > > It gives you a common source of upgrades (and everything mentioned > above). scmbugd is also a common source for blocking development, but Yeah, well killing my pserver or svnserve or SVN WebDAV is pretty good at blocking development also! > then so is bugzilla. At least you know that you are down, which is better than > sending email without any notification of whether the bz commit > succeeded. Notification from Scmbug is synchcronous. Worst case scenario, you can disable the glue. But at least > you are conscious that you did that! It also permits scmbugd to solve some > problems bz shouldn't have to deal with (and neither should gnats, or anybody else), such as cvs's lack of atomic > commits. CVS's lack of atomic commits will be rendered irrelevant when Subversion replaces it as the de-facto standard for open-source projects. I am not being religious here, I just can't see the world sticking with CVS when there is a better tool available. (Of course, there is quite a bit of inertia to overcome ...) > > quite wary of having a long-running deamon process written in a > > scripting language (been there, done that). Performance may also be an issue under heavy loads. > I needed this integration desperately, but frankly cvszilla, McIntere's > work, and the email gateway just didn't work for me. Plus I could not reuse > any of their source at all. Everybody assumed a certain schema, certain bz > version, provided certain features I did not want and could not disable (cvszilla modified the > bz schema!) or had some dirty code tangled up in blue. Lets solve this > problem once and for all. Standardize on an integration protocol and > interface. I was aiming for a svn -> bz integration (which is part of Mark's bigger plan for a change request tool), but wanted to get > cvs working first, since that's what I was mostly familiar with and used > John's integration before. Practically I just changed the design. The ideas for most of the goodies are his. In terms of general comments, my interest is to create a SCM system from the viewpoint of the revision-control tool whereas the approach here is to tackle the problem in the eyes of the change-request tool. In an ideal world I suppose the distinction is largely academic in as much as all revision-control and change-request tools would speak the same language. But in practice the vantage point can be important. For example, I may want a "tagging" or "labeling" operation in my revision-control tool to add a "version" into the change-request tool (so that I can write bugs against that version). That works well if we use something like CVS, ClearCase, etc., but is significantly more difficult in, say, Subversion as "tags" are simply tree copies. The point here is the intersection between the revision-control and change-request tools varies with the products and can drive the design of the integration code. >From the technical side, why a daemon? As I mentioned above, scmbugd is really the glue between the glue - it connects the revision-control triggers to the change-request API. As such, there are a number of ways this could be implemented. I am curious as to why you chose a daemon. Some day I will send you a diagram of my high-level architecture ideas. (Right after I work 50+ hours, mow the yards, install some misters on the back patio, clean up the garage, replace the water main at my parents house, spend some time with the wife so she doesn't leave me, and finish trimming out the kitchen windows I installed over two years ago. Yes Kristis, I still haven't done that! ;-) Regards, Mark Reibert -- ---------------------- Mark S. Reibert, Ph.D. mark at reibert.com ---------------------- From dswegen at software.plasmon.com Thu Jun 10 07:56:17 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Thu, 10 Jun 2004 08:56:17 +0100 Subject: On Scmbug In-Reply-To: <1086383502.1338.4.camel@syd.mkgnu.net> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086383502.1338.4.camel@syd.mkgnu.net> Message-ID: <20040610075616.GO22978@software.plasmon> On Fri, Jun 04, 2004 at 02:11:50PM -0700, Kristis Makris wrote: > > > > 2) To be honest, I've pretty much gone off the idea of having the scm > > > > system fiddling directly with the bz DB. The main problem is that as bz > > > > > > It also solves one of the other big problems - mapping cvs usernames to > > bz logins. Your solution is workable, but I think the correct way of > > doing that sort of thing is by adding an extra field to the user table. > > I do think its the right think to do. Where do you draw the line ? Will The problem with that approach is that it becomes unmanageable for large installations. If, hypothetically, mozilla.org was to start using cvs integration it would mean that every time a dev with commit rights changes their email address/login, some admin would have to change their cvs->bz mapping too. That means that either you have to hack bz to notify the admin, or the user has to notify the admin. Both solutions are somewhat suboptimal. > > other way round)? And once you've solved the problem of a) getting the > > data from the scm, and b) getting it into the tracker anything in the > > middle that doesn't need to be there is simply potential maintainance > > and support problems. > > Not quite simply. I've experienced such maintainance and support > problems in the past by not having this middle man: > 1 - setting the minimum characters of a log message is done once in the > daemon, rather than in 17 glued repositories. Same for changing various > checking policies, such as the status of the bug before you commit (may > want to allow commits against "closed" or "confirmed" bugs). Same for > changing the format of your commit messages, and adding other daemon > features (emulate atomic cvs commits, moin-moin autolinking, etc.) > 2 - What happens when you setup your own cvs repository on your laptop > for testing, but your laptop username does not match the one used in > your LAN for bz ? Having this extra authentication layer would permit > Joe Schmoe to authenticate against his custom text file, or through > other mechanisms, or not at all (in testing maybe ??)! > 3 - Extracting changelog information should happen through scmbugd > (http://bugzilla.mkgnu.net/show_bug.cgi?id=80 - I'm still thinking about > this). Windows users would not be prohibited from getting such logs, > only because they are missing a bunch of Perl libraries, and neither > should Linux users need some graph drawing libs in their local > workstations to create a changelog and make a product release. Scmbugd > should take solve this problem in a central location. Yikes! This is way beyond anything that I was thinking of. I'll say this: You've certainly got ambition :) > 4 - The glue code should generally be immutable, and have the backend > daemon upgraded for newer functionality (I need to fix > http://bugzilla.mkgnu.net/show_bug.cgi?id=213). Eg fixing a single > 'quotes' bug on the daemon is better than fixing it in 17 repositories! That is a good point. It certainly scales better. But then how often do you have 17 cvs repositories that aren't on the same machine? If nothing else I might nick your approach of having stuff in libraries. > 5 - You can hide your mysql database behing port filtering on the same > machine scmbugd runs, rather than directly hit it from any repository > location. As I said, I believe talking directly to the DB is wrong (at least in the case of bz). > 6 - I tried setting up the bz email gateway when I desperately needed > it. My ISP was blocking port 25. With scmbugd I can configure the glue > to connect to any port I want, and run scmbugd at any port I want. > 7 - You get integration logs in /var/log/scmbug rather than look in sendmail or whathaveyou logs to see if your integration went through, and if not what the problem was. I quite agree: The mail interface is wrong. [stuff snipped] > > > quite wary of having a long-running deamon process written in a > > scripting language (been there, done that). > > I haven't. What should I be careful of? Oh, at the time (I think this was with perl 5.0-something), perl had really iffy signal-handling (and this was code that forked a lot). It meant that the daemon would crash randomly from anything between 2 minutes and 20 hours. I eventually figured it out, but only after hurling abuse at my monitor for a week. It sort of left me feeling nervous about these things :) > > That was a hacky solution that was the only thing we could think of at > > the time. Again, it simply adds to the complexity of getting the system > > set up, and that is something I quite desperatly want to get away from. > > Having people patch and recompile CVS is Wrong. It also breaks if there > > are quotes in filenames. > > Why isn't this fixed in the CVS codebase yet? I don't know if Steve has gotten it in yet (I'm pretty certain it goes in Debian's CVS packages). From what Steve has been telling me the CVS maintainers have changed the way the commitinfo stuff works, but I haven't looked at it. Apperently it is a far more sane way of doing these things. > > > To add to my points above about supporting multiple SCMs/bug trackers, > > I'd rather have a solution that supports a very limited (but common) > > selection setups, but which is as easy as is possibly to set up and > > maintain. > > There's an installation script for the glue, and the glue includes an > "enabled" flag if you want to disable it. The scmbugd requires 1 configuration file, > and the bugzilla source. You start it, it runs. > > Lets face it. You shouldn't have to provide a custom solution to a > generic problem. You should use a generic solution, and customize it to > your own environment. You shouldn't be providing such integration in bz. > It's very much needed, but that's not where it belongs. > > > > > 7) You might want to think about nicking our bz->viewcvs autolinking > > ***Never***. I'd rather "reuse" one of your functions. I consider > globals.pl your official interface, until you tell me otherwise! Aah. Maybe I should clarify things: When I say 'our' I don't mean bugzilla's, I mean 'the two employees of Plasmon Data Ltd who have hacked together some cvs-> integration stuff' :) Bugzilla has yet to accept any cvs integration stuff, and that includes the autolinking code. The code in question is in patch #3, and is subject to change. > > > To get that working we added one new function to globals.pl, added some > > code to another function, and added some code to the parameters page. > > The patch should be straightforward enough. > > Is this in 2.16 ? 2.18 ? What's the name of the function ? I've made versions of patch #3 for both 2.17.1 and 2.16.5, and plan on updating the patches to 2.18 soonish. Basically, my aims are as follow (I think): * Something that is simple to set up, and simple to maintain (both for me and the admin) * Something that works on the systems I'll most likely will be working on (bz, svn, cvs) * Something that simply puts formatted commit comments into bz. I have little interest in something that changes the bz db in any further ways via commit comments: There are too many ways that the bz db can get into an iffy state that way (we regularly have people committing against the wrong bug - I dread to think what it would be like if other changes could take place due to incorrect commitlog data). * Something that will go into bz proper, as I don't have the time to maintain a pile of external patches. But my primary problem on what should be done is that I have very little idea of what other people want in such a system. You said that our patches weren't enough, but Steve has had some feedback stating that the patches were spot-on. I just don't know... Anyway, it's taken me ages to reply to this, and I'm just wibbling now, so I'll stop :) Cheers Dave From asmodai at wxs.nl Thu Jun 10 07:35:06 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Thu, 10 Jun 2004 09:35:06 +0200 Subject: On Scmbug In-Reply-To: <1086718266.10798.101.camel@syd.mkgnu.net> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086383502.1338.4.camel@syd.mkgnu.net> <1086673263.1276.173.camel@hellcat.home.reibert.com> <1086718266.10798.101.camel@syd.mkgnu.net> Message-ID: <20040610073506.GA22748@nexus.ninth-circle.org> -On [20040608 20:22], Kristis Makris (mkgnu at gmx.net) wrote: >One could modify the RCS source to add support for consulting an >RCS.conf that is local to a directory (or maybe from /etc). When such a >file is present, the rcs commands could execute triggers as specified an >that file. I'm coming to you with solutions, not problems! Don't forget that not every system out there has the sources for the utilities they ship with the OS. I agree heavily with Mark on the source modification issue. Once you start down that slippery slope you'll find yourself maintaining the other software more than your own. :S >I think there's room for a separate "release tool" that creates >Changelog information, verifies all the files you are packaging in a >tar.gz have been tagged, verify all source files include the appropriate >license, verify all bugs worked are in a closed/fixed state (or >according to some other policy) etc. I have a separate script I use to >release scmbug that may be of interest. Don't forget that not everyone uses ChangeLog. In the BSD world it is almost not used. >> In my perfect world the integration glue uses only the published API of >> the change-request tool (web service, socket connection, etc.). Hacking > >How do you handle in your perfect world upgrades in the published API >when the glue has not been upgraded in the repository ? I hope I am understanding correctly, but that's why you need to take the data you have and make it agnostic to a specific piece of software, save your own. Also, APIs normally don't change out quickly under your feet, well, at least it will not if the developer has some experience doing real code. >> CVS's lack of atomic commits will be rendered irrelevant when Subversion >> replaces it as the de-facto standard for open-source projects. I am not >> being religious here, I just can't see the world sticking with CVS when >> there is a better tool available. (Of course, there is quite a bit of >> inertia to overcome ...) > >I agree here. But this may not be an option for everyone. Big advantage of CVS is the file hacking possibility. I have used CVS for a long period and even do/did some maintaining in FreeBSD and DragonFly, but for the new launch of TenDRA I switched to Subversion and for the occasional feature missing (diff -N) I haven't regretted it. But Subversion can also be overkill for some people, remember that CVS uses normal files so it in effect it is merely a client and daemon. Subversion has dependencies to APR and bdb at least. Of course, with fsfs things will change a bit. >> >From the technical side, why a daemon? As I mentioned above, scmbugd is > >Primarily because Bugzilla's current public API is the globals.pl file, >and I'm assuming other tools also lack a publicly accessible API. I'm >calling functions out of globals.pl, rather than sent sql statements >that assume a certain schema. That's good, assuming a certain schema is a sure way to hang yourself. >I had to add some new functions I'm planning on submitting for inclusion to >Bugzilla as part of their API. I prefer to wrap around other people's APIs >with what you call a "glue to change-request API" today, rather than wait >for everyone else to make theirs truly public (ala WebDAV). Since the >assumption that the bugzilla source is uncompressed on each machine that >hosts a CVS repository is a little far-fetched, I'm requiring that source >only on the machine scmbugd runs. DragonFly, FreeBSD, NetBSD, and OpenBSD all provide cvs in their base install. Patching this every time is cumbersome since a CVSup will replace the files with the original ones again. Of course, often they have a global NO_CVS make variable which disables building it and installnig a custom one. >As to why I picked a TCP daemon rather than a different service (e.g. >WebDAV)... there's no WebDAV chapter in my Perl book, and with minimum >research a barebones daemon was coded in less than a couple of hours (I >was coding this over Spring break, needed it desperately and had the >whole thing working over a weekend). I think some separation of a "glue >to change-request API" is valuable, but the daemon could be replaced >with a WebDAV service. Just for the record, the repository and bugzilla software do not necessarily have to reside on the same box! I know a lot of split set-ups. Also, I do not use WebDAV anywhere nor will I install it, since I do not want nor need it. I find it less secure than using my repository over ssh. But that's just me. :) -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ All that we are is the result of what we have thought. The mind is everything. What we think, we become... From mike.morgan at oregonstate.edu Sat Jun 12 19:02:04 2004 From: mike.morgan at oregonstate.edu (Michael Joseph Morgan) Date: Sat, 12 Jun 2004 12:02:04 -0700 Subject: bugzilla features list Message-ID: <40CB532C.8070701@oregonstate.edu> Hi. I need some help with features for some of the content for the new site (http://website-beta.bugzilla.org). Please use bug 189613 to log comments and feature ideas: http://bugzilla.mozilla.org/show_bug.cgi?id=189613 Main Features -- On the front page, as with other products, we need to list the best features IN ENGLISH. Here are some examples: * Optimized database structure for increased performance and scalability * Excellent security to protect confidentiality * Custom query tool to save common searches * Integrated email capabilities * Editable user profiles and email preferences * Private comments * Comprehensive permissions system (for groups or individuals) * Proven reliability * Easily integrated with other management tools (CVS, Bonsai, etc.) * Easy-to-use, simple interface * Active development; Bugzilla is always getting better * Free future updates All < 2.16 Basic Features -- On the features page (http://website-beta.bugzilla.org/features/) we need to list features available up to and including version 2.16. This includes a lot of the basics, but we don't have any type of list so I'd like to come up with an _honest_ and comprehensive list of all basic features that were implemented and tested as of the 2.16 release. For everything after 2.16 we can go off of our status updates / release notes. Please focus on the features for now. Dave and I are working on other pages right now. Thanks everyone! Regards, Mike From justdave at bugzilla.org Sat Jun 12 19:26:29 2004 From: justdave at bugzilla.org (David Miller) Date: Sat, 12 Jun 2004 14:26:29 -0500 Subject: bugzilla features list In-Reply-To: <40CB532C.8070701@oregonstate.edu> References: <40CB532C.8070701@oregonstate.edu> Message-ID: <40CB58E5.6080300@bugzilla.org> Michael Joseph Morgan wrote: > I need some help with features for some of the content for the new site (http://website-beta.bugzilla.org). > > Please use bug 189613 to log comments and feature ideas: > http://bugzilla.mozilla.org/show_bug.cgi?id=189613 > > Main Features > -- > On the front page, as with other products, we need to list the best features IN ENGLISH. Here are some examples: To put Mike's request in plain English ;) What we need on the front page is a short and concise list of 10 or so of the best features Bugzilla has. These should be things that will pique a PHB's interest, and or make someone go "Wow, I need that". The existing list is stolen out of old documentation, and appears to be slightly embellished (there may be things in there that "yeah, you can do that, but it requires hacking" which probably shouldn't be there. On the actual features page, we need to list *everything* that can be considered a feature of Bugzilla, even if it makes it 15 pages long. :) This is the page they get when they click for *details* of course. :) The references to version 2.16 in Mike's request meant that we've kept pretty good track of the new features added since 2.16 by way of the new features announcements in the status updates. But we have very little record of what features exist that were implemented prior to 2.16. Coming up with a list like this is harder than it sounds, for people that have been using Bugzilla for a long time. We're used to everything Bugzilla does, so "what makes it unique" or "what several other trackers do that we do also" is hard to think up off the top of your head, because we know little else :) This would be a good topic for people on this list who have just recently dived into Bugzilla to help with. What made you choose Bugzilla? What does Bugzilla do that we should be advertising? -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From shiva.blacklist at sewingwitch.com Sat Jun 12 02:42:10 2004 From: shiva.blacklist at sewingwitch.com (Kenneth Porter) Date: Sat, 12 Jun 2004 02:42:10 +0000 (UTC) Subject: ft_min_word_len unrecognized on Red Hat >= 9 Message-ID: Installing Bugzilla 2.17.7 on Fedora Core 2. Following the installation guide, I set ft_min_word_len in my.cnf and got this error in /var/log/mysqld.log: /usr/libexec/mysqld: unrecognized option `--ft_min_word_len=2' Apparently I'm not the only one. Googling for this turned up this user with the problem on RH9: http://forums.devshed.com/t155106/s.html Looks like there's something fishy with Red Hat's mysql build. From mkgnu at gmx.net Mon Jun 14 18:22:00 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Mon, 14 Jun 2004 11:22:00 -0700 Subject: On Scmbug In-Reply-To: <20040610075616.GO22978@software.plasmon> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086383502.1338.4.camel@syd.mkgnu.net> <20040610075616.GO22978@software.plasmon> Message-ID: <1087237320.1409.47.camel@syd.mkgnu.net> On Thu, 2004-06-10 at 00:56, Dave Swegen wrote: > The problem with that approach is that it becomes unmanageable for large > installations. If, hypothetically, mozilla.org was to start using cvs > I quite agree: The mail interface is wrong. Assuming we all agree some level of cvs/svn integration with Bugzilla is needed, that the email interface is wrong, and that the cvs commits should not go through under certain conditions (e.g. commiting against bugs not assigned to you, or closed bugs), what would you recommend ? > That is a good point. It certainly scales better. But then how often do > you have 17 cvs repositories that aren't on the same machine? If nothing Perhaps if you are running Sourceforge and host a lot more repositories than that on multiple machines? I don't know. I'm trying to think ahead for cases we might be missing, and ensure scmbug will accomodate those. This is why I wrote this in the first place. ALL other solutions did not work for me. I'm sorry, I tried! They weren't flexible enough. As I also said before, I do have both local cvs repositories on my laptop, and remote ones on 2 other machines :) Designing integration glue that will not work in all cases even though you could with reasonably equal effort design one that works in all cases, already resulted in 3 integration glue efforts that did not work for ME :) Why limit our options when we don't have to ? > else I might nick your approach of having stuff in libraries. > I'd rather you didn't do that so casually. See below... > As I said, I believe talking directly to the DB is wrong (at least in > the case of bz). How should one talk to bugzilla for integration purposes ? See below... > > > Having people patch and recompile CVS is Wrong. It also breaks if there > > > are quotes in filenames. I think the stateful parser I posted earlier should now take care of commas and whitespaces in directories/files in a lot more cases without any changes needed in CVS. > hacked together some cvs-> integration stuff' :) Bugzilla has yet to > accept any cvs integration stuff, and that includes the autolinking > code. The code in question is in patch #3, and is subject to change. What is Bz's official position on how it would like to be integrated ? Should integration tools talk to some public WebDAV service provided by bz ? Directly to the DB ? Using the globals.pl file ? Is bz sticking with the email interface ? Will cvs/svn usernames be added in bz ? Is there a plan on making all this happen ? If there's no such plan, I'll have to continue working around globals.pl. > * Something that is simple to set up, and simple to maintain (both for me > and the admin) Agreed. > * Something that works on the systems I'll most likely will be working on > (bz, svn, cvs) Agreed. > * Something that simply puts formatted commit comments into bz. I have > little interest in something that changes the bz db in any further ways > via commit comments: There are too many ways that the bz db can get into > an iffy state that way (we regularly have people committing against the > wrong bug - I dread to think what it would be like if other changes I see you point here. See below... > could take place due to incorrect commitlog data). > * Something that will go into bz proper, as I don't have the time to > maintain a pile of external patches. > I couldn't agree more! > But my primary problem on what should be done is that I have very little > idea of what other people want in such a system. You said that our > patches weren't enough, but Steve has had some feedback stating that the > patches were spot-on. I just don't know... In summary, my secondary problem is that integration efforts developed so far will not work in 100% of all setups. My primary problem is that they are also designed in a way that does not permit them from being extended to capture all 100% of those cases, and nobody has addressed this issue. below: You may only be interested in having commit messages sent in bz, but from an scm-integration perspective I'm also interested in those being refused when a bug is closed, or assigned to someone else, or when the log size is less than 50 chars, and I need the cvs commit to fail if that's the case (so the email interface would not work for me). Again, that's why I wrote this. Do you think all those additional features should be developed in bugzilla, a bug tracking system, or as part of an scm-integration package ? How about allowing for integration developers to provide all the features requested by everyone, with the option of selectively choosing which features each user might want active ? As you mentioned, the only problem is that you don't know what's needed, and you shouldn't! Some scm-integration people should come to you saying "we want to add feature X, Y, and Z and we need this kind of support from bz". You should only implement the support, not the feature. For example, bz should provide a function called AppendToComment() that lets someone append commit messages to comments. But it shouldn't implement parsing of cvs commit messages. Another example (as we discovered) is that you should offer a mechanism for mapping cvs/svn usernames to bz email addresses. You should implement the SCVCUsername_To_BugzillaUsername() function, but nothing more. The point is that any work done towards improving bugzilla-watcher is a waste of time, since someone else will eventually need more features than the email gateway (or even a custom libraries approach) can provide. ALL those additional features should be developed somewhere else. Those features could be distributed in a custom-libraries fashion, a client/daemon scheme, or in any other way one might want to distribute them, but they should NOT be part of the bugzilla source tree. If you can build a reusable module providing the bugzilla support for integration, I could make it part of a local-libraries-only approach (or any other approach) that provides cvs/svn/anything else to bz integration. I already have a list of functions I need provided by Bugzilla. The major problem I have not addressed yet, is talking to bugzilla securely. Scmbugd will gladly accept any cvs username you tell it you are sending data from, and then contact the mysql db using globals.pl. If your DB and scmbugd are on the same machine, you don't have to send the mysql db username/password in cleartext over the web. If not, then this is still a problem regardless of whether you are using a daemon, or a local-libraries approach. I don't know how that should be handled. Perhaps talk to mysql securely (I haven't looked in their auth mechanisms yet -- having mysql exposed to everyone daes not sound like a good idea) ? Then, Bz must accept that the mysql db port will be publicly open, update their documentation to describe installation of mysql in that way, and talk to mysql over some secure authentication mechanism (that the integration glue can talk to as well). If WebDAV or any other public interface will be used, be that as it may, but still provide the designated way one should talk to bz. I can't do much in terms of redesigning scmbug unless bz answers some of these questions, and decides if it wants to support being integrated in a more extensive manner bugzilla-watcher allows. I'll gladly convert to some universally agreed design that will make everyone happy. But, at the moment what I have works with adequate security while all other integration efforts didn't. From jon at vmware.com Mon Jun 14 21:24:03 2004 From: jon at vmware.com (Jonathan Schatz) Date: Mon, 14 Jun 2004 14:24:03 -0700 Subject: ft_min_word_len unrecognized on Red Hat >= 9 In-Reply-To: References: Message-ID: <1087248243.22341.12.camel@jonschatz-lx.eng.vmware.com> are you sure you're using the right version of mysql? you need mysql >= 4.0 to use that environment variable: http://dev.mysql.com/doc/mysql/en/Fulltext_Fine-tuning.html -jon On Sat, 2004-06-12 at 02:42 +0000, Kenneth Porter wrote: > Installing Bugzilla 2.17.7 on Fedora Core 2. > > Following the installation guide, I set ft_min_word_len in my.cnf and got > this error in /var/log/mysqld.log: > > /usr/libexec/mysqld: unrecognized option `--ft_min_word_len=2' > > Apparently I'm not the only one. Googling for this turned up this user with > the problem on RH9: > > http://forums.devshed.com/t155106/s.html > > Looks like there's something fishy with Red Hat's mysql build. > > - > To view or change your list settings, click here: > -- Jonathan Schatz Technical Operations VMware, Inc "Te occidere possunt sed te edere non possunt nefas est." From shiva.blacklist at sewingwitch.com Tue Jun 15 21:50:32 2004 From: shiva.blacklist at sewingwitch.com (Kenneth Porter) Date: Tue, 15 Jun 2004 21:50:32 +0000 (UTC) Subject: ft_min_word_len unrecognized on Red Hat >= 9 References: <1087248243.22341.12.camel@jonschatz-lx.eng.vmware.com> Message-ID: Jonathan Schatz wrote in news:1087248243.22341.12.camel at jonschatz-lx.eng.vmware.com: > are you sure you're using the right version of mysql? you need mysql >= > 4.0 to use that environment variable: > > http://dev.mysql.com/doc/mysql/en/Fulltext_Fine-tuning.html So I've discovered. And Fedora doesn't ship with a v4 MySQL, so it's necessary to upgrade using the SRPM at the MySQL site. I found some bugs registered about this so I'll probably bite the bullet and upgrade the DB. From bugreport at peshkin.net Wed Jun 16 03:50:31 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 15 Jun 2004 20:50:31 -0700 Subject: Naming of system groups Message-ID: <40CFC387.2040908@peshkin.net> After discovering that the new system group, "admin" sometimes overlapped with an existing group on some sites, I would like to avoid this in the future. I am considering renaming all system groups to have a prefix (either "_" or "bz_" so that "editusers" would become "_editusers" or "bz_editusers") if we have consensus that all system groups should be required to follow such a convention. Opinions? From bugzilla at glob.com.au Wed Jun 16 04:47:17 2004 From: bugzilla at glob.com.au (bugzilla at glob.com.au) Date: Wed, 16 Jun 2004 12:47:17 +0800 (WST) Subject: Naming of system groups Message-ID: <20040616044717.A4EC989F65@click.bur.st> > I am considering renaming all system groups to have a prefix (either "_" > or "bz_" so that "editusers" would become "_editusers" or > "bz_editusers") if we have consensus that all system groups should be > required to follow such a convention. > > Opinions? i like _editusers. it's probably a good idea to restrict users from creating system-named groups (ie. forbid names begining with underscore). begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From kiko at async.com.br Wed Jun 16 13:51:10 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 16 Jun 2004 10:51:10 -0300 Subject: Naming of system groups In-Reply-To: <20040616044717.A4EC989F65@click.bur.st> References: <20040616044717.A4EC989F65@click.bur.st> Message-ID: <20040616135110.GF727@async.com.br> On Wed, Jun 16, 2004 at 12:47:17PM +0800, bugzilla at glob.com.au wrote: > > I am considering renaming all system groups to have a prefix (either "_" > > or "bz_" so that "editusers" would become "_editusers" or > > "bz_editusers") if we have consensus that all system groups should be > > required to follow such a convention. > > > > Opinions? > > i like _editusers. > > it's probably a good idea to restrict users from creating system-named groups > (ie. forbid names begining with underscore). Given that I suggested it, I like it too. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From justdave at bugzilla.org Wed Jun 16 14:23:35 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 16 Jun 2004 10:23:35 -0400 Subject: ft_min_word_len unrecognized on Red Hat >= 9 In-Reply-To: References: <1087248243.22341.12.camel@jonschatz-lx.eng.vmware.com> Message-ID: <40D057E7.9020800@bugzilla.org> Kenneth Porter wrote: > So I've discovered. And Fedora doesn't ship with a v4 MySQL, so it's > necessary to upgrade using the SRPM at the MySQL site. I found some bugs > registered about this so I'll probably bite the bullet and upgrade the DB. This was because of licensing issues... MySQL changed their license in 4.0, and the new license was just strict enough that RedHat couldn't legally distribute it. So RedHat stuck with 3.23.x. I've heard rumors that MySQL has since fixed that problem with the license, but since RedHat still has 3.23.x (even in Fedora Core 2), I don't know how true that is. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Wed Jun 16 14:40:18 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 16 Jun 2004 10:40:18 -0400 Subject: Naming of system groups In-Reply-To: <40CFC387.2040908@peshkin.net> References: <40CFC387.2040908@peshkin.net> Message-ID: <40D05BD2.9030709@bugzilla.org> Joel Peshkin wrote: > I am considering renaming all system groups to have a prefix (either "_" > or "bz_" so that "editusers" would become "_editusers" or > "bz_editusers") if we have consensus that all system groups should be > required to follow such a convention. The thing to watch out for here is people who have customized their Bugzilla using UserInGroup() tests... this kind of thing needs big bold letters in the release notes if we do it. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From myk at mozilla.org Wed Jun 16 17:19:16 2004 From: myk at mozilla.org (Myk Melez) Date: Wed, 16 Jun 2004 10:19:16 -0700 Subject: ft_min_word_len unrecognized on Red Hat >= 9 In-Reply-To: <40D057E7.9020800@bugzilla.org> References: <1087248243.22341.12.camel@jonschatz-lx.eng.vmware.com> <40D057E7.9020800@bugzilla.org> Message-ID: <40D08114.5030307@mozilla.org> David Miller wrote: > Kenneth Porter wrote: > >> So I've discovered. And Fedora doesn't ship with a v4 MySQL, so it's >> necessary to upgrade using the SRPM at the MySQL site. I found some >> bugs registered about this so I'll probably bite the bullet and >> upgrade the DB. > > > This was because of licensing issues... MySQL changed their license in > 4.0, and the new license was just strict enough that RedHat couldn't > legally distribute it. So RedHat stuck with 3.23.x. I've heard > rumors that MySQL has since fixed that problem with the license, but > since RedHat still has 3.23.x (even in Fedora Core 2), I don't know > how true that is. The last I heard the license problems weren't fixed, but regardless, I recommend using MySQL's RPMs instead of Red Hat's. Red Hat only updates MySQL for critical fixes and often does it by backporting fixes to its existing release, while MySQL regularly releases stable point versions with many bug fixes and stable feature enhancements. I find the stable MySQL RPMs better balance the twin needs for stability and enhancements. -myk From justdave at bugzilla.org Wed Jun 16 18:20:13 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 16 Jun 2004 14:20:13 -0400 Subject: ft_min_word_len unrecognized on Red Hat >= 9 In-Reply-To: <40D08114.5030307@mozilla.org> References: <1087248243.22341.12.camel@jonschatz-lx.eng.vmware.com> <40D057E7.9020800@bugzilla.org> <40D08114.5030307@mozilla.org> Message-ID: <40D08F5D.3050701@bugzilla.org> Myk Melez wrote: > The last I heard the license problems weren't fixed, but regardless, I > recommend using MySQL's RPMs instead of Red Hat's. Red Hat only updates > MySQL for critical fixes and often does it by backporting fixes to its > existing release, while MySQL regularly releases stable point versions > with many bug fixes and stable feature enhancements. I find the stable > MySQL RPMs better balance the twin needs for stability and enhancements. I agree. One thing you need to keep in mind when using MySQL's RPMs is that the DBD::mysql RPM provided by RedHat only works with RedHat's MySQL RPMs (when talking to a database server on the same machine - it'll still work fine if the DB server is remote). If you use MySQL's RPM for MySQL itself, make sure you reinstall DBD::mysql from CPAN *after* installing MySQL's RPMs. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From tyler at cryptio.net Wed Jun 16 18:37:09 2004 From: tyler at cryptio.net (Tyler) Date: Wed, 16 Jun 2004 11:37:09 -0700 Subject: ft_min_word_len unrecognized on Red Hat >= 9 In-Reply-To: References: <1087248243.22341.12.camel@jonschatz-lx.eng.vmware.com> Message-ID: <20040616183708.GA31279@cryptio.net> On Tue, Jun 15, 2004 at 09:50:32PM +0000, Kenneth Porter wrote: > > are you sure you're using the right version of mysql? you need mysql >= > > 4.0 to use that environment variable: > > > > http://dev.mysql.com/doc/mysql/en/Fulltext_Fine-tuning.html > > So I've discovered. And Fedora doesn't ship with a v4 MySQL, so it's > necessary to upgrade using the SRPM at the MySQL site. I found some bugs > registered about this so I'll probably bite the bullet and upgrade the DB. The install doc doesn't mention this requirement; in fact, it says: "You need MySQL version 3.23.41 or higher." What will the effect of not having this property be? The install docs say only this: "This causes a lot of Bugzilla specific words to be missed, including "cc", "ftp" and "uri"." Since it's index related, i'm guessing it will make some searches slower, but will it in fact break stuff? tyler From mkanat at kerio.com Wed Jun 16 19:44:56 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Wed, 16 Jun 2004 12:44:56 -0700 Subject: Naming of system groups In-Reply-To: <40D05BD2.9030709@bugzilla.org> References: <40CFC387.2040908@peshkin.net> <40D05BD2.9030709@bugzilla.org> Message-ID: <1087415095.3063.32.camel@localhost.localdomain> > The thing to watch out for here is people who have customized their > Bugzilla using UserInGroup() tests... this kind of thing needs big bold > letters in the release notes if we do it. :) Indeed. I would probably suggest that any groups that existed in 2.16 should have the same names as they did, and only groups added to 2.18 should have the underscore added. Or, if this change is happening in 2.20, do it for 2.20-added groups. Renaming things can cause a lot of pain. -Max From bugreport at peshkin.net Wed Jun 16 20:20:16 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 16 Jun 2004 13:20:16 -0700 Subject: Naming of system groups In-Reply-To: <1087415095.3063.32.camel@localhost.localdomain> References: <40CFC387.2040908@peshkin.net> <40D05BD2.9030709@bugzilla.org> <1087415095.3063.32.camel@localhost.localdomain> Message-ID: <40D0AB80.5090903@peshkin.net> Maxwell Kanat-Alexander wrote: >>The thing to watch out for here is people who have customized their >>Bugzilla using UserInGroup() tests... this kind of thing needs big bold >>letters in the release notes if we do it. :) >> >> > > Indeed. I would probably suggest that any groups that existed in 2.16 >should have the same names as they did, and only groups added to 2.18 >should have the underscore added. > > Or, if this change is happening in 2.20, do it for 2.20-added groups. > > Renaming things can cause a lot of pain. > > -Max > > > That makes a lot of sense. The only question in my mind is what to do about "admin" From mabomail at libero.it Thu Jun 17 12:52:33 2004 From: mabomail at libero.it (MaboMail) Date: Thu, 17 Jun 2004 14:52:33 +0200 Subject: Send mail In-Reply-To: <1087415095.3063.32.camel@localhost.localdomain> References: <40CFC387.2040908@peshkin.net> <40D05BD2.9030709@bugzilla.org> <1087415095.3063.32.camel@localhost.localdomain> Message-ID: <200406171452330500.01396B0B@mail.tin.it> Hello i install bugzilla in my server and now i try to use it! I'd like to implements this feature: I'd like taht the reporter do not received all mail of the bugs that he submitetd but only a mail when we close the bug! Is it possible? How I can configure my bugzilla server? Thanks! Matteo Bordin From mark at reibert.com Fri Jun 18 06:28:14 2004 From: mark at reibert.com (Mark Reibert) Date: Thu, 17 Jun 2004 23:28:14 -0700 Subject: On Scmbug In-Reply-To: <1087237320.1409.47.camel@syd.mkgnu.net> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086383502.1338.4.camel@syd.mkgnu.net> <20040610075616.GO22978@software.plasmon> <1087237320.1409.47.camel@syd.mkgnu.net> Message-ID: <1087540094.1276.39.camel@hellcat.home.reibert.com> On Mon, 2004-06-14 at 11:22, Kristis Makris wrote: > You may only be interested in having commit messages sent in bz, but > from an scm-integration perspective I'm also interested in those being > refused when a bug is closed, or assigned to someone else, or when the > log size is less than 50 chars, and I need the cvs commit to fail if > that's the case (so the email interface would not work for me). Again, > that's why I wrote this. Do you think all those additional features > should be developed in bugzilla, a bug tracking system, or as part of an > scm-integration package ? Part of the integration glue - see below. > How about allowing for integration developers to provide all the > features requested by everyone, with the option of selectively choosing > which features each user might want active ? As you mentioned, the only > problem is that you don't know what's needed, and you shouldn't! Some > scm-integration people should come to you saying "we want to add feature > X, Y, and Z and we need this kind of support from bz". You should only > implement the support, not the feature. For example, bz should provide a > function called AppendToComment() that lets someone append commit > messages to comments. But it shouldn't implement parsing of cvs commit > messages. Another example (as we discovered) is that you should offer a > mechanism for mapping cvs/svn usernames to bz email addresses. You > should implement the SCVCUsername_To_BugzillaUsername() function, but > nothing more. The point is that any work done towards improving > bugzilla-watcher is a waste of time, since someone else will eventually > need more features than the email gateway (or even a custom libraries > approach) can provide. ALL those additional features should be developed > somewhere else. Those features could be distributed in a > custom-libraries fashion, a client/daemon scheme, or in any other way > one might want to distribute them, but they should NOT be part of the > bugzilla source tree. below: The solution is to have the integration glue take care of the integration logic. (Earth shattering, I know! ;-) The revision-control and the change-management tools simply provide hooks and APIs that allow the glue to do its thing. On the revision-control side of things this means triggers. (Well, the trigger itself is part of the integration glue ... the *ability* to trigger is what we get from the tool.) With respect to the change-management tool, we need an API that allows us to both query and update the system. This should take the form of a web service, WebDAV, socket, or something that allows the glue to work both from local and remote installations. (bz's globals.pl is not sufficient because it cannot be accessed remotely.) Whatever we put between the trigger and the change-management API (Kristis' daemon, a library call, etc.) is glue implementation detail. So, what does this mean for our hypothetical bz API? Well, we definitely need functions like AddComment(), GetBugOwner(), GetBugState(), etc., but we do not want something like SCVCUsername_To_BugzillaUsername(). This is integration glue stuff - if the glue needs to translate user names then it is the responsibility of the glue to manage the mapping. All we have to do now is define the bz API! Mark -- ---------------------- Mark S. Reibert, Ph.D. mark at reibert.com ---------------------- From dswegen at software.plasmon.com Fri Jun 18 11:45:42 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Fri, 18 Jun 2004 12:45:42 +0100 Subject: On Scmbug In-Reply-To: <1087540094.1276.39.camel@hellcat.home.reibert.com> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086383502.1338.4.camel@syd.mkgnu.net> <20040610075616.GO22978@software.plasmon> <1087237320.1409.47.camel@syd.mkgnu.net> <1087540094.1276.39.camel@hellcat.home.reibert.com> Message-ID: <20040618114542.GB4627@software.plasmon> On Thu, Jun 17, 2004 at 11:28:14PM -0700, Mark Reibert wrote: > > So, what does this mean for our hypothetical bz API? Well, we definitely > need functions like AddComment(), GetBugOwner(), GetBugState(), etc., > but we do not want something like SCVCUsername_To_BugzillaUsername(). > This is integration glue stuff - if the glue needs to translate user > names then it is the responsibility of the glue to manage the mapping. I have to disagree with this: As I mentioned before in a previous mail, not having the mapping in the bugtracker scales very poorly. If you have any idea on how to work around that using a third party utility I'd be interested to hear it. Cheers Dave From shiva.blacklist at sewingwitch.com Fri Jun 18 23:58:47 2004 From: shiva.blacklist at sewingwitch.com (Kenneth Porter) Date: Fri, 18 Jun 2004 23:58:47 +0000 (UTC) Subject: ft_min_word_len unrecognized on Red Hat >= 9 References: <1087248243.22341.12.camel@jonschatz-lx.eng.vmware.com> <40D057E7.9020800@bugzilla.org> <40D08114.5030307@mozilla.org> <40D08F5D.3050701@bugzilla.org> Message-ID: David Miller wrote in news:40D08F5D.3050701 at bugzilla.org: > One thing you need to keep in mind when using MySQL's RPMs is > that the DBD::mysql RPM provided by RedHat only works with RedHat's > MySQL RPMs (when talking to a database server on the same machine - > it'll still work fine if the DB server is remote). If you use MySQL's > RPM for MySQL itself, make sure you reinstall DBD::mysql from CPAN > *after* installing MySQL's RPMs Thanks for the heads-up. To continue to keep everything registered in the RPM database, one should use RPM::Specfile to build CPAN modules as RPM's and then install them. Once RPM::Specfile is installed, you can quickly build CPAN RPM's with "cpanflute2 --buildall cpanmodulename.tar.gz". From gerv at mozilla.org Sat Jun 19 11:58:01 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 19 Jun 2004 12:58:01 +0100 Subject: Naming of system groups In-Reply-To: <1087415095.3063.32.camel@localhost.localdomain> References: <40CFC387.2040908@peshkin.net> <40D05BD2.9030709@bugzilla.org> <1087415095.3063.32.camel@localhost.localdomain> Message-ID: <40D42A49.7060609@mozilla.org> Maxwell Kanat-Alexander wrote: > Indeed. I would probably suggest that any groups that existed in 2.16 > should have the same names as they did, and only groups added to 2.18 > should have the underscore added. The problem with that is that we get inconsistencies going forward. How about we rename them all, but continue to accept the legacy names of current ones in UserInGroup(), using a simple mapping table? Lastly, the problem with the names currently is that they are exposed in the UI - which makes me less keen on the _ prefix, because it's ugly and not immediately human-understandable. Could we not prefix with bugzilla_ or system_ instead? Gerv From mkgnu at gmx.net Mon Jun 21 16:43:33 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Mon, 21 Jun 2004 09:43:33 -0700 Subject: On Scmbug In-Reply-To: <20040618114542.GB4627@software.plasmon> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086383502.1338.4.camel@syd.mkgnu.net> <20040610075616.GO22978@software.plasmon> <1087237320.1409.47.camel@syd.mkgnu.net> <1087540094.1276.39.camel@hellcat.home.reibert.com> <20040618114542.GB4627@software.plasmon> Message-ID: <1087836213.1502.4.camel@syd.mkgnu.net> I think Mark wasn't CC'ed in this. > On Thu, Jun 17, 2004 at 11:28:14PM -0700, Mark Reibert wrote: > > This is integration glue stuff - if the glue needs to translate user > > names then it is the responsibility of the glue to manage the mapping. On Mon, 2004-06-07 at 22:41, Mark Reibert wrote: > Not another passwd file to maintain ... ! On Fri, 2004-06-18 at 04:45, Dave Swegen wrote: > I have to disagree with this: As I mentioned before in a previous mail, > not having the mapping in the bugtracker scales very poorly. If you have > On Thu, 2004-06-10 at 00:56, Dave Swegen wrote: > The problem with that approach is that it becomes unmanageable for large > installations. If, hypothetically, mozilla.org was to start using cvs > integration it would mean that every time a dev with commit rights > changes their email address/login, some admin would have to change their > cvs->bz mapping too. That means that either you have to hack bz to Is that a bad thing ? Is the bz email changing, or is the scm integration email changing, causing a respective change in the bz email/login ? Besides, bz could keep a chain of email addresses and eventually accept integration requests to older email addresses. Is it a good policy to simply trash older email addresses used as logins in bz ? From mkanat at kerio.com Mon Jun 21 17:18:28 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Mon, 21 Jun 2004 10:18:28 -0700 Subject: Naming of system groups In-Reply-To: <40D42A49.7060609@mozilla.org> References: <40CFC387.2040908@peshkin.net> <40D05BD2.9030709@bugzilla.org> <1087415095.3063.32.camel@localhost.localdomain> <40D42A49.7060609@mozilla.org> Message-ID: <1087838308.2942.5.camel@localhost.localdomain> > How about we rename them all, but continue to accept the legacy names of > current ones in UserInGroup(), using a simple mapping table? Yeah, I agree with that. But then this definitely needs a release note, so that somebody doesn't say something like, "I made a group called editusers and it does strange things!" And it also needs a migration script in checksetup. Oh, and for everybody who's customized their Bugzilla (which is pretty much everybody), if they've used the old groupnames manually in their own functions or schema, they will break... -Max From justdave at bugzilla.org Mon Jun 21 18:07:32 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 21 Jun 2004 14:07:32 -0400 Subject: ft_min_word_len unrecognized on Red Hat >= 9 In-Reply-To: <20040616183708.GA31279@cryptio.net> References: <1087248243.22341.12.camel@jonschatz-lx.eng.vmware.com> <20040616183708.GA31279@cryptio.net> Message-ID: <40D723E4.20204@bugzilla.org> Tyler wrote: > The install doc doesn't mention this requirement; in fact, it says: We need to get a note on that in the docs saying the setting is only available in 4.x and what the side effects are in 3.23 without it (as mentioned below: > "You need MySQL version 3.23.41 or higher." > > What will the effect of not having this property be? The install docs > say only this: > > "This causes a lot of Bugzilla specific words to be missed, including > "cc", "ftp" and "uri"." > > Since it's index related, i'm guessing it will make some searches > slower, but will it in fact break stuff? It won't affect the search speed at all. As noted, without it, words with fewer than 4 characters won't get indexed. In 3.23.x, you couldn't change the minimum word size for full text indexing, it was always 4 characters. In 4.x you can change the minimum word size using that setting. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From tyler at cryptio.net Mon Jun 21 18:14:37 2004 From: tyler at cryptio.net (Tyler) Date: Mon, 21 Jun 2004 11:14:37 -0700 Subject: ft_min_word_len unrecognized on Red Hat >= 9 In-Reply-To: <40D723E4.20204@bugzilla.org> References: <1087248243.22341.12.camel@jonschatz-lx.eng.vmware.com> <20040616183708.GA31279@cryptio.net> <40D723E4.20204@bugzilla.org> Message-ID: <20040621181437.GE27573@cryptio.net> On Mon, Jun 21, 2004 at 02:07:32PM -0400, David Miller wrote: > >What will the effect of not having this property be? The install docs > >say only this: > > > >"This causes a lot of Bugzilla specific words to be missed, including > >"cc", "ftp" and "uri"." > > > >Since it's index related, i'm guessing it will make some searches > >slower, but will it in fact break stuff? > > It won't affect the search speed at all. As noted, without it, words > with fewer than 4 characters won't get indexed. In 3.23.x, you couldn't > change the minimum word size for full text indexing, it was always 4 > characters. In 4.x you can change the minimum word size using that setting. What's the point of indexing those words if it doesn't have an effect on search speed? Just because you can? :P tyler From justdave at bugzilla.org Mon Jun 21 19:17:07 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 21 Jun 2004 15:17:07 -0400 Subject: ft_min_word_len unrecognized on Red Hat >= 9 In-Reply-To: <20040621181437.GE27573@cryptio.net> References: <1087248243.22341.12.camel@jonschatz-lx.eng.vmware.com> <20040616183708.GA31279@cryptio.net> <40D723E4.20204@bugzilla.org> <20040621181437.GE27573@cryptio.net> Message-ID: <40D73433.6090803@bugzilla.org> Tyler wrote: > On Mon, Jun 21, 2004 at 02:07:32PM -0400, David Miller wrote: > >>>What will the effect of not having this property be? The install docs >>>say only this: >>> >>>"This causes a lot of Bugzilla specific words to be missed, including >>>"cc", "ftp" and "uri"." >>> >>>Since it's index related, i'm guessing it will make some searches >>>slower, but will it in fact break stuff? >> >>It won't affect the search speed at all. As noted, without it, words >>with fewer than 4 characters won't get indexed. In 3.23.x, you couldn't >>change the minimum word size for full text indexing, it was always 4 >>characters. In 4.x you can change the minimum word size using that setting. > > What's the point of indexing those words if it doesn't have an effect on > search speed? Just because you can? :P Guess I should clarify that... on 3.23 it won't have an effect. Yes, on 4.0, the lower you drop that number, the longer it'll take to run searches on it (because the index will be bigger). The speed difference doesn't seem to be a whole lot on bugzilla.mozilla.org though. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Tue Jun 22 04:04:37 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 22 Jun 2004 00:04:37 -0400 Subject: 2.18 Release Notes Message-ID: <40D7AFD5.2070208@bugzilla.org> We need a volunteer to take on the task of updating the release notes for the 2.18 release. It's likely going to be a sizable job, because they've hardly been touched since 2.16 released, and Bugzilla has changed a lot since then. We have over two years worth of changes to condense into a readable form. There's a general overview of what needs to be done at http://www.bugzilla.org/releasenotesguide.html The bug that goes with this is http://bugzilla.mozilla.org/show_bug.cgi?id=150149 And so everyone knows, this *is* blocking the 2.18 release candidates, so we won't be releasing until it's done. I have no objections to multiple people sharing the job if you want to split it up. :) Any volunteers? -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From asmodai at wxs.nl Tue Jun 22 04:49:08 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Tue, 22 Jun 2004 06:49:08 +0200 Subject: 2.18 Release Notes In-Reply-To: <40D7AFD5.2070208@bugzilla.org> References: <40D7AFD5.2070208@bugzilla.org> Message-ID: <20040622044908.GA34024@nexus.ninth-circle.org> -On [20040622 06:12], David Miller (justdave at bugzilla.org) wrote: >We need a volunteer to take on the task of updating the release notes >for the 2.18 release. [snip] >And so everyone knows, this *is* blocking the 2.18 release candidates, >so we won't be releasing until it's done. I have no objections to >multiple people sharing the job if you want to split it up. :) I wouldn't mind trying my hand at this. What's the time frame in which you want to have something tangible? -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Reality is an illusion, grimmer. The dreamlands are like masks within masks, and Time has no dominion beyond the Shroud... From justdave at bugzilla.org Tue Jun 22 04:54:17 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 22 Jun 2004 00:54:17 -0400 Subject: 2.18 Release Notes In-Reply-To: <20040622044908.GA34024@nexus.ninth-circle.org> References: <40D7AFD5.2070208@bugzilla.org> <20040622044908.GA34024@nexus.ninth-circle.org> Message-ID: <40D7BB79.6020900@bugzilla.org> Jeroen Ruigrok/asmodai wrote: > -On [20040622 06:12], David Miller (justdave at bugzilla.org) wrote: > >>And so everyone knows, this *is* blocking the 2.18 release candidates, >>so we won't be releasing until it's done. I have no objections to >>multiple people sharing the job if you want to split it up. :) > > I wouldn't mind trying my hand at this. Cool! > What's the time frame in which you want to have something tangible? Well, the sooner the better. Within a week would be nice, but if that's enough rush to impact quality, I'll wait. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From asmodai at wxs.nl Thu Jun 24 04:59:14 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Thu, 24 Jun 2004 06:59:14 +0200 Subject: Should Bugzilla 2.18 require Perl 5.6.1? In-Reply-To: <40A0D634.4010108@bugzilla.org> References: <408DE4C0.70708@bugzilla.org> <409FBF0A.7030708@bugzilla.org> <20040511064325.GJ553@nexus.ninth-circle.org> <40A0D634.4010108@bugzilla.org> Message-ID: <20040624045914.GO34024@nexus.ninth-circle.org> -On [20040511 15:42], David Miller (justdave at bugzilla.org) wrote: [Higher Perl version 'n Unicode] >Although working Unicode support (as much as Bugzilla needs) can be >accomplished with Perl 5.6.1, as long as you don't need to do character >set conversions. But inbound email support will likely require charset >conversions (because we'll need to convert whatever charset the email is >in to Unicode before putting it in the database). Any conversion code >from legacy databases would certainly require 5.8 as well. Inbound email support isn't for 2.18, right? So for 2.18 we can stil get away with 5.6.x, but the requirement for 2.20 will be 5.8.x? -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Nothing is constant but change... From justdave at bugzilla.org Fri Jun 25 07:49:28 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 25 Jun 2004 03:49:28 -0400 Subject: Should Bugzilla 2.18 require Perl 5.6.1? In-Reply-To: <20040624045914.GO34024@nexus.ninth-circle.org> References: <408DE4C0.70708@bugzilla.org> <409FBF0A.7030708@bugzilla.org> <20040511064325.GJ553@nexus.ninth-circle.org> <40A0D634.4010108@bugzilla.org> <20040624045914.GO34024@nexus.ninth-circle.org> Message-ID: <40DBD908.1090103@bugzilla.org> Jeroen Ruigrok/asmodai wrote: > Inbound email support isn't for 2.18, right? Right, that's not ready to land yet. > So for 2.18 we can stil get away with 5.6.x, but the requirement for 2.20 > will be 5.8.x? That sounds pretty good to me. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mark at reibert.com Sun Jun 27 06:40:18 2004 From: mark at reibert.com (Mark Reibert) Date: Sat, 26 Jun 2004 23:40:18 -0700 Subject: On Scmbug In-Reply-To: <1087836213.1502.4.camel@syd.mkgnu.net> References: <1086116224.1394.41.camel@syd.mkgnu.net> <20040604100405.GH30765@software.plasmon> <1086383502.1338.4.camel@syd.mkgnu.net> <20040610075616.GO22978@software.plasmon> <1087237320.1409.47.camel@syd.mkgnu.net> <1087540094.1276.39.camel@hellcat.home.reibert.com> <20040618114542.GB4627@software.plasmon> <1087836213.1502.4.camel@syd.mkgnu.net> Message-ID: <1088318417.1276.24.camel@hellcat.home.reibert.com> On Mon, 2004-06-21 at 09:43, Kristis Makris wrote: > > The problem with that approach is that it becomes unmanageable for > large > > installations. If, hypothetically, mozilla.org was to start using cvs > > integration it would mean that every time a dev with commit rights > > changes their email address/login, some admin would have to change their > > cvs->bz mapping too. That means that either you have to hack bz to > > Is that a bad thing ? Is the bz email changing, or is the scm integration > email changing, causing a respective change in the bz email/login ? > > Besides, bz could keep a chain of email addresses and eventually accept integration requests to older email addresses. Is it a good policy to simply trash older email addresses used as logins in bz ? Are we missing the obvious solution? The e-mail address should be an attribute (or metadata or whatever you want to call it) associated with the bz account; it should not be the account name/login itself. Then I can change me e-mail address all I want and never have to worry about updating the mapping between bz and revision-control tool X. I am sure there is a reason why bz prefers the often-changing e-mail address as the primary account information. Maybe the reason is no more complex than it really doesn't matter until you try to provide automated integration between bz and another tool? Mark -- ---------------------- Mark S. Reibert, Ph.D. mark at reibert.com ---------------------- From justdave at bugzilla.org Tue Jun 29 04:58:03 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 29 Jun 2004 00:58:03 -0400 Subject: Bugzilla Beta website Message-ID: <40E0F6DB.3010200@bugzilla.org> The preview version of the new www.bugzilla.org website is now available at http://website-beta.bugzilla.org/ This now has live data on it and not just a mock-up. Currently, with a few exceptions, this is the existing site redone with the new look and a new URL scheme. (and don't worry - I do plan on throwing a nice list of Apache rewrite rules on it to compensate for the existing URLs that are posted all over the planet which are changing) Now comes the task of reorganizing or adding to the content to get what people need access to posted on the site where they can find it. If you notice anything that doesn't look right, links that go to the wrong place, things that just shouldn't be there, etc, please speak up :) If you have ideas for content, please share them. The intention at this point is to move this to www.bugzilla.org near the same time as the 2.18 release (or perhaps one of the release candidates if it's ready that soon). We want the primary focus of the main page to be marketing-oriented at this point, but with the developer and administrator type stuff easily located. IF YOU HAVE CVS WRITE ACCESS TO THE WEBSITE, PLEASE NOTE: Since the beta website now has real data on it, if you update anything on the currently live website, make sure to also update the corresponding page on the beta website, or your changes will likely be lost when we make the beta site live. The beta site lives on the MOZILLA_ORG_BRANCH, and updates to website-beta on the same schedule as the live site. If you've made any changes on the live site, -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From asmodai at wxs.nl Tue Jun 29 14:09:07 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Tue, 29 Jun 2004 16:09:07 +0200 Subject: Bugzilla Beta website In-Reply-To: <40E0F6DB.3010200@bugzilla.org> References: <40E0F6DB.3010200@bugzilla.org> Message-ID: <20040629140907.GO1042@nexus.ninth-circle.org> -On [20040629 14:53], David Miller (justdave at bugzilla.org) wrote: >The preview version of the new www.bugzilla.org website is now available >at http://website-beta.bugzilla.org/ BIG improvement over the old site! I like it. Will it go live together with 2.18? :) -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Speak the sweet truth... From bz at barnson.org Wed Jun 30 16:32:13 2004 From: bz at barnson.org (Matthew P. Barnson) Date: Wed, 30 Jun 2004 10:32:13 -0600 Subject: 3-month contract in Salt Lake City Message-ID: <20040630163213.GN59630@barnson.org> A local recruiter is pinging me about finding Bugzilla expertise to work on Bugzilla and CVS (not integration of the two) for the next three months. Rate is $35-$50/hour W2, full-time. If you are interested, I'll put you in touch with the agent. Oh, and Dave: the new web site kicks ass compared to the old one. When are we going to get a Wiki? -- Matthew P. Barnson - - - - Thought for the moment: `Just the place for a Snark!' the Bellman cried, As he landed his crew with care; Supporting each man on the top of the tide By a finger entwined in his hair. 'Just the place for a Snark! I have said it twice: That alone should encourage the crew. Just the place for a Snark! I have said it thrice: What I tell you three times is true.' -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mike.morgan at oregonstate.edu Wed Jun 30 16:42:36 2004 From: mike.morgan at oregonstate.edu (Mike Morgan) Date: Wed, 30 Jun 2004 09:42:36 -0700 Subject: Bugzilla wiki? In-Reply-To: <20040630163213.GN59630@barnson.org> References: <20040630163213.GN59630@barnson.org> Message-ID: <40E2ED7C.700@oregonstate.edu> Matthew P. Barnson wrote: >When are we going to get a Wiki? > I have a lot of experience setting up phpwiki and mediawiki -- not that they requires experience. Just to say -- we use phpwiki at work, and have been very happy with how it works. It's very, very simple and gets the job done. Anyway, I think Matt has a point -- a wiki would be a very good tool. What other options are out there? What do you guys prefer? Mike From bz at barnson.org Wed Jun 30 16:49:22 2004 From: bz at barnson.org (Matthew P. Barnson) Date: Wed, 30 Jun 2004 10:49:22 -0600 Subject: Bugzilla wiki? In-Reply-To: <40E2ED7C.700@oregonstate.edu> References: <20040630163213.GN59630@barnson.org> <40E2ED7C.700@oregonstate.edu> Message-ID: <20040630164922.GP59630@barnson.org> On Wed, Jun 30, 2004 at 09:42:36AM -0700, Mike Morgan wrote: > Anyway, I think Matt has a point -- a wiki would be a very good tool. > What other options are out there? What do you guys prefer? Ideally, from a document-management standpoint, something that can easily export text back to XML for integration into the Guide. I've been building one on my web site at http://barnson.org/ within the Drupal framework for the last six months, but it doesn't work well and is horribly klunky. I've basically given up on it at the moment. -- Matthew P. Barnson - - - - Thought for the moment: "Terence, this is stupid stuff: You eat your victuals fast enough; There can't be much amiss, 'tis clear, To see the rate you drink your beer. But oh, good Lord, the verse you make, It gives a chap the belly-ache. The cow, the old cow, she is dead; It sleeps well the horned head: We poor lads, 'tis our turn now To hear such tunes as killed the cow. Pretty friendship 'tis to rhyme Your friends to death before their time. Moping, melancholy mad: Come, pipe a tune to dance to, lad." -- A. E. Housman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From matthew at barnson.org Wed Jun 30 17:29:17 2004 From: matthew at barnson.org (Matthew P. Barnson) Date: Wed, 30 Jun 2004 11:29:17 -0600 Subject: Handling copyright change gracefully Message-ID: <20040630172917.GS59630@barnson.org> I need to make a quick change before I check in further changes to the tree. Dave, you'll probably want to archive this somewhere so that copyright of the Guide isn't stuck in legal limbo at any point. By my verifiable digital signature attached to this message, I assign copyright of "The Bugzilla Guide" to "The Bugzilla Team". To that end, I am making a small change on the "about.xml" page to reflect this change as it was earlier an invariant section according to the GNU Free Documentation License. Copyright will now read "This document is copyright (c) 2000, 2001, 2002, 2003 Matthew P. Barnson. Copyright (c) 2004 The Bugzilla Team." "The Bugzilla Team" may continue to maintain copyright indefinitely from 2004 on. I recognize "The Bugzilla Team" to be headed by, and responsible to, Dave Miller, also known as JustDave. He's a benevolent dictator, and will, I'm sure, see that the continuing license terms of the document are honored and remain copy-left. If nobody objects to this change in copyright language, I'll commit it shortly to CVS. The main reason for this change is that 2.17's assignment of copyright "to the various contributors" is not a legal standing any different than public domain, and hopelessly muddled and useless. Through 2.16 and the early 2.17 development cycle, the copyright was in my name, and continuing submissions also came under that copyright (since modification of copyright was specifically precluded by the terms of the license). I'm aiming to correct that with this little statement. Since it was my copyright that is now "The Bugzilla Team"'s (ergo: Dave), he and the team are free to change the license if necessary for those portions I've contributed. My thought is that there should be a brief period available for contributors to 2.17 to object to license changes, and if any do, those portions removed. Then change as you like. I'll wait for a couple of days for any objections to this correction. If there are none, I'll commit it. Thanks. Please note, though, that changing copyright is not allowed under the current license terms of the document. I'd prefer my 2000-2003 copyright remain on the document in case someone is found to have copied in violation of license during those years. -- Matthew P. Barnson - - - - Thought for the moment: Forms follow function, and often obliterate it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From gerv at mozilla.org Wed Jun 30 18:01:46 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 Jun 2004 19:01:46 +0100 Subject: Handling copyright change gracefully In-Reply-To: <20040630172917.GS59630@barnson.org> References: <20040630172917.GS59630@barnson.org> Message-ID: <40E3000A.2050203@mozilla.org> Matthew P. Barnson wrote: > By my verifiable digital signature attached to this message, I assign > copyright of "The Bugzilla Guide" to "The Bugzilla Team". Matthew, There are, unfortunately, a few problems with what you are trying to do. Don't get me wrong - I think it's great. But legally it doesn't quite work. First of all, "The Bugzilla Team" is not a legal entity, even if you define what you mean by it, and so can't hold copyrights. You can transfer any copyrights you hold to an organisation (such as the Mozilla Foundation) or a person (such as Dave.) > The main reason for this change is that 2.17's assignment of copyright > "to the various contributors" is not a legal standing any different than > public domain, and hopelessly muddled and useless. It may indeed be "totally muddled and useless", although the code for most free software projects is copyrighted this way, including Mozilla and Bugzilla. > Through 2.16 and the > early 2.17 development cycle, the copyright was in my name, and > continuing submissions also came under that copyright (since > modification of copyright was specifically precluded by the terms of > the license). I'm afraid that simply isn't true, legally. Merely making a contribution to a document in which you own some of the copyright does not assign the copyright in the contribution to you. As SCO is finding out, copyright assignment has to be done by a specific legal contract or document. The current Bugzilla Guide has multiple copyright owners. If one wishes to copy it in a way not in accordance with its current licence, one has to either get permission from all of them, or remove the sections written by those from whom you do not have permission. This is why free software licences were invented :-) You do, of course, retain the copyright in all sections of the document which you wrote. Assigning that to the Foundation or to Dave would be a great first step in relicensing it, for example under a DFSG-free licence. Gerv From bz at barnson.org Wed Jun 30 20:53:08 2004 From: bz at barnson.org (Matthew P. Barnson) Date: Wed, 30 Jun 2004 14:53:08 -0600 Subject: bz-devel entity? Message-ID: <20040630205308.GA59630@barnson.org> I'm trying to get the Guide to compile cleanly in XML (using Debian's xmlto tool is so much easier than building your own toolchain). Unfortunately, the "bz-devel" entity, which defines some optional text if it's the development version of the Guide, doesn't validate appropriately as an XML entity. Anybody mind if I nuke the two locations we're using that so that it will be perfectly valid XML? -- Matthew P. Barnson - - - - Thought for the moment: You could get a new lease on life -- if only you didn't need the first and last month in advance. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: