From Chris.Donovan at team.telstra.com Mon May 3 23:09:17 2004 From: Chris.Donovan at team.telstra.com (Donovan, Chris) Date: Mon, 3 May 2004 19:09:17 -0400 Subject: DBD::Mysql and Perl on Solaris 9 for Bugzilla Message-ID: Hi, I admit that the following bit of information may not be relevant for some as it isn't really directly related to development of bugzilla but something I felt should be mentioned. I just finished installing Bugzilla on Solaris 9. I had a few issues with installing the perl module DBD::Mysql. My problem was I installed the binary package for MySQL and did not compile from source(.so vs. .a libraries). Now everything but this one module(DBD::Mysql) worked great. My `make test` kept failing because it couldn't find certain libraries. Specifically mysqlclient.so could not be found. I am not a developer so I had a fun time figuring this out even though it says so right in the error message. I didn't know the difference between a shared object and a static one and now I do (: I just thought perhaps it was worth mentioning in the install documentation available on the web (and all else if possible) that you need the shared objects for DBD::Mysql. I have read through the DBD::Mysql docs and nothing mentions needing the source code for mysql or the shared objects, but obviously to me they are needed. Anyways it is finally installed. I would be happy to provide some scripts as to the failings and to the successfull installs I have had if anyone would like. I saved them in a `script` session. I hope this gets put into the docs for future sys admins so they can install Bugzilla for their misc projects without this headache. Thanks, Chris Donovan- From justdave at bugzilla.org Tue May 4 02:37:50 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 03 May 2004 22:37:50 -0400 Subject: Documentation Licensing Message-ID: <409701FE.6010800@bugzilla.org> The Bugzilla Guide is currently licensed under the GNU Free Documentation License (henceforth referred to as "GFDL"). I've recently discovered some interesting tidbits about the GFDL, particularly several of the restrictions it imposes on the document which make it not exactly "Free" (as in speech). When I tried to track down more information on these things I'd been hearing, the best summary of the issues I found is a position statement from Debian, declaring why they don't consider that license to be Free. Here's Debian's position on it: http://people.debian.org/%7Esrivasta/Position_Statement.html Doing some more reading, you will discover that recent changes to the Debian Constitution also mean that the GFDL is now on the "banned licenses" list for Debian, meaning anything using that license will no longer be allowed to be distributed by Debian (and probably not by several other distros that are based on Debian either). This means people getting Bugzilla from Debian (or derivatives) will no longer get a copy of the Bugzilla documentation with it. I don't consider Debian to be the end-all and be-all of what's Free (I'm sure lots of people know how radical they've been known to be at times ;) ) however, I do happen to agree with them on this issue, after reading through the license myself. Anyone have any opinions on this? Should we make an attempt to relicense the Bugzilla Guide? My personal opinion is that the documentation for Bugzilla shouldn't be any less free than Bugzilla itself is. I am open to suggestions as to possible new licenses. I note that the Mozilla Documentation is currently not licensed, and they have a discussion underway to come up with a license to use for theirs. Among the candidates listed on their page are the Open Publications License and the LDP Copying License. There's no reason we need to do the same thing Mozilla does, however. Maybe we don't even need to change it. But I'd like to open the discussion on it at least. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From christian.masopust at siemens.com Tue May 4 05:35:18 2004 From: christian.masopust at siemens.com (Masopust Christian) Date: Tue, 4 May 2004 07:35:18 +0200 Subject: :Mysql and Perl on Solaris 9 for Bugzilla Message-ID: Hello Chris, check if the mysql-libraries are installed and where they are installed. maybe you have to extend your library-search-path either with the LD_LIBRARY_PATH variable or via ld.config (see man-page for crle) regards, chris -----Ursprungliche Nachricht----- Von: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]Im Auftrag von Donovan, Chris Gesendet: Dienstag, 04. Mai 2004 01:09 An: developers at bugzilla.org Betreff: DBD::Mysql and Perl on Solaris 9 for Bugzilla Hi, I admit that the following bit of information may not be relevant for some as it isn't really directly related to development of bugzilla but something I felt should be mentioned. I just finished installing Bugzilla on Solaris 9. I had a few issues with installing the perl module DBD::Mysql. My problem was I installed the binary package for MySQL and did not compile from source(.so vs. .a libraries). Now everything but this one module(DBD::Mysql) worked great. My `make test` kept failing because it couldn't find certain libraries. Specifically mysqlclient.so could not be found. I am not a developer so I had a fun time figuring this out even though it says so right in the error message. I didn't know the difference between a shared object and a static one and now I do (: I just thought perhaps it was worth mentioning in the install documentation available on the web (and all else if possible) that you need the shared objects for DBD::Mysql. I have read through the DBD::Mysql docs and nothing mentions needing the source code for mysql or the shared objects, but obviously to me they are needed. Anyways it is finally installed. I would be happy to provide some scripts as to the failings and to the successfull installs I have had if anyone would like. I saved them in a `script` session. I hope this gets put into the docs for future sys admins so they can install Bugzilla for their misc projects without this headache. Thanks, Chris Donovan- - To view or change your list settings, click here: -------------- next part -------------- An HTML attachment was scrubbed... URL: From Chris.Donovan at team.telstra.com Tue May 4 05:50:17 2004 From: Chris.Donovan at team.telstra.com (Donovan, Chris) Date: Tue, 4 May 2004 15:50:17 +1000 Subject: :Mysql and Perl on Solaris 9 for Bugzilla Message-ID: <83A05A620FD8D211BD9B0008C7247D1B104A5905@ntmsg0025.corpmail.telstra.com.au> Hello, I have successfully installed Bugzilla and it is working fine as I said in my original email. However I just wanted to point out that I had to download and compile the source myself taking the default of creating both shared and static libraries for ./configure. It wasn't a problem with MySQL directly but rather the DBD::Mysql perl module that was needing the shared library mysqlclient.so. I think perhaps for some admins at least that it might be beneficial to note unless you can find the mysqlclient.so library. If you couldn't find it you would need to download the source and compile it yourself or at least find a package that has that in it. I am referring to sunfreeware packages that didn't have it nor did the binary copies for Solaris that I downloaded from mysql.com itself. I will be submitting this to the mysql-perl-list as well, but for now since it doesn't mention anything in their docs I figure since Bugzilla requires it, it could be beneficial for the documentation to mention it. I addition to what I have said I did look through the package/binary installtion and did not find anything but the static library mysqlclient.a but no .so. I'd like to stress that this is not directly related to Bugzilla itself but rather something that the perl-mysql-list should take care of. It just helps to know in advance what will be needed for proper planning and deployment and that is where the Bugzilla docs come into play. Chris Donovan- -----Original Message----- From: Masopust Christian [mailto:christian.masopust at siemens.com] Sent: Tuesday, 4 May 2004 3:35 PM To: 'developers at bugzilla.org' Subject: Re: :Mysql and Perl on Solaris 9 for Bugzilla Hello Chris, check if the mysql-libraries are installed and where they are installed. maybe you have to extend your library-search-path either with the LD_LIBRARY_PATH variable or via ld.config (see man-page for crle) regards, chris -----Ursprungliche Nachricht----- Von: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]Im Auftrag von Donovan, Chris Gesendet: Dienstag, 04. Mai 2004 01:09 An: developers at bugzilla.org Betreff: DBD::Mysql and Perl on Solaris 9 for Bugzilla Hi, I admit that the following bit of information may not be relevant for some as it isn't really directly related to development of bugzilla but something I felt should be mentioned. I just finished installing Bugzilla on Solaris 9. I had a few issues with installing the perl module DBD::Mysql. My problem was I installed the binary package for MySQL and did not compile from source(.so vs. .a libraries). Now everything but this one module(DBD::Mysql) worked great. My `make test` kept failing because it couldn't find certain libraries. Specifically mysqlclient.so could not be found. I am not a developer so I had a fun time figuring this out even though it says so right in the error message. I didn't know the difference between a shared object and a static one and now I do (: I just thought perhaps it was worth mentioning in the install documentation available on the web (and all else if possible) that you need the shared objects for DBD::Mysql. I have read through the DBD::Mysql docs and nothing mentions needing the source code for mysql or the shared objects, but obviously to me they are needed. Anyways it is finally installed. I would be happy to provide some scripts as to the failings and to the successfull installs I have had if anyone would like. I saved them in a `script` session. I hope this gets put into the docs for future sys admins so they can install Bugzilla for their misc projects without this headache. Thanks, Chris Donovan- - To view or change your list settings, click here: From sr at stephenreindl.de Tue May 4 07:26:39 2004 From: sr at stephenreindl.de (Stephen Reindl) Date: Tue, 4 May 2004 09:26:39 +0200 (CEST) Subject: {Spam?} Re: :Mysql and Perl on Solaris 9 for Bugzilla In-Reply-To: <83A05A620FD8D211BD9B0008C7247D1B104A5905@ntmsg0025.corpmail.telstra.c om.au> References: <83A05A620FD8D211BD9B0008C7247D1B104A5905@ntmsg0025.corpmail.telstra.com.au> Message-ID: <51316.195.233.250.6.1083655599.squirrel@sreindl.dyndns.org> Hi, maybe we should provide some kind of FAQ for issues like this. I do not think we should cover this in the installation manual because this is not directly related to BugZilla. Regards Stephen -- Stephen Reindl Donovan, Chris sagte: > Hello, > > I have successfully installed Bugzilla and it is working fine as I > said in my original email. However I just wanted to point out that I > had to download and compile the source myself taking the default of > creating both shared and static libraries for ./configure. It wasn't > a problem with MySQL directly but rather the DBD::Mysql perl module > that was needing the shared library mysqlclient.so. I think perhaps > for some admins at least that it might be beneficial to note unless > you can find the mysqlclient.so library. If you couldn't find it you > would need to download the source and compile it yourself or at least > find a package that has that in it. I am referring to sunfreeware > packages that didn't have it nor did the binary copies for Solaris > that I downloaded from mysql.com itself. I will be submitting this > to the mysql-perl-list as well, but for now since it doesn't mention > anything in their docs I figure since Bugzilla requires it, it could > be beneficial for the do! > cumentation to mention it. > > I addition to what I have said I did look through the package/binary > installtion and did not find anything but the static library > mysqlclient.a but no .so. I'd like to stress that this is not > directly related to Bugzilla itself but rather something that the > perl-mysql-list should take care of. It just helps to know in > advance what will be needed for proper planning and deployment and > that is where the Bugzilla docs come into play. > > Chris Donovan- > > > -----Original Message----- > From: Masopust Christian [mailto:christian.masopust at siemens.com] > Sent: Tuesday, 4 May 2004 3:35 PM > To: 'developers at bugzilla.org' > Subject: Re: :Mysql and Perl on Solaris 9 for Bugzilla > > > > > Hello Chris, > check if the mysql-libraries are installed and where they are installed. > maybe you have to extend your library-search-path either with the > LD_LIBRARY_PATH > variable or via ld.config (see man-page for crle) > regards, > chris > -----Ursprungliche Nachricht----- > Von: developers-owner at bugzilla.org > [mailto:developers-owner at bugzilla.org]Im Auftrag von Donovan, Chris > Gesendet: Dienstag, 04. Mai 2004 01:09 > An: developers at bugzilla.org > Betreff: DBD::Mysql and Perl on Solaris 9 for Bugzilla > > > Hi, > I admit that the following bit of information may not be relevant for > some as it isn't really directly related to development of bugzilla > but something I felt should be mentioned. > I just finished installing Bugzilla on Solaris 9. I had a few issues > with installing the perl module DBD::Mysql. My problem was I > installed the binary package for MySQL and did not compile from > source(.so vs. .a libraries). Now everything but this one > module(DBD::Mysql) worked great. My `make test` kept failing because > it couldn't find certain libraries. Specifically mysqlclient.so > could not be found. I am not a developer so I had a fun time > figuring this out even though it says so right in the error message. > I didn't know the difference between a shared object and a static one > and now I do (: > I just thought perhaps it was worth mentioning in the install > documentation available on the web (and all else if possible) that > you need the shared objects for DBD::Mysql. I have read through the > DBD::Mysql docs and nothing mentions needing the source code for > mysql or the shared objects, but obviously to me they are needed. > Anyways it is finally installed. I would be happy to provide some > scripts as to the failings and to the successfull installs I have had > if anyone would like. I saved them in a `script` session. I hope > this gets put into the docs for future sys admins so they can install > Bugzilla for their misc projects without this headache. > > > Thanks, > > > Chris Donovan- > - > To view or change your list settings, click here: > > > - > To view or change your list settings, click here: > > From gerv at mozilla.org Tue May 4 17:51:00 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 04 May 2004 18:51:00 +0100 Subject: Documentation Licensing In-Reply-To: <409701FE.6010800@bugzilla.org> References: <409701FE.6010800@bugzilla.org> Message-ID: <4097D804.2010903@mozilla.org> David Miller wrote: > Doing some more reading, you will discover that recent changes to the > Debian Constitution also mean that the GFDL is now on the "banned > licenses" list for Debian, meaning anything using that license will no > longer be allowed to be distributed by Debian (and probably not by > several other distros that are based on Debian either). This decision may be stayed till after the 'sarge' release, but yes, the writing is definitely on the wall. > Anyone have any opinions on this? Should we make an attempt to > relicense the Bugzilla Guide? My personal opinion is that the > documentation for Bugzilla shouldn't be any less free than Bugzilla > itself is. I think we should relicense. > I am open to suggestions as to possible new licenses. I note that the > Mozilla Documentation is currently not licensed, and they have a > discussion underway to come up with a license to use for theirs. Among > the candidates listed on their page are the Open Publications License > and the LDP Copying License. What page is that? I know of no such page. My original suggestion for Mozilla documentation was an Creative Commons License. Thinking about it, though, we may have a problem. - I think requiring attribution is bad, because you get "credit bloat" - each MPLed file suffers from this to a certain degree, and would suffer a lot more if everyone who qualified added their name. For a whole document, it would quickly get out of hand. Particularly if you then copy one chapter into a new document, and a bit of that into a third, and so on. - ShareAlike would be good, except that the terms are: "If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one." This means we couldn't convert some of the docs to HTML help templates and license them under the MPL. - We want to allow commercial uses. I hope one day there will be a Bugzilla book, and it would be foolish to prevent the author(s) using the Guide material. So if you put the above reasoning into the CC license chooser, you end up with a Public Domain dedication... which may or may not be what we want. Anyone else got any thoughts? Gerv From justdave at bugzilla.org Tue May 4 18:20:59 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 04 May 2004 14:20:59 -0400 Subject: Documentation Licensing In-Reply-To: <4097D804.2010903@mozilla.org> References: <409701FE.6010800@bugzilla.org> <4097D804.2010903@mozilla.org> Message-ID: <4097DF0B.30306@bugzilla.org> Gervase Markham wrote: > David Miller wrote: > >> I am open to suggestions as to possible new licenses. I note that the >> Mozilla Documentation is currently not licensed, and they have a >> discussion underway to come up with a license to use for theirs. >> Among the candidates listed on their page are the Open Publications >> License and the LDP Copying License. > > What page is that? I know of no such page. http://www.mozilla.org/docs/contribute.html - see "Legal Stuff" at the bottom. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From zach at zachlipton.com Wed May 5 06:15:07 2004 From: zach at zachlipton.com (Zach Lipton) Date: Tue, 4 May 2004 23:15:07 -0700 Subject: Documentation Licensing In-Reply-To: <409701FE.6010800@bugzilla.org> References: <409701FE.6010800@bugzilla.org> Message-ID: <1083737711.164F3378@s5.dngr.org> Based on reading the Debian position paper on the GFDL, I'm inclined to say we should relicense, to keep the docs in Debian and to avoid the issues with the existing license. It wouldn't be very difficult to relicense, as there are only a few contributors and most are regularly involved with the project (my current lack of productivity nonwithstanding :). I agree however that any license used needs to leave open the possibility of incorporating the material into a book at some point in the future. Since the guide is already a part of the LDP, the LDP Copying License might be a good choice. Zach On Mon, 3 May 2004 7:50pm, David Miller wrote: > The Bugzilla Guide is currently licensed under the GNU Free > Documentation License (henceforth referred to as "GFDL"). > > I've recently discovered some interesting tidbits about the GFDL, > particularly several of the restrictions it imposes on the document > which make it not exactly "Free" (as in speech). When I tried to track > down more information on these things I'd been hearing, the best > summary of the issues I found is a position statement from Debian, > declaring why they don't consider that license to be Free. > > Here's Debian's position on it: > http://people.debian.org/%7Esrivasta/Position_Statement.html > > Doing some more reading, you will discover that recent changes to the > Debian Constitution also mean that the GFDL is now on the "banned > licenses" list for Debian, meaning anything using that license will no > longer be allowed to be distributed by Debian (and probably not by > several other distros that are based on Debian either). > > This means people getting Bugzilla from Debian (or derivatives) will no > longer get a copy of the Bugzilla documentation with it. > > I don't consider Debian to be the end-all and be-all of what's Free > (I'm sure lots of people know how radical they've been known to be at > times ;) ) however, I do happen to agree with them on this issue, after > reading through the license myself. > > Anyone have any opinions on this? Should we make an attempt to > relicense the Bugzilla Guide? My personal opinion is that the > documentation for Bugzilla shouldn't be any less free than Bugzilla > itself is. > > I am open to suggestions as to possible new licenses. I note that the > Mozilla Documentation is currently not licensed, and they have a > discussion underway to come up with a license to use for theirs. Among > the candidates listed on their page are the Open Publications License > and the LDP Copying License. There's no reason we need to do the same > thing Mozilla does, however. > > Maybe we don't even need to change it. But I'd like to open the > discussion on it at least. > > -- > Dave Miller Project Leader, Bugzilla Bug Tracking System > http://www.justdave.net/ http://www.bugzilla.org/ > > - > To view or change your list settings, click here: > From gerv at mozilla.org Wed May 5 07:55:53 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 05 May 2004 08:55:53 +0100 Subject: Documentation Licensing In-Reply-To: <4097DF0B.30306@bugzilla.org> References: <409701FE.6010800@bugzilla.org> <4097D804.2010903@mozilla.org> <4097DF0B.30306@bugzilla.org> Message-ID: <40989E09.6020903@mozilla.org> David Miller wrote: > Gervase Markham wrote: >> What page is that? I know of no such page. > > http://www.mozilla.org/docs/contribute.html - see "Legal Stuff" at the > bottom. Apparently we were "working on a copyright policy" in 1999 - and the issue still hasn't been resolved. Ah, well. But don't take those suggestions as anything more than a snapshot of history. Gerv From MKey at atmi.com Wed May 5 17:23:02 2004 From: MKey at atmi.com (MKey at atmi.com) Date: Wed, 5 May 2004 17:23:02 +0000 Subject: Mathew Key is out of the office.... Message-ID: I will be out of the office starting 05/05/2004 and will not return until 24/05/2004. For APAC technical support, please email CK Loo at ckloo at emosyn.com For EMEA technical support, please email Xavier Quillien at xquillien at emosyn.com For Emosyn.com website issues, please email Stephen Johnston at sjohnston at emosyn.com From matthew at barnson.org Wed May 5 16:46:48 2004 From: matthew at barnson.org (Matthew P. Barnson) Date: Wed, 5 May 2004 10:46:48 -0600 Subject: Documentation Licensing In-Reply-To: <409701FE.6010800@bugzilla.org> References: <409701FE.6010800@bugzilla.org> Message-ID: <20040505164647.GD61187@barnson.org> As the author of the Bugzilla Guide, I should probably chime in here :) At the time I wrote the Guide, Creative Commons licenses did not exist. Well, perhaps it existed, but I was not aware of them. The reason I chose GFDL was because, at the time and based on the advice of a lawyer I know and trust, "code" licenses (such as the MPL) didn't apply well to text documentation. I am not averse to changing the license to something more free than the GFDL; when I licensed the doc under the GFDL, although some developers questioned the judgement of using any GNU license, it seemed an appropriate way to make sure the documentation remained free, while maintaining attribution, copyright, etc. However, there is one provision of the GFDL not being met that, while not wanting to be a jerk about it, I'd prefer Bugzilla adhere to: leaving my copyright intact. Right now, by removing my copyright (haven't looked in the CVS log to see who did it) and my name from the principal author list, Bugzilla's in violation of the GFDL. I have a few doc patches that I really need to check in, and, if nobody objects, I'll remedy this in my next checkin. I realize that I haven't contributed meaningfully in quite some time, but I was still the author, and the GFDL requires author and copyright notices be added to, not removed. But that's a side issue from the question; I apologize for bringing it up, but it's bugged me for several months :) I think that the only developers from whom we'll need to obtain consent to change the copyright are JustDave, Jake (can we do that with him on-duty?), Zach Lipton, and myself. I'll check out some Creative Commons licenses. I think their attribution-required license wil probably fit the bill. -- Matthew P. Barnson - - - - Thought for the moment: In a medium in which a News Piece takes a minute and an "In-Depth" Piece takes two minutes, the Simple will drive out the Complex. -- Frank Mankiewicz From matthew at barnson.org Wed May 5 16:54:14 2004 From: matthew at barnson.org (Matthew P. Barnson) Date: Wed, 5 May 2004 10:54:14 -0600 Subject: Documentation Licensing In-Reply-To: <40989E09.6020903@mozilla.org> References: <409701FE.6010800@bugzilla.org> <4097D804.2010903@mozilla.org> <4097DF0B.30306@bugzilla.org> <40989E09.6020903@mozilla.org> Message-ID: <20040505165414.GE61187@barnson.org> On Wed, May 05, 2004 at 08:55:53AM +0100, Gervase Markham wrote: > Apparently we were "working on a copyright policy" in 1999 - and the > issue still hasn't been resolved. Ah, well. But don't take those > suggestions as anything more than a snapshot of history. Yep, the decision wasn't made in a vacuum, but at the time Mozilla.org had no documentation copyright policy -- except the guideline of MPL for code which in-lined documentation -- and after furious debate for about a week and a half, I believe Tara's opinion was something to the effect of "You know, as long as some docs get written, I don't care what license we use". So I wrote them up, put them under the GFDL (which seemed the most appropriate at the time), and there you have them. -- Matthew P. Barnson - - - - Thought for the moment: You men out there probably think you already know how to dress for success. You know, for example, that you should not wear leisure suits or white plastic belts and shoes, unless you are going to a costume party disguised as a pig farmer vacationing at Disney World. -- Dave Barry, "How to Dress for Real Success" From matthew at barnson.org Wed May 5 17:40:11 2004 From: matthew at barnson.org (Matthew P. Barnson) Date: Wed, 5 May 2004 11:40:11 -0600 Subject: Documentation Licensing In-Reply-To: <1083737711.164F3378@s5.dngr.org> References: <409701FE.6010800@bugzilla.org> <1083737711.164F3378@s5.dngr.org> Message-ID: <20040505174010.GF61187@barnson.org> On Tue, May 04, 2004 at 11:15:07PM -0700, Zach Lipton wrote: > I agree however that any license used needs to leave open the > possibility of incorporating the material into a book at some point in > the future. Since the guide is already a part of the LDP, the LDP > Copying License might be a good choice. After researching it this morning, I think Creative Commons Attribution 1.0 license fits the bill nicely. Yes, you are going to have attribution bloat over time, but that is not a big deal. It represents perhaps one or two pages out of the book which people commonly skip over anyway. This license woud nicely dovetail with my original objectives for the work: allow free redistribution and modification, prevent people from "closing" it up (preventing others from freely redistributing it), but require that author credits and copyright remain intact. Free software developers and documentors generally do it for money or recognition, and those of us not getting paid to work on BZ value the props :) See: Human-readable: http://creativecommons.org/licenses/by/1.0/ Lawyer-readable: http://creativecommons.org/licenses/by/1.0/legalcode -- Matthew P. Barnson - - - - Thought for the moment: "I'm prepared for all emergencies but totally unprepared for everyday life." From justdave at bugzilla.org Wed May 5 19:27:11 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 05 May 2004 15:27:11 -0400 Subject: Documentation Licensing In-Reply-To: <20040505164647.GD61187@barnson.org> References: <409701FE.6010800@bugzilla.org> <20040505164647.GD61187@barnson.org> Message-ID: <4099400F.30206@bugzilla.org> Matthew P. Barnson wrote: > However, there is one provision of the GFDL not being met that, while not > wanting to be a jerk about it, I'd prefer Bugzilla adhere to: leaving my > copyright intact. Right now, by removing my copyright (haven't looked in > the CVS log to see who did it) and my name from the principal author list, > Bugzilla's in violation of the GFDL. I have a few doc patches that I > really need to check in, and, if nobody objects, I'll remedy this in my > next checkin. I realize that I haven't contributed meaningfully in quite > some time, but I was still the author, and the GFDL requires author and > copyright notices be added to, not removed. I don't think it was intentional to take your name off of billing, I think the intent at the time was only to get the people list there who you would go to if you wanted stuff added. I have no objection to putting it back (nor can I object under the current license ;) I know the only thing I had explicitly authorized to go away was the document history section. It made the table of contents very hard to find, since it was on the same page with it, and that information is readily available from CVS anyway. My actual instructions were to move it below the table of contents, but I think the docbook stylesheets made that difficult to do. > I think that the only developers from whom we'll need to obtain consent to > change the copyright are JustDave, Jake (can we do that with him on-duty?), > Zach Lipton, and myself. Jake has been occasionally online... he did manage to get net access from his bunker, and is actually the unofficial networking guy for his unit :) Unfortunately, I can imagine given the recent events there (he's stationed at the Abu Gahraib prison, which has been all over the news the last couple weeks), that they might be cracking down on what folks get access to. And in case anyone's wondering, the two Military Police units actually involved in all the crap going on there are based in Pennsylvania and Maryland; Jake's unit is based in Michigan. As for others to get consent from, there's actually been a variety of people contributing to docs recently. We'll probably need to go through the checkin logs and check the related bugs and so forth. Gerv (not on your list) has made some major contributions. There's also been several smaller contributions from other folks. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Wed May 5 20:07:13 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 05 May 2004 21:07:13 +0100 Subject: Documentation Licensing In-Reply-To: <20040505174010.GF61187@barnson.org> References: <409701FE.6010800@bugzilla.org> <1083737711.164F3378@s5.dngr.org> <20040505174010.GF61187@barnson.org> Message-ID: <40994971.5010100@mozilla.org> Matthew P. Barnson wrote: > After researching it this morning, I think Creative Commons Attribution 1.0 > license fits the bill nicely. Yes, you are going to have attribution bloat > over time, but that is not a big deal. It represents perhaps one or two > pages out of the book which people commonly skip over anyway. But what happens if I copy a chapter into another book (say on webtools)? And then a year later, someone else takes a chapter from that (it may not contain any of your content, but he's not to know) for his own use? Not putting attribution in the license doesn't mean we wouldn't have any - it just means that if someone wanted to copy a paragraph into something else, it wouldn't come with baggage. > This license woud nicely dovetail with my original objectives for the work: > allow free redistribution and modification, prevent people from "closing" > it up (preventing others from freely redistributing it), but require that > author credits and copyright remain intact. Attribution 1.0 does allow people to close it up - you'd need to add ShareAlike to prevent that. But see my previous post for the problems with that. Gerv From gerv at mozilla.org Wed May 5 20:13:07 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 05 May 2004 21:13:07 +0100 Subject: Documentation Licensing In-Reply-To: <20040505164647.GD61187@barnson.org> References: <409701FE.6010800@bugzilla.org> <20040505164647.GD61187@barnson.org> Message-ID: <40994AD3.6050504@mozilla.org> Matthew P. Barnson wrote: > However, there is one provision of the GFDL not being met that, while not > wanting to be a jerk about it, I'd prefer Bugzilla adhere to: leaving my > copyright intact. Right now, by removing my copyright (haven't looked in > the CVS log to see who did it) and my name from the principal author list, > Bugzilla's in violation of the GFDL. That was me. I confess I didn't consult the license before doing so - I assumed that the reason you were specifically named was that you were the current maintainer; when that stopped being true, I just moved your name to the more general credits list, and changed the attribution to reflect the fact that the documentation is now a team effort. Here's another thought about requiring attribution through the license, actually. Let's assume you don't make any more changes to the docs. In five years time, they'll be unrecognisable from when you edited them - and yet your name would still appear as principal author. I'd say that wouldn't be right, or fair on all the people who'd done the in-between work. Voluntary attribution gives us the flexibility to be sensible. > I think that the only developers from whom we'll need to obtain consent to > change the copyright are JustDave, Jake (can we do that with him on-duty?), > Zach Lipton, and myself. I doubt that very much :-(. For a start, as Dave says, I've made significant changes. We need to look through the CVS checkin history, and perhaps Bugzilla, to see who has contributed. Relicensing anything is (sadly) not a simple process. Gerv From bz at barnson.org Thu May 6 03:24:38 2004 From: bz at barnson.org (Barnboy) Date: Wed, 5 May 2004 21:24:38 -0600 Subject: Documentation Licensing In-Reply-To: <40994AD3.6050504@mozilla.org> References: <409701FE.6010800@bugzilla.org> <20040505164647.GD61187@barnson.org> <40994AD3.6050504@mozilla.org> Message-ID: <20040506032437.GL61187@barnson.org> So I did a lot of reading this evening regarding the potential non-freeness of the GFDL. From what I can tell, the argument centers around 'invariant sections'. When originally writing the Guide, I decided against using them, abd you'll note that the Bugzilla Guide has no invariant sections -- and thus remains truly free documentation. Just a thought... might be less hassle to not relicense :) Note I am not trying to be an advocate for or against, but without invariant sections, the Guide is perfectly free according to the Debian guidelines. So it seems to be a non-issue in this case. -- Matthew P. Barnson - - - - Thought for the moment: "I'm returning this note to you, instead of your paper, because it (your paper) presently occupies the bottom of my bird cage." -- English Professor, Providence College From justdave at bugzilla.org Thu May 6 04:34:02 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 06 May 2004 00:34:02 -0400 Subject: Documentation Licensing In-Reply-To: <20040506032437.GL61187@barnson.org> References: <409701FE.6010800@bugzilla.org> <20040505164647.GD61187@barnson.org> <40994AD3.6050504@mozilla.org> <20040506032437.GL61187@barnson.org> Message-ID: <4099C03A.3050009@bugzilla.org> Barnboy wrote: > So I did a lot of reading this evening regarding the potential non-freeness > of the GFDL. From what I can tell, the argument centers around 'invariant > sections'. When originally writing the Guide, I decided against using them, > abd you'll note that the Bugzilla Guide has no invariant sections -- and > thus remains truly free documentation. Except that anyone can add an invariant section to their derived work, thus allowing it to become non-free. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bz at barnson.org Thu May 6 17:00:55 2004 From: bz at barnson.org (Barnboy) Date: Thu, 6 May 2004 11:00:55 -0600 Subject: Documentation Licensing In-Reply-To: <4099C03A.3050009@bugzilla.org> References: <409701FE.6010800@bugzilla.org> <20040505164647.GD61187@barnson.org> <40994AD3.6050504@mozilla.org> <20040506032437.GL61187@barnson.org> <4099C03A.3050009@bugzilla.org> Message-ID: <20040506170054.GA62670@barnson.org> On Thu, May 06, 2004 at 12:34:02AM -0400, David Miller wrote: > Except that anyone can add an invariant section to their derived work, > thus allowing it to become non-free. Yep, that's part of the fun discussion on Debian-legal. I'm still sorting through some archives, but it sure seems as if it's simply become a holy war, arguing over free vs. non-free status of licenses... it's like arguing over programming languages :) Regardless, it seems that Bugzilla is in Debian-stable, and not in Debian-nonfree. If we require that the core Bugzilla docs not make use of invariant sections, we will remain there. Yeah, people could be obnoxious and put invarianet sections in forked documentation, but under BSD-style licenses, you face the same problem. Just a different symptom :) It might be worthwhile to put a note in the BZ Guide basically stating that "any CVS documentation submissions must not alter the GFDL licensing scheme, specifically no invariant sections or cover texts may be specified." And leave it at that -- if someone really wants to fork and create invariant sections, that becomes their closed-off doc fork without possibility of landing back in the main tree. -- Matthew P. Barnson - - - - Thought for the moment: Santa Claus wears a Red Suit, He must be a communist. And a beard and long hair, Must be a pacifist. What's in that pipe that he's smoking? -- Arlo Guthrie From gerv at mozilla.org Thu May 6 22:36:42 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 06 May 2004 23:36:42 +0100 Subject: Documentation Licensing In-Reply-To: <20040506170054.GA62670@barnson.org> References: <409701FE.6010800@bugzilla.org> <20040505164647.GD61187@barnson.org> <40994AD3.6050504@mozilla.org> <20040506032437.GL61187@barnson.org> <4099C03A.3050009@bugzilla.org> <20040506170054.GA62670@barnson.org> Message-ID: <409ABDFA.3060006@mozilla.org> Barnboy wrote: > Yep, that's part of the fun discussion on Debian-legal. I'm still sorting > through some archives, but it sure seems as if it's simply become a holy > war, arguing over free vs. non-free status of licenses... it's like arguing > over programming languages :) Er... the freeness or non-freeness of licenses, both for code and documentation, is important. (As is the choice of the correct programming language for a particular task, for that matter.) If it weren't important, we wouldn't be having this discussion. > Regardless, it seems that Bugzilla is in Debian-stable, and not in > Debian-nonfree. If we require that the core Bugzilla docs not make use of > invariant sections, we will remain there. That's not true. They have other objections to the GFDL beside the invariant sections, and Bugzilla's docs will end up in nonfree if they act on the resolution they just passed. Gerv From dshesnicky at enqsemi.com Fri May 7 15:47:47 2004 From: dshesnicky at enqsemi.com (Don Shesnicky) Date: Fri, 7 May 2004 11:47:47 -0400 Subject: finer granularity on changing fields Message-ID: Sorry if this is already discussed somewhere but the search page is giving a "Internal Server Error".... My company is looking for finer granularity on the ability to limit users to change fields. For instance only team leaders would be able to set priority or perhaps close the ticket. I have 2.16.5 installed and only see the "Bit 32 editbugs Can edit all aspects of any bug" group. Is this functionality already built into this version of bugzilla and I'm missing it somewhere? Is there the ability to add more bits/groups that I could edit the code to check? I believe I see the sub that needs modification CheckCanChangeField, don't fully understand it yet though. Don From gerv at mozilla.org Fri May 7 16:18:36 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 07 May 2004 17:18:36 +0100 Subject: finer granularity on changing fields In-Reply-To: References: Message-ID: <409BB6DC.5070605@mozilla.org> Don Shesnicky wrote: > Sorry if this is already discussed somewhere but the search page is > giving > a "Internal Server Error".... Which search page? > My company is looking for finer granularity on the ability to limit > users > to change fields. For instance only team leaders would be able to set > priority > or perhaps close the ticket. I have 2.16.5 installed and only see the > "Bit 32 > editbugs Can edit all aspects of any bug" group. This is achieved by changing the Perl code in a function called "CheckCanChangeField()", which has been isolated and commented for this particular purpose. This gives people ultimate flexibility in defining the rules for their organisation. Gerv From dshesnicky at enqsemi.com Fri May 7 17:39:58 2004 From: dshesnicky at enqsemi.com (Don Shesnicky) Date: Fri, 7 May 2004 13:39:58 -0400 Subject: finer granularity on changing fields Message-ID: http://bugzilla.org/discussion.html developers at bugzilla.org - This mailing list is for discussion among people who are assisting with the to this list. Suscrib /Browse Archives Search Archives: ^^^^^^^^^^^^^^^^ this one is broken Don -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gervase Markham Sent: Friday, May 07, 2004 12:19 PM To: developers at bugzilla.org Subject: Re: finer granularity on changing fields Don Shesnicky wrote: > Sorry if this is already discussed somewhere but the search page is > giving a "Internal Server Error".... Which search page? > My company is looking for finer granularity on the ability to limit > users to change fields. For instance only team leaders would be able > to set priority or perhaps close the ticket. I have 2.16.5 installed > and only see the "Bit 32 editbugs Can edit all aspects of any bug" > group. This is achieved by changing the Perl code in a function called "CheckCanChangeField()", which has been isolated and commented for this particular purpose. This gives people ultimate flexibility in defining the rules for their organisation. Gerv - To view or change your list settings, click here: From dshesnicky at enqsemi.com Fri May 7 17:34:35 2004 From: dshesnicky at enqsemi.com (Don Shesnicky) Date: Fri, 7 May 2004 13:34:35 -0400 Subject: finer granularity on changing fields Message-ID: http://bugzilla.org/discussion.html developers at bugzilla.org - This mailing list is for discussion among people who are assisting with the to this list. Subscribe / Browse Archives Search Archives: ^^^^^^^^^^^^^^^^ this one Don -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gervase Markham Sent: Friday, May 07, 2004 12:19 PM To: developers at bugzilla.org Subject: Re: finer granularity on changing fields Don Shesnicky wrote: > Sorry if this is already discussed somewhere but the search page is > giving a "Internal Server Error".... Which search page? > My company is looking for finer granularity on the ability to limit > users to change fields. For instance only team leaders would be able > to set priority or perhaps close the ticket. I have 2.16.5 installed > and only see the "Bit 32 editbugs Can edit all aspects of any bug" > group. This is achieved by changing the Perl code in a function called "CheckCanChangeField()", which has been isolated and commented for this particular purpose. This gives people ultimate flexibility in defining the rules for their organisation. Gerv - To view or change your list settings, click here: From justdave at bugzilla.org Fri May 7 18:25:29 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 07 May 2004 14:25:29 -0400 Subject: finer granularity on changing fields In-Reply-To: References: Message-ID: <409BD499.2020609@bugzilla.org> Don Shesnicky wrote: >>Sorry if this is already discussed somewhere but the search page is >>giving a "Internal Server Error".... > http://bugzilla.org/discussion.html > > developers at bugzilla.org - This mailing list is for > discussion among people who are assisting with the > > to this list. Suscrib /Browse Archives > Search Archives: > ^^^^^^^^^^^^^^^^ > this one is broken OK, should be fixed now, as soon as it finishes re-indexing. The server it's running on just got upgraded to Fedora FC1 from RedHat 7.3 the other day, and the existing search indexes didn't survive the upgrade. I just nuked the old indexes, and they're in the process of rebuilding now. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Mon May 10 17:42:34 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 10 May 2004 13:42:34 -0400 Subject: Should Bugzilla 2.18 require Perl 5.6.1? In-Reply-To: <408DE4C0.70708@bugzilla.org> References: <408DE4C0.70708@bugzilla.org> Message-ID: <409FBF0A.7030708@bugzilla.org> David Miller wrote: > In hunting down various bugs, we've run into some more taint-related > problems that are essentially bugs in Perl 5.6.0 that were fixed in > 5.6.1. There are ways to work around them, but they're not fun. > > How many people are still using Perl 5.6.0 or older? > > Bugzilla 2.16.x currently requires Perl 5.00503 or newer. The 2.17 > branch (which will soon be 2.18) currently already requires Perl 5.6.0 > or newer. Would it hurt too many people if we go the extra step up to > require Perl 5.6.1? > > I'm not aware of any distros still shipping 5.6.0. Mac OS X was the > last one I knew of that was still shipping Perl 5.6.0, and they're > shipping 5.8.1 now. I've gotten absolutely zero responses from anyone saying they still need Perl 5.6.0 support. We're close enough to releasing 2.18 now, though, I'm going to go ahead and leave the requirement at 5.6.0 for 2.18, however we will be dropping 5.6.0 support (requiring a minimum of at least 5.6.1) for 2.19/2.20. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From asmodai at wxs.nl Tue May 11 06:43:25 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Tue, 11 May 2004 08:43:25 +0200 Subject: Should Bugzilla 2.18 require Perl 5.6.1? In-Reply-To: <409FBF0A.7030708@bugzilla.org> References: <408DE4C0.70708@bugzilla.org> <409FBF0A.7030708@bugzilla.org> Message-ID: <20040511064325.GJ553@nexus.ninth-circle.org> Dave, -On [20040510 19:52], David Miller (justdave at bugzilla.org) wrote: >I've gotten absolutely zero responses from anyone saying they still need >Perl 5.6.0 support. We're close enough to releasing 2.18 now, though, >I'm going to go ahead and leave the requirement at 5.6.0 for 2.18, >however we will be dropping 5.6.0 support (requiring a minimum of at >least 5.6.1) for 2.19/2.20. Not trying to beat on a dead horse here, so excuse me if I missed previous discussions (only now getting back on track with my lists), but wouldn't a dependency on 5.8.x not be a better goal? As far as I understood it Unicode support is just not what it should be in 5.6.x and given the diverse userbase it would seem more interesting to go that route. -- 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/ Is this all there is of me..? From Nick.Barnes at pobox.com Tue May 11 08:23:04 2004 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Tue, 11 May 2004 09:23:04 +0100 Subject: Should Bugzilla 2.18 require Perl 5.6.1? In-Reply-To: <409FBF0A.7030708@bugzilla.org> from David Miller of "Mon, 10 May 2004 13:42:34 -0400" Message-ID: <97833.1084263784@thrush.ravenbrook.com> At 2004-05-10 17:42:34+0000, David Miller writes: > We're close enough to releasing 2.18 now, though, And how close is that? It feels pretty close. Are we going to get an RC or two? There's not been much discussion of this on either of these lists. There are 4 "blockers" with target milestone 2.18, but there are 11 bugs with the flag "blocking2.18". Nick B From justdave at bugzilla.org Tue May 11 13:33:40 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 11 May 2004 09:33:40 -0400 Subject: Should Bugzilla 2.18 require Perl 5.6.1? In-Reply-To: <20040511064325.GJ553@nexus.ninth-circle.org> References: <408DE4C0.70708@bugzilla.org> <409FBF0A.7030708@bugzilla.org> <20040511064325.GJ553@nexus.ninth-circle.org> Message-ID: <40A0D634.4010108@bugzilla.org> Jeroen Ruigrok/asmodai wrote: > -On [20040510 19:52], David Miller (justdave at bugzilla.org) wrote: > >>I've gotten absolutely zero responses from anyone saying they still need >>Perl 5.6.0 support. We're close enough to releasing 2.18 now, though, >>I'm going to go ahead and leave the requirement at 5.6.0 for 2.18, >>however we will be dropping 5.6.0 support (requiring a minimum of at >>least 5.6.1) for 2.19/2.20. > > Not trying to beat on a dead horse here, so excuse me if I missed > previous discussions (only now getting back on track with my lists), but > wouldn't a dependency on 5.8.x not be a better goal? As far as I > understood it Unicode support is just not what it should be in 5.6.x and > given the diverse userbase it would seem more interesting to go that > route. Yes, I really want to do that, too. I remember we got a lot of resistance when we dropped 5.005 support for 2.18 (2.16 still supports 5.00503). Just remembering that, and knowing that 5.6.1 hasn't disappeared all that long ago. On the other hand, 2.18 with 5.6.0 support will be around for at least a year, and that's a long time in the software world, so requiring 5.8 on the trunk probably wouldn't hurt that bad (people who need earlier can just keep using 2.18). 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. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Tue May 11 15:21:15 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 11 May 2004 11:21:15 -0400 Subject: Should Bugzilla 2.18 require Perl 5.6.1? In-Reply-To: <97833.1084263784@thrush.ravenbrook.com> References: <97833.1084263784@thrush.ravenbrook.com> Message-ID: <40A0EF6B.7030607@bugzilla.org> Nick Barnes wrote: > At 2004-05-10 17:42:34+0000, David Miller writes: > >>We're close enough to releasing 2.18 now, though, > > And how close is that? It feels pretty close. Are we going to get an > RC or two? There's not been much discussion of this on either of > these lists. > > There are 4 "blockers" with target milestone 2.18, but there are 11 > bugs with the flag "blocking2.18". Using a criteria of "no regressions" we've got 8 bugs left, 6 of which are up for review right now. Once we get those in, we'll release an RC. Most of the others left on the list are extremely low-risk cosmetic nits that I don't have a problem fixing between the RC and the real release if they aren't done before the above 8 are. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Sun May 16 22:42:22 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 16 May 2004 23:42:22 +0100 Subject: Charts and Security Message-ID: <40A7EE4E.8080401@mozilla.org> Chaps, We have a small problem with the new charting system and security - in that it doesn't have any. Anyone with editbugs can view the charts, which leak the names of all products, even secure ones. This is all basically due to me not implementing a solution quick enough, and you all being very efficient about the other pre-requisites for 2.18. The names of the series are just text - i.e. there's no hard and fast link between them and the product names they happen to match. This is a feature, and probably a good one, but it makes automatic group management a little more tricky than otherwise. There are currently two proposed solutions: 1) Add group controls to the charts http://bugzilla.mozilla.org/show_bug.cgi?id=225687 This means each series has a group, and we intelligently put the migrated ones in groups. The various corners have been discussed and we have an implementation strategy, but it's a bit of work. I'm happy to do it, and even prioritise it, but it would unavoidably take an amount of time to get a working, tested patch reviewed and checked in. 2) Use a single "magic name" group (like timetracking) to control access to the lot http://bugzilla.mozilla.org/show_bug.cgi?id=243463 This means we have a single group which controls access to the whole thing. It was proposed as a stopgap solution if the above is too complex to implement for 2.18. It's easier to do, but I'm concerned that a) it leaves a migration problem if we want to do 1) later, and b) it doesn't actually provide a workable solution for a lot of sites, leaving them no option but to disable chart access for most people. Which would be sad. Views? Feel free to read the bugs to get expanded versions of the above summary. Neeeed sleeeep.... Gerv From justdave at bugzilla.org Mon May 17 02:29:26 2004 From: justdave at bugzilla.org (David Miller) Date: Sun, 16 May 2004 22:29:26 -0400 Subject: Charts and Security In-Reply-To: <40A7EE4E.8080401@mozilla.org> References: <40A7EE4E.8080401@mozilla.org> Message-ID: <40A82386.5000300@bugzilla.org> Gervase Markham wrote: > There are currently two proposed solutions: Actually 3, I proposed the third one on one of the other two bugs, I forget which... > 1) Add group controls to the charts > 2) Use a single "magic name" group (like timetracking) to control access > to the lot 3) Don't do any migration of old data from the old chart system, and leave it all in the old chart system for now. Remove the code which adds a new series when creating a new product. Perhaps only migrate the "-All-" data to use as a sample series. Then we leave the old chart system in place for now instead of getting rid of it. This leaves the existing security from the old chart system still protecting that data, and allows new charts to be public, and lets the admin create what they want. Just need to make sure that the "make this available to others" box that the admin sees explains that it's *really* public. At that point, the admin can probably choose what they think is safe to make public, or name things in such a way that it doesn't expose anything other than statistics. At a later date, when we're preparing to remove the old chart system, we can offer a standalone migration script for people to use to pull the data from the old chart system, and/or offer to invoke it (but not force them to) from checksetup.pl at that time. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Wed May 19 22:44:15 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 19 May 2004 23:44:15 +0100 Subject: Charts and Security In-Reply-To: <40A82386.5000300@bugzilla.org> References: <40A7EE4E.8080401@mozilla.org> <40A82386.5000300@bugzilla.org> Message-ID: <40ABE33F.2090008@mozilla.org> David Miller wrote: > 3) Don't do any migration of old data from the old chart system, and Yeah, we could do that too. :-) Although when we throw the switch, I'd make the migration compulsory rather than optional, setting the initial groups for each series as outlined in one of the bugs on the subject. Sounds good. Anyone else got any thoughts? Gerv From gerv at mozilla.org Mon May 24 23:18:23 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 25 May 2004 00:18:23 +0100 Subject: More thoughts on securing series Message-ID: <40B282BF.20602@mozilla.org> Joel and I just had a chat about securing charts. I won't do a timeless and just quote the entire IRC log, leaving you to figure out what was said ;-); here's an edited summary. Basically, joel suggested a bunch of stuff (including some things which have been proposed on the list) and I said what problems each idea had :-) Further comments very welcome. I am willing to carve out time to fix this properly, if Dave is willing to wait a few days for me to do so, and help tighten up the review cycle for the patch. Gerv Gerv: The problem with "release now with no migration, and migrate later" is that if we migrate at the start, it's guaranteed to succeed (no name clashes). If we migrate later, we have to deal with the issue that the users may have created a series with a name we want to use. Also, a non-zero number of installations on the 2.17 branch will have migrated already. joel: True. We just went through the same issue with adding a new system group "admin". joel: Though I think we place too much importance on the names as a key - which doesn't survive renames. If we are going to have the permissions follow those of a product, I would have a reference to the product's ID in the tables, but show the products name in the UI. Gerv: But not all series are related to products. That's the point - the names are totally arbitrary. [This is one of the big improvements over the previous version.] joel: If we want to name something after a product and that would have caused a collision, prepend/append a character to make it unique. Gerv: But that's really nasty. What happens if some series clash for a particular product, but others don't? Sorting the mess out for an admin would be a nightmare, particularly as they don't see private series. (It would make their UI unmanageable.) joel: I'd lean towards having the feature require enabling by the adminustrator and default to "off", that way we don't make anyone leak unless they are aware of the need to secure things. Gerv: We could do that, i.e. migrate the lot and have a special group for access, but that presents its own migration issues. For example, if we later implement group-based security, how do we retroactively apply it to all existing series? We can't make an admin do that by hand. There are hundreds of them. We could make a hacky "guessing" algorithm which tries to match product names to series categories, but I don't like that idea much. joel: We definitely should keep track of the product id when we auto-migrate or auto-create and think hard about the defaults. Gerv: But that makes some series special. What happens if we implement series editing, and the series changes to something else? It's already complicated enough :-) The only good answer is to fix this right. Gerv From bugreport at peshkin.net Thu May 27 19:35:03 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 27 May 2004 12:35:03 -0700 Subject: More thoughts on securing series In-Reply-To: <40B282BF.20602@mozilla.org> References: <40B282BF.20602@mozilla.org> Message-ID: <40B642E7.9040303@peshkin.net> Ok, here's the proposal. When creating a series, the creator can select a product with which the series is associated. The series is then only available/visible to users for whom that product would be selectable. The ID of that product is stored in the series table so that it will automatically track product renames. It also makes it possible for product renames to rename the series IF the associated series (or its category) has a name that is identical to the name of the product. When the series is run, it runs under the privileges of its creator. (optionally - let the creator indicate that a subset of the creator's privileges are to be used) Migration code and product creation code populates the product ID for any series created by that code, so there is no leak created. From kiko at async.com.br Thu May 27 20:46:10 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 27 May 2004 17:46:10 -0300 Subject: Login error when trying to use bugzilla-submit utility. In-Reply-To: <7D5AE17D4288D511A57F00508BE7FE6C8D765A@sockeye-mail.sockeye> References: <7D5AE17D4288D511A57F00508BE7FE6C8D765A@sockeye-mail.sockeye> Message-ID: <20040527204610.GH2561@async.com.br> (Hi everyone -- just in from Morocco) On Sun, Apr 25, 2004 at 07:21:48PM -0400, Kethees Murugupillai wrote: > I finally started migrating the TestTrack bugs to bugzilla but faced a > problem - when the status is set to AGGIGNED or CLOSED I get the following > error: > > bugzilla-submit: status 'ASSIGNED' is not a valid creation status in this > Bugzilla instance > bugzilla-submit: status 'CLOSED' is not a valid creation status in this > Bugzilla instance > > even though the status ASSIGNED and CLOSED exist in the database. Is it > because we can import only NEW bugs? Is there any way to import these bugs? Yes, you can currently only *open* NEW bugs. There could be a way around this, but it would require changes to the backend (we'd need a way to be able to force setting states upon bug creation, which would require a security evaluation of this feature since bugzilla-submit's interface is a simple CGI post). Anyone have an opinion on this? Importing bugs this way might be better served by a database import script. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From paulo.casanova at link.pt Fri May 28 15:30:28 2004 From: paulo.casanova at link.pt (Paulo Casanova) Date: Fri, 28 May 2004 16:30:28 +0100 Subject: Login error when trying to use bugzilla-submit utility. In-Reply-To: <20040527204610.GH2561@async.com.br> Message-ID: Well, you could always hack post_bug.cgi and, when CheckFormField is called (you can search for it as all calls are next each other) and change it from: CheckFormField(\%::FORM, 'bug_status', [$::unconfirmedstate, 'NEW']); to: CheckFormField(\%::FORM, 'bug_status', [$::unconfirmedstate, 'NEW', 'ASSIGNED', 'CLOSED']); of, course, I don't assume any responsability on this :) and you should but it back as soon as you have finished your migration... Note that I didn't test this and I'm not an expert on perl either :) Paulo On 5/27/04 21:46, "Christian Robottom Reis" wrote: > > (Hi everyone -- just in from Morocco) > > On Sun, Apr 25, 2004 at 07:21:48PM -0400, Kethees Murugupillai wrote: >> I finally started migrating the TestTrack bugs to bugzilla but faced a >> problem - when the status is set to AGGIGNED or CLOSED I get the following >> error: >> >> bugzilla-submit: status 'ASSIGNED' is not a valid creation status in this >> Bugzilla instance >> bugzilla-submit: status 'CLOSED' is not a valid creation status in this >> Bugzilla instance >> >> even though the status ASSIGNED and CLOSED exist in the database. Is it >> because we can import only NEW bugs? Is there any way to import these bugs? > > Yes, you can currently only *open* NEW bugs. There could be a way around > this, but it would require changes to the backend (we'd need a way to be > able to force setting states upon bug creation, which would require > a security evaluation of this feature since bugzilla-submit's interface > is a simple CGI post). Anyone have an opinion on this? > > Importing bugs this way might be better served by a database import > script. > > Take care, > -- > Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 > - > To view or change your list settings, click here: > From Kamal.Ahmed at esecurity.net Fri May 28 15:39:43 2004 From: Kamal.Ahmed at esecurity.net (Kamal Ahmed) Date: Fri, 28 May 2004 11:39:43 -0400 Subject: Login error when trying to use bugzilla-submit utility. Message-ID: <5513C07DE400274F9D90FF87B861873F350FF7@va-ex01> Hi Bugzilla List, Is there a good HOW TO on customizing Bugzilla. Thanks, -Kamal. From kiko at async.com.br Fri May 28 23:02:55 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 28 May 2004 20:02:55 -0300 Subject: Login error when trying to use bugzilla-submit utility. In-Reply-To: References: <20040527204610.GH2561@async.com.br> Message-ID: <20040528230254.GA5947@async.com.br> On Fri, May 28, 2004 at 04:30:28PM +0100, Paulo Casanova wrote: > > Well, you could always hack post_bug.cgi and, when CheckFormField is called > (you can search for it as all calls are next each other) and change it from: > > CheckFormField(\%::FORM, 'bug_status', [$::unconfirmedstate, 'NEW']); > > to: > > CheckFormField(\%::FORM, 'bug_status', [$::unconfirmedstate, 'NEW', > 'ASSIGNED', 'CLOSED']); > > of, course, I don't assume any responsability on this :) and you should but > it back as soon as you have finished your migration... Problem here is that not everyone should have rights to post ASSIGNED/CLOSED bugs, and there's currently no way to limit this in the permissions backend. But yeah, that would be an initial hack at least. Note that there's another, related check in the same file which sets the default status for the bug and forces it to UNCONFIRMED if the user doesn't have canconfirm or canedit privileges. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From justdave at bugzilla.org Sun May 30 04:48:04 2004 From: justdave at bugzilla.org (David Miller) Date: Sun, 30 May 2004 00:48:04 -0400 Subject: What do we do about 2.18? Message-ID: <40B96784.30806@bugzilla.org> In theory, we did a feature freeze on March 15th in preparation for the 2.18 release. A few things have slipped in here and there, but they've mostly been minor low-risk stuff. However, we still have 11 bugs left in the buglist that are pretty much blocker quality, and have sat there for a while. Meanwhile, there's several projects people have shown interest in landing soon, and have held off on putting major effort into them because they can't go in until after we branch for 2.18. Typically at this point in the release cycle, we don't branch until the first Release Candidate (RC) goes out (in an effort to get people to spend their labor on the release blockers). March 15th was 2 1/2 months ago. The freeze was only intended to last a month before RC. And here we still sit. I still intend to stick to the schedule for 2.20. It may happen a month after 2.18 does at this rate. :) Because of the number of big things waiting for us to branch, I'm confident 2.20 will be worth the version number bump, despite the short time frame. Because of the short time frame, I'm not so worried about it taking forever to push out the door like 2.18 is. So, that leaves us with a decision now. We either get as many folks to help as possible to kill off the last blockers, or we branch now and forget about waiting for an RC before we branch. Personally I'd really like to see 2.18 out sooner than later, which makes me want to continue to hold the branch hostage... Here's what's left: checksetup.pl fails to remove product index from milestones table in upgrade from 2.14.x => http://bugzilla.mozilla.org/show_bug.cgi?id=244756 Status: UNCONFIRMED - Needs someone to attempt to reproduce or find the code that's doing the wrong thing. If it can be reproduced or visually pointed out in the code, this is a release blocker. "View All" attachment statuses field empty => http://bugzilla.mozilla.org/show_bug.cgi?id=223541 Status: This is a small UI tweak, polish issue. Should be really easy if someone wants to tackle it. Data in question should be available to the template already, the template just needs to reference it properly. Flag system dies when changing a deleted flag => http://bugzilla.mozilla.org/show_bug.cgi?id=223878 Status: Needs a patch. Problem seems to have been identified in the bug comments, but no one has written a patch to fix it yet. Best fix is probably to find some way to make flag IDs unique so they never get reused (auto_increment?), and add the flag type to a hidden field in the form so it knows what to do if it encounters one that's been deleted. Add group controls to new charts => http://bugzilla.mozilla.org/show_bug.cgi?id=225687 This is kind of a security hole, but the bug is public because the problem has been publicly disclosed since the feature was introduced. The new chart system changes the way series are defined in the charts so that they're no longer explicitly tied to products. However, it migrates the old data and uses the product names for the series when it creates them. This means hidden products would have their names visible (but no actual bug data) unless the admin when back and deleted them from the new charts. Current status: lots of discussion about the best way to fix it. (see other threads on this list recently). The leading theory at the moment is to go ahead and make the new system (optionally) explicitly tie a series to a product, and make that tie on each of the datasets that are migrated from the old system. This is probably Gerv's baby, but the patch is going to be substantial and he'll need review help when it's done. We can't release 2.18 with this hole here though. Boolean charts are broken on reporting pages => http://bugzilla.mozilla.org/show_bug.cgi?id=179671 Status: has patch, waiting for review That's 5 bugs. We're close :) I'm going on vacation this coming week, and will probably be completely offline from later this morning until Sunday the 6th. It'd make my day if I came back to things being ready to go :) As always, you can still get approvals from Myk while I'm gone. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Sun May 30 04:58:52 2004 From: justdave at bugzilla.org (David Miller) Date: Sun, 30 May 2004 00:58:52 -0400 Subject: Customizing Bugzilla (was: Login error ... bugzilla-submit) In-Reply-To: <5513C07DE400274F9D90FF87B861873F350FF7@va-ex01> References: <5513C07DE400274F9D90FF87B861873F350FF7@va-ex01> Message-ID: <40B96A0C.8060002@bugzilla.org> Please start a new message with a new subject when you're asking a new question. This doesn't have anything to do with bugzilla-submit as the subject implied. Kamal Ahmed wrote: > Is there a good HOW TO on customizing Bugzilla. Yep. http://www.bugzilla.org/docs/html/customization.html Note that's for the cvs tip version (soon to be Bugzilla 2.18rc1) There is a similar section in the docs for 2.16.5, but it's very incomplete. Not all of that stuff will work in 2.16.x, but a lot of the basics will (which templates to edit and so forth) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Sun May 30 04:59:14 2004 From: justdave at bugzilla.org (David Miller) Date: Sun, 30 May 2004 00:59:14 -0400 Subject: What do we do about 2.18? In-Reply-To: <40B96784.30806@bugzilla.org> References: <40B96784.30806@bugzilla.org> Message-ID: <40B96A22.2050408@bugzilla.org> David Miller wrote: > However, we still have 11 bugs left > in the buglist that are pretty much blocker quality, and have sat there > for a while. Heh, the list shrank since I started composing that message and when I finished it (I actually had that compose window open for a couple days ;) The number at the bottom of the email (5) is correct. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From jth at mikrobitti.fi Sun May 30 07:58:37 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Sun, 30 May 2004 10:58:37 +0300 (EEST) Subject: What do we do about 2.18? In-Reply-To: <40B96784.30806@bugzilla.org> References: <40B96784.30806@bugzilla.org> Message-ID: On Sun, 30 May 2004, David Miller wrote: > So, that leaves us with a decision now. We either get as many folks to > help as possible to kill off the last blockers, or we branch now and > forget about waiting for an RC before we branch. Personally I'd really > like to see 2.18 out sooner than later, which makes me want to continue > to hold the branch hostage... Let's proceed as you've already planned. With some good luck, we should be in far better shape when you're back from your vacation. > "View All" attachment statuses field empty > => http://bugzilla.mozilla.org/show_bug.cgi?id=223541 > Status: This is a small UI tweak, polish issue. Should be really easy > if someone wants to tackle it. Data in question should be available to > the template already, the template just needs to reference it properly. I'll get this. > Flag system dies when changing a deleted flag > => http://bugzilla.mozilla.org/show_bug.cgi?id=223878 > Status: Needs a patch. Problem seems to have been identified in the bug > comments, but no one has written a patch to fix it yet. Best fix is > probably to find some way to make flag IDs unique so they never get > reused (auto_increment?), and add the flag type to a hidden field in the > form so it knows what to do if it encounters one that's been deleted. This is the former nuclear collision. I've debugged it (as can be seen in the bug) and I can also patch it, but we need a consensus on how to do that... As we've discussed in IRC, I'm not convinced on just having auto_increments; I'd prefer not deleting stuff at all. But I'll resummarize in the bug soon. Myk's opinion would be valuable, since he's the man behind the flags. Give me a couple of hours to come up with some proposals. Jouni From jth at mikrobitti.fi Sun May 30 09:24:44 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Sun, 30 May 2004 12:24:44 +0300 (EEST) Subject: What do we do about 2.18? In-Reply-To: References: <40B96784.30806@bugzilla.org> Message-ID: On Sun, 30 May 2004, Jouni Heikniemi wrote: > > "View All" attachment statuses field empty > > => http://bugzilla.mozilla.org/show_bug.cgi?id=223541 > I'll get this. This is now waiting for review. > Give me a couple of hours to come up with some proposals. I have posted some. If you know flags and/or search well, please give this monster a moment of your precious time: http://bugzilla.mozilla.org/show_bug.cgi?id=223878#c13 Jouni From gerv at mozilla.org Mon May 31 09:36:20 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 31 May 2004 10:36:20 +0100 Subject: HOW TO on customizing Bugzilla In-Reply-To: <5513C07DE400274F9D90FF87B861873F350FF7@va-ex01> References: <5513C07DE400274F9D90FF87B861873F350FF7@va-ex01> Message-ID: <40BAFC94.1060301@mozilla.org> Kamal Ahmed wrote: > Hi Bugzilla List, > > Is there a good HOW TO on customizing Bugzilla. Have you read the Bugzilla Guide? What is it that you want to do? Gerv From kristis.makris at asu.edu Mon May 31 00:08:39 2004 From: kristis.makris at asu.edu (Kristis Makris) Date: Sun, 30 May 2004 17:08:39 -0700 Subject: Scmbug Message-ID: <1085962119.1380.0.camel@syd.mkgnu.net> Greetings. I'd like to announce Scmbug, a tool providing integration of Source code Configuration Management with Bugtracking. It is meant to be a universal tool that can glue any source code version control system with any bugtracking tool, for all platforms. In the current development release, Scmbug supports integrating CVS with Bugzilla. The intention is to integrate other source code version control tools (e.g. Subversion) with other bugtracking systems (e.g. gnats) in a consistent and more flexible manner other independent tools currently do so (e.g. Tony Garnock-Jones' cvszilla from http://homepages.kcbbs.gen.nz/~tonyg/, Steve McIntyre's integration from http://www.einval.com/~steve/software/cvs-bugzilla/ ). I would encourage developers and users of integration glue to contribute to this general integration tool, rather than continue the fragmentation of individual tools attempting to resolve the same problem. The latest development release is available at: http://www.public.asu.edu/~makrists/scmbug/ Regards, Kristis Makris