From gerv at mozilla.org Mon Mar 1 10:42:07 2010 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 01 Mar 2010 10:42:07 +0000 Subject: Bugzilla: Philosophy In-Reply-To: References: <4B79420C.8030109@mozilla.org> <4aidnTEl7ICPXhrWnZ2dnUVZ_u5i4p2d@mozilla.org> Message-ID: On 27/02/10 03:50, Justin Wood (Callek) wrote: > help PEOPLE fix bugs. PEOPLE to fix bugs well usually wish to have a > project management system of some sort. In Mozilla Project Management > uses Bugzilla features for their ease of use, while I also *agree* it > should NOT be a project management system this point should be felt more > through the other goals rather than in opposition to them. Well, let's reconsider the question entirely, just as a thought experiment. Why do we want Bugzilla not to be a project management system? 1) It increases code complexity 2) It increases UI complexity 3) It spreads development and testing resources thinner ... Why might someone want Bugzilla to be a project management system? 1) There are organizational benefits of having your PMS and your task tracker closely integrated ... (any more for either list) So perhaps "Bugzilla is not a project management system" is not a bit of philosophy; it's more a practical restriction we have decided to make to avoid scope creep and focus our resources. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From fct.java at gmail.com Mon Mar 1 11:36:46 2010 From: fct.java at gmail.com (Francois Cottet) Date: Mon, 1 Mar 2010 19:36:46 +0800 Subject: Bugzilla: Philosophy In-Reply-To: References: <4B79420C.8030109@mozilla.org> <4aidnTEl7ICPXhrWnZ2dnUVZ_u5i4p2d@mozilla.org> Message-ID: <1acd1dcb1003010336w148622e2k59c9fd9748d87780@mail.gmail.com> Hi folks, While I agree that Bugzilla is not meant to replace any PMS, there are few enhancements which would be welcome. A simple one is a clear separation between bugs and enhancements. https://bugzilla.mozilla.org/show_bug.cgi?id=9412 "In my humble opinion" bugzilla is used in a more complex way than just a bug tracking system, most installation I have seen actually use Bugzilla as a "change tracking system". In my organization people (developers and managers) complain frequently about the interface, mainly because they can see at one glance what are the bugs and what are the enhancements. When a public release of a product is scheduled, people want to focus on bug fixing, while once the release is done and the product stable. We want to review the enhancement requests. Currently we use the "severity" field but it's a workaround and it seems that quite a few installations have to deal with that workaround. Best regards, Francois On Mon, Mar 1, 2010 at 18:42, Gervase Markham wrote: > On 27/02/10 03:50, Justin Wood (Callek) wrote: >> help PEOPLE fix bugs. PEOPLE to fix bugs well usually wish to have a >> project management system of some sort. In Mozilla Project Management >> uses Bugzilla features for their ease of use, while I also *agree* it >> should NOT be a project management system this point should be felt more >> through the other goals rather than in opposition to them. > > Well, let's reconsider the question entirely, just as a thought experiment. > > Why do we want Bugzilla not to be a project management system? > > 1) It increases code complexity > 2) It increases UI complexity > 3) It spreads development and testing resources thinner > ... > > Why might someone want Bugzilla to be a project management system? > > 1) There are organizational benefits of having your PMS and your task > tracker closely integrated > ... > > (any more for either list) > > So perhaps "Bugzilla is not a project management system" is not a bit of > philosophy; it's more a practical restriction we have decided to make to > avoid scope creep and focus our resources. > > Gerv > > > _______________________________________________ > dev-apps-bugzilla mailing list > dev-apps-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > - > To view or change your list settings, click here: > > _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From guy.pyrzak at gmail.com Mon Mar 1 15:47:18 2010 From: guy.pyrzak at gmail.com (Guy Pyrzak) Date: Mon, 1 Mar 2010 07:47:18 -0800 Subject: Bugzilla: Philosophy In-Reply-To: <1acd1dcb1003010336w148622e2k59c9fd9748d87780@mail.gmail.com> References: <4B79420C.8030109@mozilla.org> <4aidnTEl7ICPXhrWnZ2dnUVZ_u5i4p2d@mozilla.org> <1acd1dcb1003010336w148622e2k59c9fd9748d87780@mail.gmail.com> Message-ID: Bugzilla can be used for a LOT of things, trust me I'd know. But I think you're right Gerv, the "philosophy" is more about maintaining and narrowing scopes and features than "philosophy". Does that change anything about the reality of the tool? I don't think it does. However, what it might change is how we support people who want to make it more than a bug tracking system. Maybe we (the core developers) write a few enhancements to make bugzilla a more of a ticket tracker, or more of a PMS, but those are all extensions? Francois just pointed out that he has had to do a bit of work to get around the severity field's restrictions but there could be a few extensions or code organizations to make it easier to do (I do think we're headed in that direction as we move more fields into fields.js btw. However, as Max would point out, we can focus on extensions once Bugzilla isn't so unwieldy and unfriendly. So I was reading the first line (i stopped there because i realized it could become a whole new conversation). Gerv wrote: *To help people fix bugs in software.* Max wrote: *To help people store and organize bug reports.* I'm not sure either are great, however, Gerv your statement could also be applied to an IDE, which are actually used to "help people fix bugs in software" in fact if that was Bugzilla's philosophy then we'd need to add a debugger, something that lets users check in code from the UI, review the test cases against newly checked in code, stuff that testopia does... well you get the idea. Now many (myself included) would say "Geez don't be so litteral" but we all know that many folks will see Gerv's statement and start arguing for all sorts of new features. I'm not much of a word smith so I'm not going to try to say the 1 sentence, but I think it should include the words file/communicate, triage/understand, find, follow and disposition bugs. But as a developer the software that "helps me fix bugs in software" is my IDE or my debugger. My bug tracker just tells me what to do next, how bad the situation is for an existing bug(/component/product based on bugs filed), find out how people think a bug should be fixed and lets me tell others I'm done and when and also lets me find out what others users found wrong. To be clear to Gerv, I like your philosophy, but it doesn't fulfill the main purpose of stating this philosophy. So I'll state the reason/rationale for stating the philosophy.... *To avoid scope creep and feature enhancements on a product (Bugzilla) which is already unwieldy and not user friendly by many accounts*. So maybe the Bugzilla philosophy for now could be: *To not add any big new features that don't serve the purpose of simplifying and easing the use of existing features in Bugzilla.* * * But that's a tongue-in-cheek philosophy, so don't go posting this as the new Bugzilla philosophy! Besides we all know Bugzilla doesn't support fixing bugs on multiple branches very well, we should add that feature, erm i mean "enhancement" :P. -Guy On Mon, Mar 1, 2010 at 3:36 AM, Francois Cottet wrote: > Hi folks, > > While I agree that Bugzilla is not meant to replace any PMS, there are > few enhancements which would be welcome. > > A simple one is a clear separation between bugs and enhancements. > https://bugzilla.mozilla.org/show_bug.cgi?id=9412 > "In my humble opinion" bugzilla is used in a more complex way than > just a bug tracking system, most installation I have seen actually use > Bugzilla as a "change tracking system". > In my organization people (developers and managers) complain > frequently about the interface, mainly because they can see at one > glance what are the bugs and what are the enhancements. > > When a public release of a product is scheduled, people want to focus > on bug fixing, while once the release is done and the product stable. > We want to review the enhancement requests. > Currently we use the "severity" field but it's a workaround and it > seems that quite a few installations have to deal with that > workaround. > > Best regards, > Francois > > > > > > > On Mon, Mar 1, 2010 at 18:42, Gervase Markham wrote: > > On 27/02/10 03:50, Justin Wood (Callek) wrote: > >> help PEOPLE fix bugs. PEOPLE to fix bugs well usually wish to have a > >> project management system of some sort. In Mozilla Project Management > >> uses Bugzilla features for their ease of use, while I also *agree* it > >> should NOT be a project management system this point should be felt more > >> through the other goals rather than in opposition to them. > > > > Well, let's reconsider the question entirely, just as a thought > experiment. > > > > Why do we want Bugzilla not to be a project management system? > > > > 1) It increases code complexity > > 2) It increases UI complexity > > 3) It spreads development and testing resources thinner > > ... > > > > Why might someone want Bugzilla to be a project management system? > > > > 1) There are organizational benefits of having your PMS and your task > > tracker closely integrated > > ... > > > > (any more for either list) > > > > So perhaps "Bugzilla is not a project management system" is not a bit of > > philosophy; it's more a practical restriction we have decided to make to > > avoid scope creep and focus our resources. > > > > Gerv > > > > > > _______________________________________________ > > dev-apps-bugzilla mailing list > > dev-apps-bugzilla at lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > > - > > To view or change your list settings, click here: > > > > > _______________________________________________ > dev-apps-bugzilla mailing list > dev-apps-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mockodin at gmail.com Mon Mar 1 16:55:20 2010 From: mockodin at gmail.com (Michael Thomas) Date: Mon, 1 Mar 2010 08:55:20 -0800 Subject: Bugzilla: Philosophy In-Reply-To: References: <4B79420C.8030109@mozilla.org> <4aidnTEl7ICPXhrWnZ2dnUVZ_u5i4p2d@mozilla.org> <1acd1dcb1003010336w148622e2k59c9fd9748d87780@mail.gmail.com> Message-ID: <6b9407351003010855v7db159ccr94f0068c23bd92f6@mail.gmail.com> We seem to be trying to define exactly what bugzilla is or does. Is it a bug tracker, is it a development tool, is it etc.. It would seem to me that it is a open ended collection tool at the core. That is what it does right? Collect a bug report and record comments pertaining to. Sure it also categorizes, prioritizes, files, sorts... Sure it does more. But it could operate at that level at its most basic. Everything else is add-on.The word "Bug" could be swapped out with issue, or any number of other words or phrases to identify a single or group of individuals needs. The extension system that has been/is being implemented makes this feel more apparent. It can now or has, the potential to integrate with hundreds of third party applications and systems. That means it can serve any numbers of roles or even all of them with the same instance. While preventing scope creep is all well an good I would not want to start outright tossing or discouraging someones ideas because it didn't meet a specific ideal. Make it an extension. Perhaps provide a area to submit extensions for general consumption? Other than the core. Unless the goal is the become Microsoft... Gerv's "To help people fix bugs in software." I think meets that the best, it does not define how it helps, merely that the ability is there. /end comment on only a small part of the overall "Philosophy" conversation From guy.pyrzak at gmail.com Mon Mar 1 18:08:19 2010 From: guy.pyrzak at gmail.com (Guy Pyrzak) Date: Mon, 1 Mar 2010 10:08:19 -0800 Subject: Bugzilla: Philosophy In-Reply-To: <6b9407351003010855v7db159ccr94f0068c23bd92f6@mail.gmail.com> References: <4B79420C.8030109@mozilla.org> <4aidnTEl7ICPXhrWnZ2dnUVZ_u5i4p2d@mozilla.org> <1acd1dcb1003010336w148622e2k59c9fd9748d87780@mail.gmail.com> <6b9407351003010855v7db159ccr94f0068c23bd92f6@mail.gmail.com> Message-ID: Well i guess my question/rant were about "why do we need a philosophy?". The answer I came up with was "to figure out what goes is core to Bugzilla development and what is an extension" or "to figure out what core developers should work on next". Is that the reason why we need a philosophy? Stating a philosophy with out an actual use is fine, in which case done. But I'm more interested in the application of the philosophy. For example... - If someone wrote code that adds an integrated debugger into Bugzilla, core or extension? - If someone wrote code to encourage test driven development, core or an extension? - If someone wrote code to support syntax highlighting on patches, core or an extension? - If someone wrote code to integrate a wiki into bugzilla, core or extension? - If someone wrote code to show images inline with comments.. core or extension? - If someone wrote code that adds the "Getting Bugs Done" methodology... core or extension? - Do we add feature X or do we improve usability of feature Y? These are the sorts of questions that I'd like to see the philosophy attempt to answer. A bug tracker by its very nature "helps people fix bugs in software", but so do a bunch of other tools. So I'd like to see a philosophy that helps define a purpose beyond the fuzzy area of "fix bugs in software", I think we should and can be more specific. As someone who has hacked Bugzilla in more ways than I care to describe, I wan to know which of my hacks I can think about giving back to Bugzilla and which are extensions. -Guy On Mon, Mar 1, 2010 at 8:55 AM, Michael Thomas wrote: > We seem to be trying to define exactly what bugzilla is or does. Is it > a bug tracker, is it a development tool, is it etc.. > > It would seem to me that it is a open ended collection tool at the > core. That is what it does right? Collect a bug report and record > comments pertaining to. Sure it also categorizes, prioritizes, files, > sorts... Sure it does more. But it could operate at that level at its > most basic. Everything else is add-on.The word "Bug" could be swapped > out with issue, or any number of other words or phrases to identify a > single or group of individuals needs. > > The extension system that has been/is being implemented makes this > feel more apparent. It can now or has, the potential to integrate with > hundreds of third party applications and systems. That means it can > serve any numbers of roles or even all of them with the same instance. > While preventing scope creep is all well an good I would not want to > start outright tossing or discouraging someones ideas because it > didn't meet a specific ideal. Make it an extension. Perhaps provide a > area to submit extensions for general consumption? Other than the > core. > > Unless the goal is the become Microsoft... > > Gerv's "To help people fix bugs in software." I think meets that the > best, it does not define how it helps, merely that the ability is > there. > > /end comment on only a small part of the overall "Philosophy" conversation > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Mon Mar 1 22:07:57 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 01 Mar 2010 14:07:57 -0800 Subject: Bugzilla: Philosophy In-Reply-To: <1acd1dcb1003010336w148622e2k59c9fd9748d87780@mail.gmail.com> References: <4B79420C.8030109@mozilla.org> <4aidnTEl7ICPXhrWnZ2dnUVZ_u5i4p2d@mozilla.org> <1acd1dcb1003010336w148622e2k59c9fd9748d87780@mail.gmail.com> Message-ID: <4B8C3ABD.8070107@bugzilla.org> On 03/01/2010 03:36 AM, Francois Cottet wrote: > A simple one is a clear separation between bugs and enhancements. > https://bugzilla.mozilla.org/show_bug.cgi?id=9412 Yeah, that's one of our bz-hci2008 bugs, so it's at the top of our list. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Mon Mar 1 22:16:56 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 01 Mar 2010 14:16:56 -0800 Subject: Bugzilla: Philosophy In-Reply-To: References: <4B79420C.8030109@mozilla.org> <4aidnTEl7ICPXhrWnZ2dnUVZ_u5i4p2d@mozilla.org> <1acd1dcb1003010336w148622e2k59c9fd9748d87780@mail.gmail.com> Message-ID: <4B8C3CD8.6070404@bugzilla.org> On 03/01/2010 07:47 AM, Guy Pyrzak wrote: > But I think you're right Gerv, the "philosophy" is more about > maintaining and narrowing scopes and features than "philosophy". Just for clarity's sake, when I say "Philosophy", I mean definition 7 here: http://education.yahoo.com/reference/dictionary/entry/philosophy > Does > that change anything about the reality of the tool? I don't think it does. But this is true, too. :-) > However, as Max would point out, we can focus on extensions once > Bugzilla isn't so unwieldy and unfriendly. Sure! But I do agree with you about all the other points you made, too. > Gerv wrote: *To help people fix bugs in software.* > Max wrote: *To help people store and organize bug reports.* > > I'm not sure either are great, however, Gerv your statement could also > be applied to an IDE, which are actually used to "help people fix bugs > in software" in fact if that was Bugzilla's philosophy then we'd need to > add a debugger,[snip] That was my thought too. I did actually have a thought about how to integrate them, I'm just not too certain that it's right, yet. Perhaps: The purpose of Bugzilla is to help people store and organize bug reports so that they can be addressed. > To be clear to Gerv, I like your philosophy, but it doesn't fulfill the > main purpose of stating this philosophy. So I'll state the > reason/rationale for stating the philosophy.... > > *To avoid scope creep and feature enhancements on a product (Bugzilla) > which is already unwieldy and not user friendly by many accounts*. Pretty much. If you want to know a bit more about my thoughts on it: http://www.codesimplicity.com/post/the-purpose-of-software/ http://www.codesimplicity.com/post/specific-solutions/ http://www.codesimplicity.com/post/features-simplicity-and-the-purpose-of-software/ > So maybe the Bugzilla philosophy for now could be: > *To not add any big new features that don't serve the purpose of > simplifying and easing the use of existing features in Bugzilla.* :-) That's pretty much been my personal focus lately on the project. That does seem like our short-term goal at the moment. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From dmarshal at yahoo-inc.com Mon Mar 1 23:40:10 2010 From: dmarshal at yahoo-inc.com (David Marshall) Date: Mon, 01 Mar 2010 15:40:10 -0800 Subject: Bugzilla: Philosophy In-Reply-To: <4B8C3CD8.6070404@bugzilla.org> Message-ID: On 3/1/10 2:16 PM, "Max Kanat-Alexander" wrote: > > Perhaps: > > The purpose of Bugzilla is to help people store and organize bug > reports so that they can be addressed. > If I may offer a paraphrasing of the "vision statement" I had to write a while back: "The purpose of Bugzilla is to help people record and find information they need to fix bugs effectively." I offer this as a compromise between Max's and Gerv's statements. Hopefully no one is using Bugzilla because they just like to store and organize bug reports, so I think Max's statement makes bug reports seem more like an end than the means. On the other hand, Gerv's statement is a little too vague about exactly how Bugzilla is going to help people fix bugs in software. So let's say I'm engaged in the business of fixing bugs - how is Bugzilla going to help me do that? I argue that it can best help me do that by firstly being a place that I (or others) can record information about the bugs I am fixing. If I am recording a lot of data, however, it may be difficult to use it effectively, and thus Bugzilla secondly helps me find the information (among all the information that has been recorded) that I actually need to do the fixing. Max suggests at the bottom of the Philosophy page that the phrasing of new features should be "Bugzilla is preventing me from storing and organizing bug reports because..." I think that's too general. I would break it down to "Bugzilla is preventing me from recording information because..." or "Bugzilla is preventing me from finding information because..." Of course, the more general problem statement should be "Bugzilla is preventing me from fixing bugs effectively because...," with the supposition that Bugzilla is limited to recording and retrieving information. From lpsolit at gmail.com Tue Mar 2 16:58:18 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 02 Mar 2010 17:58:18 +0100 Subject: Bugzilla: Philosophy In-Reply-To: References: Message-ID: <4B8D43AA.8050505@gmail.com> Le 02. 03. 10 00:40, David Marshall a ?crit : > If I may offer a paraphrasing of the "vision statement" I had to write a > while back: > > "The purpose of Bugzilla is to help people record and find information they > need to fix bugs effectively." I like it! :) LpSolit From mkanat at bugzilla.org Tue Mar 2 23:12:03 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 02 Mar 2010 15:12:03 -0800 Subject: Bugzilla: Philosophy In-Reply-To: References: Message-ID: <4B8D9B43.1050004@bugzilla.org> On 03/01/2010 03:40 PM, David Marshall wrote: > "The purpose of Bugzilla is to help people record and find information they > need to fix bugs effectively." That sounds nice, but there are a lot of people who aren't fixing bugs who are using Bugzilla. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Tue Mar 2 23:31:32 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 03 Mar 2010 00:31:32 +0100 Subject: Bugzilla: Philosophy In-Reply-To: <4B8D9B43.1050004@bugzilla.org> References: <4B8D9B43.1050004@bugzilla.org> Message-ID: <4B8D9FD4.2040200@gmail.com> Le 03. 03. 10 00:12, Max Kanat-Alexander a ?crit : > That sounds nice, but there are a lot of people who aren't fixing bugs > who are using Bugzilla. But I think its primary goal is to fix bugs. LpSolit From mkanat at bugzilla.org Wed Mar 3 00:10:40 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 02 Mar 2010 16:10:40 -0800 Subject: Bugzilla: Philosophy In-Reply-To: <4B8D9FD4.2040200@gmail.com> References: <4B8D9B43.1050004@bugzilla.org> <4B8D9FD4.2040200@gmail.com> Message-ID: <4B8DA900.9010609@bugzilla.org> On 03/02/2010 03:31 PM, Fr?d?ric Buclin wrote: > But I think its primary goal is to fix bugs. That's fine, but "...they need to fix bugs effectively" grammatically indicates that our purpose would be only for the bug fixers. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Wed Mar 3 00:18:48 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 02 Mar 2010 16:18:48 -0800 Subject: Bugzilla: Philosophy In-Reply-To: References: Message-ID: <4B8DAAE8.6080705@bugzilla.org> On 03/01/2010 03:40 PM, David Marshall wrote: > "The purpose of Bugzilla is to help people record and find information they > need to fix bugs effectively." How about this? "The purpose of Bugzilla is to help people store and organize information about bugs so that bugs can be fixed effectively." "find" isn't broad enough, because it doesn't include reporting, etc. "record" might be fine, but I'm not quite as sure about it as I am about "store". -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Wed Mar 3 00:20:37 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 02 Mar 2010 16:20:37 -0800 Subject: Bugzilla: Philosophy In-Reply-To: <4B8DAAE8.6080705@bugzilla.org> References: <4B8DAAE8.6080705@bugzilla.org> Message-ID: <4B8DAB55.80208@bugzilla.org> On 03/02/2010 04:18 PM, Max Kanat-Alexander wrote: > "record" might be fine, but I'm not quite as sure about it as I am about > "store". Thinking about this a bit more--management, who doesn't file bugs, is more concerned about the storage of the reports than the recording of them, as an example. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From dmarshal at yahoo-inc.com Wed Mar 3 01:42:42 2010 From: dmarshal at yahoo-inc.com (David Marshall) Date: Tue, 02 Mar 2010 17:42:42 -0800 Subject: Bugzilla: Philosophy In-Reply-To: <4B8DAAE8.6080705@bugzilla.org> Message-ID: On 3/2/10 4:18 PM, "Max Kanat-Alexander" wrote: > On 03/01/2010 03:40 PM, David Marshall wrote: >> "The purpose of Bugzilla is to help people record and find information they >> need to fix bugs effectively." > > How about this? > > "The purpose of Bugzilla is to help people store and organize > information about bugs so that bugs can be fixed effectively." > > "find" isn't broad enough, because it doesn't include reporting, etc. > "record" might be fine, but I'm not quite as sure about it as I am about > "store". I didn't intend my statement to be parsed so literally that anyone who does not actually file bugs, perform searches, or personally fix bugs would feel disenfranchised. I tried to state the generic purpose as concisely and briefly as possible. My final suggestion, with a rather verbose explanation following: "Bugzilla help people and organizations fix bugs effectively by cataloging bug reports and coordinating effort." We should focus on the ends rather than the means, which is why I don't think the statement of purpose should be "to store and organize bug reports." To what specific end should anyone use Bugzilla? We need to state that clearly enough so that someone who really wants project management or a general ticket system doesn't choose Bugzilla instead of a more appropriate tool. I believe that the specific end is fixing bugs. People who don't actually fix bugs by editing code are still in the enterprise of bug fixing. You don't need Bugzilla (or anything similar) to fix bugs, but if you want to do it well or "effectively," you probably need Bugzilla or similar. How does Bugzilla help them achieve the end? The statement of the means should (in my opinion) be subordinate to the statement of the end. After some thought about terms like "find," "store," "record," and "organize," I think the best word for what Bugzilla does with data is "catalog." We should also include something about how Bugzilla implements workflow, sends email, etc. "Collaboratively" is way too hackneyed now, unfortunately. End: Bugzilla helps people and organizations fix bugs effectively Means #1: by cataloging bug reports Means #2: by coordinating effort P.S. I could go on all day about shades of meaning in words, but I have to get off that merry-go-round! I don't feel personally invested in whatever the final wording is. P.P.S. "To Fix Bugs" -- it's a cookbook! From mkanat at bugzilla.org Wed Mar 3 02:03:34 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 02 Mar 2010 18:03:34 -0800 Subject: Bugzilla: Philosophy In-Reply-To: References: Message-ID: <4B8DC376.1020509@bugzilla.org> On 03/02/2010 05:42 PM, David Marshall wrote: > I didn't intend my statement to be parsed so literally that anyone who does > not actually file bugs, perform searches, or personally fix bugs would feel > disenfranchised. I tried to state the generic purpose as concisely and > briefly as possible. Yeah, I know. But the purpose itself has to be complete and fully understandable by anybody, with no context, or it's just not simple enough. > "Bugzilla help people and organizations fix bugs effectively by cataloging > bug reports and coordinating effort." Coordinating effort is something that people do. "Cataloging" is a pretty good word. My only concern would be that some people might not understand the full definition of it, but it is very possibly the best word for the job. :-) > To what specific end should anyone use Bugzilla? We need to state that > clearly enough so that someone who really wants project management or a > general ticket system doesn't choose Bugzilla instead of a more appropriate > tool. I agree! > We should also include something about how Bugzilla implements workflow, > sends email, etc. "Collaboratively" is way too hackneyed now, > unfortunately. "Collaboratively" might be the right word, though. > P.S. I could go on all day about shades of meaning in words, but I have to > get off that merry-go-round! I don't feel personally invested in whatever > the final wording is. Hahaha. Well, it's actually, to me, about what the purpose *is*, and that's why I'm talking about the words--because the words are going to be the only solid, agreed-upon representation of the purpose that we have, both for ourselves and for any future developers or users of Bugzilla. So I want them to be as accurate as possible. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Wed Mar 3 13:16:34 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 03 Mar 2010 14:16:34 +0100 Subject: Bugzilla: Philosophy In-Reply-To: <4B8DC376.1020509@bugzilla.org> References: <4B8DC376.1020509@bugzilla.org> Message-ID: <4B8E6132.2000907@gmail.com> Le 03. 03. 10 03:03, Max Kanat-Alexander a ?crit : > Hahaha. Well, it's actually, to me, about what the purpose *is*, and > that's why I'm talking about the words--because the words are going to > be the only solid, agreed-upon representation of the purpose that we > have, both for ourselves and for any future developers or users of > Bugzilla. So I want them to be as accurate as possible. But in the mean time, I would update Bugzilla:Philosophy to use what dwm suggests, which is more accurate than the current text. And you can then improve it later. LpSolit From gerv at mozilla.org Wed Mar 3 14:28:52 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 03 Mar 2010 14:28:52 +0000 Subject: Bugzilla: Philosophy In-Reply-To: References: <4B79420C.8030109@mozilla.org> <4aidnTEl7ICPXhrWnZ2dnUVZ_u5i4p2d@mozilla.org> Message-ID: On 01/03/10 11:36, Francois Cottet wrote: > In my organization people (developers and managers) complain > frequently about the interface, mainly because they can see at one > glance what are the bugs and what are the enhancements. An easy fix for that would be to add a style so enhancements have a different-colour background. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Mar 3 14:30:53 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 03 Mar 2010 14:30:53 +0000 Subject: Bugzilla: Philosophy In-Reply-To: References: Message-ID: On 01/03/10 23:40, David Marshall wrote: > "The purpose of Bugzilla is to help people record and find information they > need to fix bugs effectively." Yes, I like this. It's better than mine. I agree mine is too vague. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Mar 3 14:33:25 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 03 Mar 2010 14:33:25 +0000 Subject: Bugzilla: Philosophy In-Reply-To: References: Message-ID: On 02/03/10 23:12, Max Kanat-Alexander wrote: > On 03/01/2010 03:40 PM, David Marshall wrote: >> "The purpose of Bugzilla is to help people record and find information they >> need to fix bugs effectively." > > That sounds nice, but there are a lot of people who aren't fixing bugs > who are using Bugzilla. But the point, surely, is to define what goals we are working towards, not have something general enough to encompass everything people might possibly want to do. I can use a screwdriver to lever open a can of paint. Should the creator of the screwdriver object? No. But would they have a right to say no if I said "please make the end of the screwdriver concave so it would open paint cans better"? Of course. Because the _purpose_ is to be a screwdriver, and the change makes it a worse screwdriver. Similarly, we need to figure out if people who are using Bugzilla to do things other than track bugs are people whose (different) requirements we want to be taking into account, or whether we just think "how nice for them" and go back to working on a bug tracker. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Mar 3 14:36:03 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 03 Mar 2010 14:36:03 +0000 Subject: Bugzilla: Philosophy In-Reply-To: References: Message-ID: On 03/03/10 00:18, Max Kanat-Alexander wrote: > "find" isn't broad enough, because it doesn't include reporting, etc. True. So let's not ask: "how can we change the philosophy to include reporting", but "should reporting be part of the Bugzilla core?". Most of the serious reporting done on Bugzilla within Mozilla is done by exporting the data into a different sort of database more optimized for reporting (see e.g. dascher's work using CouchDB, but also murali's work). Should we be moving towards a world where we support external dedicated tools for reporting (from CSV export right up to Crystal Reports) rather than doing it ourselves? Perhaps too big a question for now. But my point is: let's not write a philosophy with the aim of having it cover everything we do at the moment. Because if we succeed, then we haven't learned anything :-) Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Fri Mar 5 04:56:13 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 04 Mar 2010 20:56:13 -0800 Subject: Loggerhead is all better, now Message-ID: <4B908EED.2060604@bugzilla.org> So, loggerhead (the web view of bzr.mozilla.org) was having some trouble, as you probably know if you ever tried to use it. justdave just now downgraded us to a stable release of loggerhead, and the annoying "KeyError" problems are all gone now. Basically, the site works reliably, now. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From byron at glob.com.au Fri Mar 5 08:25:04 2010 From: byron at glob.com.au (Byron Jones) Date: Fri, 05 Mar 2010 16:25:04 +0800 Subject: windows installer - eyeballs needed Message-ID: <351c2b10c8371217fd2559aecbb82318@localhost> morning all, i've assembled a windows nsis installer for bugzilla, which installs: bugzilla 3.4.5 strawberry perl mysql apache the installer deploys and configures the applications to a point where bugzilla is ready to run, including installation of the windows services and addition of scheduled tasks (for collectstats, whining and creating a database dump for backups). i would appreciate another set of eyes across the installer, as well as testing in whatever environment you can get your hands on :) i've tested it in windows 2003 and xp. the setup is at and is about 76 MB. important nsis files and batch files are under the nsis subdirectory. thanks! -- byron.jones :: http://glob.com.au From ahdevans at gmail.com Fri Mar 5 16:30:01 2010 From: ahdevans at gmail.com (Aaron Evans) Date: Fri, 5 Mar 2010 08:30:01 -0800 Subject: windows installer - eyeballs needed In-Reply-To: <351c2b10c8371217fd2559aecbb82318@localhost> References: <351c2b10c8371217fd2559aecbb82318@localhost> Message-ID: <36fce4891003050830r781b707fg9f81632e28a0447c@mail.gmail.com> Byron- I've got WinXP and will try it out. I've already got ActiveState Perl 5.1, Apache 2.2, and MySQL 5.1 installed, so that might see what it does with ports and paths. -Aaron On Fri, Mar 5, 2010 at 12:25 AM, Byron Jones wrote: > morning all, > > i've assembled a windows nsis installer for bugzilla, which installs: > > bugzilla 3.4.5 > strawberry perl > mysql > apache > > the installer deploys and configures the applications to a point where > bugzilla is ready to run, including installation of the windows services > and addition of scheduled tasks (for collectstats, whining and creating a > database dump for backups). > > > i would appreciate another set of eyes across the installer, as well as > testing in whatever environment you can get your hands on :) i've tested > it in windows 2003 and xp. > > the setup is at and is > about 76 MB. important nsis files and batch files are under the nsis > subdirectory. > > > > > thanks! > > > -- > > byron.jones :: http://glob.com.au > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwierenga at gmail.com Sat Mar 6 01:09:31 2010 From: dwierenga at gmail.com (Dan Wierenga) Date: Fri, 5 Mar 2010 17:09:31 -0800 Subject: windows installer - eyeballs needed In-Reply-To: <351c2b10c8371217fd2559aecbb82318@localhost> References: <351c2b10c8371217fd2559aecbb82318@localhost> Message-ID: On Fri, Mar 5, 2010 at 12:25 AM, Byron Jones wrote: > > i would appreciate another set of eyes across the installer, as well as > testing in whatever environment you can get your hands on :) ?i've tested > it in windows 2003 and xp. Looks great! A few things I noticed, installing on Windows Vista Enterprise: - the database password fields need some additional description. I wasn't sure if I was "being asked for existing ones" or "setting new ones". - the password fields need masking. Very important especially considering you're asking for a Windows account password. I think in the ini file you can do "Type=Password" instead of "Type=Text" - the scheduled tasks pop up a black cmd.exe window every time they run. I can't see a desktop interaction like that going over very well, even if Bugzilla is meant to run as a "server-class" application. - apache failed because IIS was running and already bound to port 80. Maybe that's not going to be the typical case but it's probably useful to try to detect. When I stopped IIS and tried to start the apache service, I go this in the event logs: The Apache service named reported the following error: >>> httpd.exe: Syntax error on line 35 of C:/Program Files/Bugzilla/apache/conf/httpd.conf: ServerRoot must be a valid directory Line 35 of the httpd.conf is "ServerRoot "C:/bugzilla/apache" After changing that to ServerRoot "C:/Program Files/bugzilla/apache" I get this in the event logs: The Apache service named reported the following error: >>> Syntax error on line 178 of C:/Program Files/Bugzilla/apache/conf/httpd.conf: . (yes, that's correct, just a line number and then a blank error). line 178 is DocumentRoot "C:/bugzilla/bugzilla" which is also wrong. I pretty much stopped testing there as it seems the httpd.conf still needs some love. :D Great job so far though, it's pretty close. -Dan From KeenToKnow at Newsgroup.nospam Sat Mar 6 20:07:00 2010 From: KeenToKnow at Newsgroup.nospam (Axel Dahmen) Date: Sat, 6 Mar 2010 21:07:00 +0100 Subject: show_bug.cgi should provide separate form for adding comments Message-ID: <__KdnV6wWKV1KA_WnZ2dnUVZ_v6dnZ2d@mozilla.org> Hi there, recently I was monitoring a bug that was quite active... In order to get the latest postings on this bug I refreshed the page regularly and added a new comment when appropriate. Then suddenly, a Mozilla member urged me not to always set the Component field back to some other value... I was quite baffled, because I didn't update any of the fields. I just added comments to the bug. (#546930) Then I noticed that *all* the fields of a bug get updated whenever a comment is added to the bug. And although I had pressed to refresh the page, apparently not all field elements are reset to the page's default value then. I believe adding comments is quite a different task than changing a bug's properties. More than that: After a couple of comments have been added to a bug, the header information becomes more and more unimportant to the user (particularly to a User anyway, I should add). So I suggest to implement two different forms on the show_bug.cgi page: One to update a bug's features and another, distinct, form to add a new comment to the bug. Axel Dahmen _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Sun Mar 7 00:43:39 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 06 Mar 2010 16:43:39 -0800 Subject: show_bug.cgi should provide separate form for adding comments In-Reply-To: <__KdnV6wWKV1KA_WnZ2dnUVZ_v6dnZ2d@mozilla.org> References: <__KdnV6wWKV1KA_WnZ2dnUVZ_v6dnZ2d@mozilla.org> Message-ID: <4B92F6BB.9090205@bugzilla.org> On 03/06/2010 12:07 PM, Axel Dahmen wrote: > So I suggest to implement two different forms on the show_bug.cgi page: > One to update a bug's features and another, distinct, form to add a new > comment to the bug. Hey Axel. The best place to make feature suggestions is using bugzilla.mozilla.org. Here's a bit of info about making a report there about Bugzilla: http://www.bugzilla.org/developers/reporting_bugs.html -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From nbezzala at yahoo.com Sun Mar 7 11:58:51 2010 From: nbezzala at yahoo.com (Nitish Bezzala) Date: Sun, 7 Mar 2010 03:58:51 -0800 (PST) Subject: windows installer - eyeballs needed In-Reply-To: <351c2b10c8371217fd2559aecbb82318@localhost> References: <351c2b10c8371217fd2559aecbb82318@localhost> Message-ID: <673340.43209.qm@web114009.mail.gq1.yahoo.com> - the scheduled tasks pop up a black cmd.exe window every time they run. Uninstall works fine for everthing except the scheduled tasks. The black window still appears and disappears very quickly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From byron at glob.com.au Mon Mar 8 04:30:13 2010 From: byron at glob.com.au (Byron Jones) Date: Mon, 08 Mar 2010 12:30:13 +0800 Subject: windows installer - eyeballs needed In-Reply-To: <351c2b10c8371217fd2559aecbb82318@localhost> References: <351c2b10c8371217fd2559aecbb82318@localhost> Message-ID: <0bcb3e27fb6a57ef147f814ddacf1215@localhost> thanks to everyone who replied with feedback :) i've uploaded a new nsis setup to http://landfill.bugzilla.org/win32installer/ which addresses the following issues: - fixed mysql configuration when using a non-standard port - fixed scheduled tasks displaying the cmd window - scheduled tasks removed when uninstalled - scheduled tasks password field in setup no longer shows password - added blurb indicating we're setting mysql passwords, not requesting them -- byron.jones :: http://glob.com.au From lpsolit at gmail.com Mon Mar 8 22:28:46 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Mon, 08 Mar 2010 23:28:46 +0100 Subject: windows installer - eyeballs needed In-Reply-To: <0bcb3e27fb6a57ef147f814ddacf1215@localhost> References: <351c2b10c8371217fd2559aecbb82318@localhost> <0bcb3e27fb6a57ef147f814ddacf1215@localhost> Message-ID: <4B957A1E.2000109@gmail.com> Congratulations Byron for the Windows installer; it's working great! :) I just have a few comments: - As mentioned by Dan last week-end, the password fields should not display the root and bugs passwords in clear text. Maybe type=Password would do it. - You should remove ImageMagick from the installer. It takes 49Mb on the disk for very little benefit, especially when you know that it's gone from Bugzilla 3.6. - You should include compiled documentation instead of the XML files only. When you click the "Help" links at the top of pages, you get a "Not Found" error. Either that, or make the docs_urlbase parameter point to http://www.bugzilla.org/docs/3.4/en/html/ by default. - When checksetup.pl is done, you have to press any key to make the cmd.exe window to go away. Is that intentional? - Could we make MySQL and Apache detect if the ports are already in use, and if yes, either the installer suggests to use other ports, or it should make clear that existing MySQL and Apache installations will be used instead. - Also, the installer should make sure it's not using an existing DB, if possible. I just realized that it was using an existing DB used by Bugzilla 3.7, because I left the default MySQL port alone, and so it's using my existing MySQL server. Not sure how Bugzilla 3.4.5 will behave with a DB generated by Bugzilla 3.7. Bad, probably. :) I think that's all for now. :) Good job! LpSolit From byron at glob.com.au Tue Mar 9 01:19:10 2010 From: byron at glob.com.au (Byron Jones) Date: Tue, 09 Mar 2010 09:19:10 +0800 Subject: windows installer - eyeballs needed In-Reply-To: <4B957A1E.2000109@gmail.com> References: <351c2b10c8371217fd2559aecbb82318@localhost> <0bcb3e27fb6a57ef147f814ddacf1215@localhost> <4B957A1E.2000109@gmail.com> Message-ID: <10acf3c5ab6a410d666db1a78b747a03@localhost> > Congratulations Byron for the Windows installer; it's working great! :) thanks :) > - As mentioned by Dan last week-end, the password fields should not > display the root and bugs passwords in clear text. Maybe type=Password > would do it. ok, i'll look at doing that. it's more than just changing the field type, as i'll have to have two password fields for each username, and there isn't the real-estate on that screen for that. > - You should remove ImageMagick from the installer. It takes 49Mb on the > disk for very little benefit, especially when you know that it's gone > from Bugzilla 3.6. ok > - You should include compiled documentation instead of the XML files > only. When you click the "Help" links at the top of pages, you get a > "Not Found" error. Either that, or make the docs_urlbase parameter point > to http://www.bugzilla.org/docs/3.4/en/html/ by default. oops; i'll include the html docs for 3.4 now. > - When checksetup.pl is done, you have to press any key to make the > cmd.exe window to go away. Is that intentional? yes; if there's any errors you need to be able to read them :) > - Could we make MySQL and Apache detect if the ports are already in use, > and if yes, either the installer suggests to use other ports, or it > should make clear that existing MySQL and Apache installations will be > used instead. > > - Also, the installer should make sure it's not using an existing DB, if > possible. both of these are possible, i'll see what i can do :) thanks again for your feedback :) -- byron.jones :: http://glob.com.au From KeenToKnow at Newsgroup.nospam Tue Mar 9 23:12:03 2010 From: KeenToKnow at Newsgroup.nospam (Axel Dahmen) Date: Wed, 10 Mar 2010 00:12:03 +0100 Subject: show_bug.cgi should provide separate form for adding comments In-Reply-To: References: <__KdnV6wWKV1KA_WnZ2dnUVZ_v6dnZ2d@mozilla.org> Message-ID: Ah, I see... Great, thanks for pointing me, Max! ----------- "Max Kanat-Alexander" schrieb im Newsbeitrag news:mailman.6538.1267922653.4112.dev-apps-bugzilla at lists.mozilla.org... > On 03/06/2010 12:07 PM, Axel Dahmen wrote: >> So I suggest to implement two different forms on the show_bug.cgi page: >> One to update a bug's features and another, distinct, form to add a new >> comment to the bug. > > Hey Axel. The best place to make feature suggestions is using > bugzilla.mozilla.org. Here's a bit of info about making a report there > about Bugzilla: > > http://www.bugzilla.org/developers/reporting_bugs.html > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla and Perl Services. Everything Else, too. > - > To view or change your list settings, click here: > _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From dmarshal at yahoo-inc.com Wed Mar 10 01:53:51 2010 From: dmarshal at yahoo-inc.com (David Marshall) Date: Tue, 09 Mar 2010 17:53:51 -0800 Subject: Considering adding a serial counter to bugs_activity Message-ID: I have a requirement for a special-use Bugzilla to provide a complete record of activity since some earlier point. It would be OK if this included overlapping events that might be an artifact of using timestamps, but we'd prefer to avoid overlap, of course. My first thought is to add an activity_id to table bugs_activity which would essentially be a transaction counter. An external web service client would request details about activity that have occurred since event #231234, for instance. This almost certainly implies including the creation of bugs/attachments/comments as entries in bugs_activity. Any initial thoughts about this? From byron at glob.com.au Wed Mar 10 04:28:41 2010 From: byron at glob.com.au (Byron Jones) Date: Wed, 10 Mar 2010 12:28:41 +0800 Subject: windows installer - eyeballs needed In-Reply-To: <10acf3c5ab6a410d666db1a78b747a03@localhost> References: <351c2b10c8371217fd2559aecbb82318@localhost> <0bcb3e27fb6a57ef147f814ddacf1215@localhost> <4B957A1E.2000109@gmail.com> <10acf3c5ab6a410d666db1a78b747a03@localhost> Message-ID: another update to the win32 installer; http://landfill.bugzilla.org/win32installer/ changes since last version: - all password fields in nsis masked (and duplicated) - removed imagemagick - includes html documentation - detects and warns if mysql port is in use - detects and warns if http port is in use - warns if you point it to an existing bugzilla database -- byron.jones :: http://glob.com.au From mkanat at bugzilla.org Wed Mar 10 13:37:09 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 10 Mar 2010 05:37:09 -0800 Subject: Considering adding a serial counter to bugs_activity In-Reply-To: References: Message-ID: <4B97A085.40608@bugzilla.org> On 03/09/2010 05:53 PM, David Marshall wrote: > My first thought is to add an activity_id to table bugs_activity which would > essentially be a transaction counter. An external web service client would > request details about activity that have occurred since event #231234, for > instance. > > This almost certainly implies including the creation of > bugs/attachments/comments as entries in bugs_activity. > > Any initial thoughts about this? That's something we're going to probably have to do anyway, in order to have a Bugzilla::ChangeSet object. However, we want the id to be by ChangeSet, not by each individual field change. There's a bug filed about creating a bug_update table, which would probably just contain an id and a date, and then the bugs_activity table could use that id by reference. Of course, we wouldn't just do this for no reason--we'd have to be actually using it for some purpose within the Bugzilla codebase, such as for a Bugzilla::ChangeSet object. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mockodin at gmail.com Wed Mar 10 15:29:18 2010 From: mockodin at gmail.com (mockodin at gmail.com) Date: Wed, 10 Mar 2010 15:29:18 +0000 Subject: Considering adding a serial counter to bugs_activity Message-ID: <1789702433-1268234833-cardhu_decombobulator_blackberry.rim.net-2078926989-@bda822.bisx.prod.on.blackberry> I pointed out at one point that id columns are needed for future large installations using mssql as without a primarykey you will rowscan, causing exceptionally heavy cost on relatively simple hookups .. Let alone a complex one. ------Original Message------ From: Max Kanat-Alexander Sender: developers-owner at bugzilla.org To: developers at bugzilla.org ReplyTo: developers at bugzilla.org Subject: Re: Considering adding a serial counter to bugs_activity Sent: Mar 10, 2010 5:37 AM On 03/09/2010 05:53 PM, David Marshall wrote: > My first thought is to add an activity_id to table bugs_activity which would > essentially be a transaction counter. An external web service client would > request details about activity that have occurred since event #231234, for > instance. > > This almost certainly implies including the creation of > bugs/attachments/comments as entries in bugs_activity. > > Any initial thoughts about this? That's something we're going to probably have to do anyway, in order to have a Bugzilla::ChangeSet object. However, we want the id to be by ChangeSet, not by each individual field change. There's a bug filed about creating a bug_update table, which would probably just contain an id and a date, and then the bugs_activity table could use that id by reference. Of course, we wouldn't just do this for no reason--we'd have to be actually using it for some purpose within the Bugzilla codebase, such as for a Bugzilla::ChangeSet object. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. - To view or change your list settings, click here: Sent from my Verizon Wireless BlackBerry From lpsolit at gmail.com Sun Mar 14 20:07:14 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sun, 14 Mar 2010 21:07:14 +0100 Subject: windows installer - eyeballs needed In-Reply-To: References: <351c2b10c8371217fd2559aecbb82318@localhost> <0bcb3e27fb6a57ef147f814ddacf1215@localhost> <4B957A1E.2000109@gmail.com> <10acf3c5ab6a410d666db1a78b747a03@localhost> Message-ID: <4B9D41F2.4080200@gmail.com> Le 10. 03. 10 05:28, Byron Jones a ?crit : > - removed imagemagick This is a nice 11 Mb size reduction. Thanks for this removal! When "Configuring Bugzilla..." appears in the cmd.exe window, it would be fine to mention "(this can takes several minutes)" so that one doesn't think it froze (as I first thought). > - detects and warns if mysql port is in use > - detects and warns if http port is in use It would probably be good to mention which port number we are talking about. Also, I have some problems with both servers: - About MySQL, Bugzilla is unable to connect to it. The Bugzilla.MySQL service points to my existing MySQL server in C:\Program Files\MySQL instead of the one in C:\Program Files\Bugzilla\mysql. This probably explains why Bugzilla cannot connect to it: the user account is not valid. Moreover, the Bugzilla.MySQL service is unable to start (maybe because the MySQL service is already running). I didn't see this problem in your previous version of the installer. - About Apache, this server is working fine, but uninstalling Bugzilla using the Add/Remove Programs panel makes my existing Apache server to stop working correctly. No idea why. One more thing about both servers: would it make sense to use them if present rather than installing our own servers? Maybe is it harder to configure them? LpSolit From byron at glob.com.au Mon Mar 15 01:07:14 2010 From: byron at glob.com.au (Byron Jones) Date: Mon, 15 Mar 2010 09:07:14 +0800 Subject: windows installer - eyeballs needed In-Reply-To: <4B9D41F2.4080200@gmail.com> References: <351c2b10c8371217fd2559aecbb82318@localhost> <0bcb3e27fb6a57ef147f814ddacf1215@localhost> <4B957A1E.2000109@gmail.com> <10acf3c5ab6a410d666db1a78b747a03@localhost> <4B9D41F2.4080200@gmail.com> Message-ID: thanks again lpsolit :) > When "Configuring Bugzilla..." appears in the cmd.exe window, it would > be fine to mention "(this can takes several minutes)" so that one > doesn't think it froze (as I first thought). ok, done :) >> - detects and warns if mysql port is in use >> - detects and warns if http port is in use > > It would probably be good to mention which port number we are talking > about. done. > - About MySQL, Bugzilla is unable to connect to it. The Bugzilla.MySQL > service points to my existing MySQL server in C:\Program Files\MySQL > instead of the one in C:\Program Files\Bugzilla\mysql. This probably > explains why Bugzilla cannot connect to it: the user account is not > valid. Moreover, the Bugzilla.MySQL service is unable to start (maybe > because the MySQL service is already running). I didn't see this problem > in your previous version of the installer. > > - About Apache, this server is working fine, but uninstalling Bugzilla > using the Add/Remove Programs panel makes my existing Apache server to > stop working correctly. No idea why. i may have to catch you on irc for these issues; weird. > One more thing about both servers: would it make sense to use them if > present rather than installing our own servers? Maybe is it harder to > configure them? yeah, that would be hard to configure correctly, and is really outside what i'd like to do for the initial release. an alternative could be to provide a zip of strawberryperl i'm using. -- byron.jones :: http://glob.com.au From mkanat at bugzilla.org Mon Mar 15 13:32:26 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 15 Mar 2010 06:32:26 -0700 Subject: windows installer - eyeballs needed In-Reply-To: References: <351c2b10c8371217fd2559aecbb82318@localhost> <0bcb3e27fb6a57ef147f814ddacf1215@localhost> <4B957A1E.2000109@gmail.com> <10acf3c5ab6a410d666db1a78b747a03@localhost> <4B9D41F2.4080200@gmail.com> Message-ID: <4B9E36EA.6020503@bugzilla.org> On 03/14/2010 06:07 PM, Byron Jones wrote: > an alternative could be to provide a zip of strawberryperl i'm using. I think that instead of that, we can also offer people manual instructions that use Strawberry Perl Professional, which already has almost everything Bugzilla needs installed. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Wed Mar 17 10:10:41 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 17 Mar 2010 03:10:41 -0700 Subject: Some Kudos for 3.4 Message-ID: <4BA0AAA1.1010608@bugzilla.org> Hey hey. For any of you who don't subscribe the the support list, attached are some nice messages some users sent about Bugzilla 3.4. -Max -------------- next part -------------- An embedded message was scrubbed... From: "Erik Hemdal" Subject: RE: [ANN] Release of Bugzilla 3.0.10, 3.2.6, 3.4.5, and 3.5.3 Date: Thu, 4 Feb 2010 12:29:12 -0500 Size: 3451 URL: -------------- next part -------------- An embedded message was scrubbed... From: "OBENDORF, BRUCE R (ATTSI)" Subject: RE: [ANN] Release of Bugzilla 3.0.10, 3.2.6, 3.4.5, and 3.5.3 Date: Thu, 4 Feb 2010 10:19:41 -0800 Size: 5578 URL: From mkanat at bugzilla.org Sat Mar 20 16:56:23 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 20 Mar 2010 09:56:23 -0700 Subject: 3.8 May Be 4.0 Message-ID: <4BA4FE37.4030400@bugzilla.org> I think that if we have the following things, then we can call 3.8 4.0 instead: * A new Search Page UI * Bug.update in the WebService And branch support (bz-branch) might be nice, too. Agreed? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mockodin at gmail.com Sat Mar 20 19:24:33 2010 From: mockodin at gmail.com (mockodin at gmail.com) Date: Sat, 20 Mar 2010 19:24:33 +0000 Subject: 3.8 May Be 4.0 Message-ID: <1349457875-1269112906-cardhu_decombobulator_blackberry.rim.net-1871657500-@bda822.bisx.prod.on.blackberry> Getting MSSQL support in too ;-) ------Original Message------ From: Max Kanat-Alexander Sender: developers-owner at bugzilla.org To: developers at bugzilla.org ReplyTo: developers at bugzilla.org Subject: 3.8 May Be 4.0 Sent: Mar 20, 2010 9:56 AM I think that if we have the following things, then we can call 3.8 4.0 instead: * A new Search Page UI * Bug.update in the WebService And branch support (bz-branch) might be nice, too. Agreed? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. - To view or change your list settings, click here: Sent from my Verizon Wireless BlackBerry From mattr at kde.org Sat Mar 20 19:26:03 2010 From: mattr at kde.org (Matt Rogers) Date: Sat, 20 Mar 2010 14:26:03 -0500 Subject: 3.8 May Be 4.0 In-Reply-To: <4BA4FE37.4030400@bugzilla.org> References: <4BA4FE37.4030400@bugzilla.org> Message-ID: <201003201426.03938.mattr@kde.org> On Saturday 20 March 2010 11:56:23 am you wrote: > I think that if we have the following things, then we can call 3.8 4.0 > instead: > > * A new Search Page UI > * Bug.update in the WebService > > And branch support (bz-branch) might be nice, too. > > Agreed? > > -Max Did we decide to leave bug moving out of 4.0 or am I wrong in thinking that was one of the goals of 4.0? -- Matt From mkanat at bugzilla.org Sat Mar 20 22:07:45 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 20 Mar 2010 15:07:45 -0700 Subject: 3.8 May Be 4.0 In-Reply-To: <201003201426.03938.mattr@kde.org> References: <4BA4FE37.4030400@bugzilla.org> <201003201426.03938.mattr@kde.org> Message-ID: <4BA54731.8030304@bugzilla.org> On 03/20/2010 12:26 PM, Matt Rogers wrote: > Did we decide to leave bug moving out of 4.0 or am I wrong in thinking that > was one of the goals of 4.0? Well, originally one of the goals of 4.0 was "inter-Bugzilla", which See Also is the start of. That could still make it. It's not that we're discarding any other goals for 4.0, I'm just saying that *if we have those two things* by the time we freeze for 3.8, then I'd like to call it 4.0. It's been long enough since 3.0, and the changes will be significant enough for us to call it 4.0, I think. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From szabgab at gmail.com Sun Mar 21 09:51:45 2010 From: szabgab at gmail.com (Gabor Szabo) Date: Sun, 21 Mar 2010 11:51:45 +0200 Subject: Releasing Bugzilla to CPAN Message-ID: Hi, we had this discussion a few weeks ago. Unfortunately I did not have time to investigate it further but now at least I blogged about it http://blogs.perl.org/users/gabor_szabo/2010/03/releasing-bugzilla-to-cpan.html that entry will soon show up on http://blogs.perl.org/ and on http://ironman.enlightenedperl.org/ It would be nice to see your comments on the blog itself. regards Gabor From lpsolit at gmail.com Sun Mar 21 13:28:30 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sun, 21 Mar 2010 14:28:30 +0100 Subject: 3.8 May Be 4.0 In-Reply-To: <4BA54731.8030304@bugzilla.org> References: <4BA4FE37.4030400@bugzilla.org> <201003201426.03938.mattr@kde.org> <4BA54731.8030304@bugzilla.org> Message-ID: <4BA61EFE.6040904@gmail.com> Le 20. 03. 10 23:07, Max Kanat-Alexander a ?crit : > Well, originally one of the goals of 4.0 was "inter-Bugzilla", which > See Also is the start of. That could still make it. IMO: - Bug.update, not only for webservice, but also for process_bug.cgi and email_in.pl. - Branch support. - Inter-Bugzilla (at least status + resolution and bug summary) LpSolit From mkanat at bugzilla.org Sun Mar 21 17:18:26 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 21 Mar 2010 10:18:26 -0700 Subject: 3.8 May Be 4.0 In-Reply-To: <4BA61EFE.6040904@gmail.com> References: <4BA4FE37.4030400@bugzilla.org> <201003201426.03938.mattr@kde.org> <4BA54731.8030304@bugzilla.org> <4BA61EFE.6040904@gmail.com> Message-ID: <4BA654E2.5040408@bugzilla.org> On 03/21/2010 06:28 AM, Fr?d?ric Buclin wrote: > - Bug.update, not only for webservice, but also for process_bug.cgi and > email_in.pl. I meant that Bug.update would exist in the WebService, which means that $bug->set_all would be implemented in at least process_bug.cgi. I don't think purely-architectural features should block a major release, though (such as converting email_in to use $bug->set_all). > - Branch support. > - Inter-Bugzilla (at least status + resolution and bug summary) I don't think those are going to happen within two months after 3.6 unless somebody other than me steps up to do them both. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Sun Mar 21 17:24:31 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sun, 21 Mar 2010 18:24:31 +0100 Subject: 3.8 May Be 4.0 In-Reply-To: <4BA654E2.5040408@bugzilla.org> References: <4BA4FE37.4030400@bugzilla.org> <201003201426.03938.mattr@kde.org> <4BA54731.8030304@bugzilla.org> <4BA61EFE.6040904@gmail.com> <4BA654E2.5040408@bugzilla.org> Message-ID: <4BA6564F.40102@gmail.com> Le 21. 03. 10 18:18, Max Kanat-Alexander a ?crit : > I don't think those are going to happen within two months after 3.6 > unless somebody other than me steps up to do them both. In that case, let call our next release 3.8. LpSolit From mkanat at bugzilla.org Sun Mar 21 17:29:13 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 21 Mar 2010 10:29:13 -0700 Subject: 3.8 May Be 4.0 In-Reply-To: <4BA6564F.40102@gmail.com> References: <4BA4FE37.4030400@bugzilla.org> <201003201426.03938.mattr@kde.org> <4BA54731.8030304@bugzilla.org> <4BA61EFE.6040904@gmail.com> <4BA654E2.5040408@bugzilla.org> <4BA6564F.40102@gmail.com> Message-ID: <4BA65769.3030008@bugzilla.org> On 03/21/2010 10:24 AM, Fr?d?ric Buclin wrote: > In that case, let call our next release 3.8. Well, why? Don't you think that with Bug.update and a new Search UI we'd be far enough from 3.0? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From eaolson73 at att.net Sun Mar 21 17:40:12 2010 From: eaolson73 at att.net (Eric Olson) Date: Sun, 21 Mar 2010 12:40:12 -0500 Subject: Close 324235? Message-ID: <4BA659FC.6050907@att.net> I realize this is fairly trivial, but should 324235 be closed? It involves a parameter that doesn't exist in the 3.x branch anymore. Or is it appropriate to keep bugs open for branches no longer supported? https://bugzilla.mozilla.org/show_bug.cgi?id=324235 From mkanat at bugzilla.org Sun Mar 21 17:53:00 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 21 Mar 2010 10:53:00 -0700 Subject: Close 324235? In-Reply-To: <4BA659FC.6050907@att.net> References: <4BA659FC.6050907@att.net> Message-ID: <4BA65CFC.8040203@bugzilla.org> On 03/21/2010 10:40 AM, Eric Olson wrote: > I realize this is fairly trivial, but should 324235 be closed? It > involves a parameter that doesn't exist in the 3.x branch anymore. Or is > it appropriate to keep bugs open for branches no longer supported? > > https://bugzilla.mozilla.org/show_bug.cgi?id=324235 For a bug that's trivial like that, it should be closed if we did in fact remove that parameter in a later release. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From rsbecker at nexbridge.com Mon Mar 22 14:57:36 2010 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Mon, 22 Mar 2010 10:57:36 -0400 Subject: Porting Bugzilla to HP NonStop Message-ID: <00d601cac9d0$033a1880$09ae4980$@com> Hi People, I'm looking for advise on the most appropriate way to port Bugzilla to HP NonStop. We're currently working on a PHP 5.3.2 port. The underlying database appears to support all of the constructs needed (ANSI 2003 compliant), has a shell-level interface, C++ embedded support, ODBC, and JDBC. I've checked the porting guide, but need more direction. Any advice would be appreciated. Thanks, Randall S. Becker Managing Director, Nexbridge Inc. rsbecker at nexbridge.com Phone: +1 416 984 9826 http://indestructiblecomputing.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Mon Mar 22 20:47:21 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 22 Mar 2010 13:47:21 -0700 Subject: Porting Bugzilla to HP NonStop In-Reply-To: <00d601cac9d0$033a1880$09ae4980$@com> References: <00d601cac9d0$033a1880$09ae4980$@com> Message-ID: <4BA7D759.8010105@bugzilla.org> On 03/22/2010 07:57 AM, Randall S. Becker wrote: > We?re currently working on a PHP 5.3.2 port. Why? That's a 10-person-year job. It would probably take less time to get Perl working on your platform (which I would have to imagine it already does). > I?ve checked the porting guide, but need more direction. What porting guide? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From rsbecker at nexbridge.com Tue Mar 23 07:29:52 2010 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Tue, 23 Mar 2010 03:29:52 -0400 Subject: Porting Bugzilla to HP NonStop In-Reply-To: <4BA7D759.8010105@bugzilla.org> References: <00d601cac9d0$033a1880$09ae4980$@com> <4BA7D759.8010105@bugzilla.org> Message-ID: <003101caca5a$a185fa60$e491ef20$@com> >> We?re currently working on a PHP 5.3.2 port. > Why? That's a 10-person-year job. It would probably take less time to get Perl working on your platform (which I would have to imagine it already does). True, but we have a head-start from an older port. I'd be happy to pass on PHP ;-). We do have Perl. >> I?ve checked the porting guide, but need more direction. > What porting guide? Bugzilla 2.4.1 Doc had a discussion about porting. Old stuff. Not useful other than "Talk to the developers" From mkanat at bugzilla.org Tue Mar 23 07:56:28 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 23 Mar 2010 00:56:28 -0700 Subject: Porting Bugzilla to HP NonStop In-Reply-To: <003101caca5a$a185fa60$e491ef20$@com> References: <00d601cac9d0$033a1880$09ae4980$@com> <4BA7D759.8010105@bugzilla.org> <003101caca5a$a185fa60$e491ef20$@com> Message-ID: <4BA8742C.30003@bugzilla.org> On 03/23/2010 12:29 AM, Randall S. Becker wrote: > True, but we have a head-start from an older port. I'd be happy to pass on PHP ;-). We do have Perl. Okay. Bugzilla is written in Perl, so why not just use Bugzilla as-is? > Bugzilla 2.4.1 Doc had a discussion about porting. Old stuff. Not useful other than "Talk to the developers" There was no Bugzilla 2.4.1. (And if there was, it would have been from 1999.) Did you mean 2.14.1? I don't see anything like that in the 2.16 docs, which are the oldest we have on our website, currently. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From byron at glob.com.au Tue Mar 23 14:35:08 2010 From: byron at glob.com.au (Byron Jones) Date: Tue, 23 Mar 2010 22:35:08 +0800 Subject: bugzilla windows installers Message-ID: <4BA8D19C.2000407@glob.com.au> morning all, i'm happy to announce the first release of a windows setup for bugzilla :) http://landfill.bugzilla.org/win32installer/Bugzilla-Setup-3.4.6.exe http://landfill.bugzilla.org/win32installer/Bugzilla-Setup-3.6rc1.exe the setup weighs in at about 66M, and will install and configure the following: bugzilla mysql apache perl scheduled tasks for whining, etc assorted utilities (cvs, database backup script, etc) thanks to all who provided feedback. -byron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsbecker at nexbridge.com Tue Mar 23 14:57:40 2010 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Tue, 23 Mar 2010 10:57:40 -0400 Subject: Porting Bugzilla to HP NonStop In-Reply-To: <4BA8742C.30003@bugzilla.org> References: <00d601cac9d0$033a1880$09ae4980$@com> <4BA7D759.8010105@bugzilla.org> <003101caca5a$a185fa60$e491ef20$@com> <4BA8742C.30003@bugzilla.org> Message-ID: <005301caca99$2fe36840$8faa38c0$@com> Here's the situation: Checking for DBD-Pg (v1.45) not found Checking for DBD-mysql (v4.00) not found Checking for DBD-Oracle (v1.19) not found As indicated, this box has none of the above three, nor are we going to put those on the box. I'm looking to port to a new database and am looking for advise on doing so. The RDBMS is NonStop SQL/MX, and I'm expert level at that. -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Max Kanat-Alexander Sent: March-23-10 3:56 AM To: developers at bugzilla.org Subject: Re: Porting Bugzilla to HP NonStop On 03/23/2010 12:29 AM, Randall S. Becker wrote: > True, but we have a head-start from an older port. I'd be happy to pass on PHP ;-). We do have Perl. Okay. Bugzilla is written in Perl, so why not just use Bugzilla as-is? > Bugzilla 2.4.1 Doc had a discussion about porting. Old stuff. Not useful other than "Talk to the developers" There was no Bugzilla 2.4.1. (And if there was, it would have been from 1999.) Did you mean 2.14.1? I don't see anything like that in the 2.16 docs, which are the oldest we have on our website, currently. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. - To view or change your list settings, click here: From gerv at mozilla.org Tue Mar 23 15:57:32 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 23 Mar 2010 15:57:32 +0000 Subject: Mozilla UI team mockup of simpler Bugzilla interface Message-ID: I thought people might be interested in commenting on this :-) http://newdefault.tumblr.com/post/441128727/theres-also-a-mockup-showing-what-happens-if-you I think beltzner is behind it, but that's a shared blog, so I'm not certain. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Tue Mar 23 16:06:24 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 23 Mar 2010 16:06:24 +0000 Subject: Porting Bugzilla to HP NonStop In-Reply-To: References: <00d601cac9d0$033a1880$09ae4980$@com> <4BA7D759.8010105@bugzilla.org> <003101caca5a$a185fa60$e491ef20$@com> <4BA8742C.30003@bugzilla.org> Message-ID: <4BA8E700.6090408@mozilla.org> On 23/03/10 14:57, Randall S. Becker wrote: > Here's the situation: > > Checking for DBD-Pg (v1.45) not found > Checking for DBD-mysql (v4.00) not found > Checking for DBD-Oracle (v1.19) not found > > As indicated, this box has none of the above three, nor are we going to > put those on the box. I'm looking to port to a new database and am > looking for advise on doing so. The RDBMS is NonStop SQL/MX, and I'm > expert level at that. Someone here is deeply confused :-) Perl and PHP are scripting languages. Bugzilla is a large web application written in Perl. In order to get the output above, your box must have run the checksetup.pl script which is written in Perl. Therefore, your box is capable of running Perl, and running Bugzilla's current code. Converting it "to PHP" would mean rewriting all the code - basically writing a new application. As Max says, it's a 10 person year job. Cost - $1M plus. (Cost of buying dedicated hardware, putting Linux on it and running Bugzilla on that: $1K + 1 man day). Separately, Bugzilla uses an SQL database. It currently supports MySQL, PostgreSQL and Oracle (experimentally). Porting it to use a new database is a comparatively easy task. If you wanted to add "NonStop SQL/MX" to that list, then that I'm sure is doable. You would need to write a Perl DBD driver for your database, as I don't think one is available, but documentation on how to do that _is_ available: http://search.cpan.org/~timb/DBI-1.609/lib/DBI/DBD.pm Thirdly, the list you give above does not tell you whether particular databases are installed, but whether the Perl modules to _drive_ particular databases (DBD modules) are installed or not. You don't have any of such modules installed, but they are very easy to install. Just use CPAN. You do not need to be an expert DBMS to run Bugzilla. Most people just set up MySQL following the instructions, and let it get on with it. I strongly suggest that, assuming MySQL is available for your platform, the easiest way for you to run Bugzilla is to do the same. And if it's not, the easiest thing to do is buy a 1U rackmount server, install Linux and use that. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From rsbecker at nexbridge.com Tue Mar 23 16:14:59 2010 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Tue, 23 Mar 2010 12:14:59 -0400 Subject: Porting Bugzilla to HP NonStop In-Reply-To: <4BA8E700.6090408@mozilla.org> References: <00d601cac9d0$033a1880$09ae4980$@com> <4BA7D759.8010105@bugzilla.org> <003101caca5a$a185fa60$e491ef20$@com> <4BA8742C.30003@bugzilla.org> <4BA8E700.6090408@mozilla.org> Message-ID: <005a01cacaa3$fca210c0$f5e63240$@com> Thanks Gervase. The point is actually to do the port to SQL/MX rather than using MySQL. At present, we're upgrading Perl to include the required modules (not so easy due to quirks, unfortunately, and a lack of mail of any kind on the box). I wasn't actually confused about the database; rather, just responding to Max. The SQL/MX engine is native on the box. The documentation at CPAN appears helpful and I'm going down the DBD path, although I'm spawning a separate path for using the unixODBC driver directly. Thanks, Randall -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gervase Markham Sent: March-23-10 12:06 PM To: dev-apps-bugzilla at lists.mozilla.org Subject: Re: Porting Bugzilla to HP NonStop On 23/03/10 14:57, Randall S. Becker wrote: > Here's the situation: > > Checking for DBD-Pg (v1.45) not found > Checking for DBD-mysql (v4.00) not found > Checking for DBD-Oracle (v1.19) not found > > As indicated, this box has none of the above three, nor are we going to > put those on the box. I'm looking to port to a new database and am > looking for advise on doing so. The RDBMS is NonStop SQL/MX, and I'm > expert level at that. Someone here is deeply confused :-) Perl and PHP are scripting languages. Bugzilla is a large web application written in Perl. In order to get the output above, your box must have run the checksetup.pl script which is written in Perl. Therefore, your box is capable of running Perl, and running Bugzilla's current code. Converting it "to PHP" would mean rewriting all the code - basically writing a new application. As Max says, it's a 10 person year job. Cost - $1M plus. (Cost of buying dedicated hardware, putting Linux on it and running Bugzilla on that: $1K + 1 man day). Separately, Bugzilla uses an SQL database. It currently supports MySQL, PostgreSQL and Oracle (experimentally). Porting it to use a new database is a comparatively easy task. If you wanted to add "NonStop SQL/MX" to that list, then that I'm sure is doable. You would need to write a Perl DBD driver for your database, as I don't think one is available, but documentation on how to do that _is_ available: http://search.cpan.org/~timb/DBI-1.609/lib/DBI/DBD.pm Thirdly, the list you give above does not tell you whether particular databases are installed, but whether the Perl modules to _drive_ particular databases (DBD modules) are installed or not. You don't have any of such modules installed, but they are very easy to install. Just use CPAN. You do not need to be an expert DBMS to run Bugzilla. Most people just set up MySQL following the instructions, and let it get on with it. I strongly suggest that, assuming MySQL is available for your platform, the easiest way for you to run Bugzilla is to do the same. And if it's not, the easiest thing to do is buy a 1U rackmount server, install Linux and use that. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla - To view or change your list settings, click here: From bugreport at peshkin.net Tue Mar 23 16:27:22 2010 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 23 Mar 2010 09:27:22 -0700 (PDT) Subject: Porting Bugzilla to HP NonStop In-Reply-To: <005a01cacaa3$fca210c0$f5e63240$@com> References: <00d601cac9d0$033a1880$09ae4980$@com> <4BA7D759.8010105@bugzilla.org> <003101caca5a$a185fa60$e491ef20$@com> <4BA8742C.30003@bugzilla.org> <4BA8E700.6090408@mozilla.org> <005a01cacaa3$fca210c0$f5e63240$@com> Message-ID: <15581.70.167.158.162.1269361642.squirrel@peshkin.net> Randall, If you have ODBC available, the path of least resistance is likely to start with DBD::ODBC. Naturally, once you've done that you will need to update and test all of the Bugzilla code that needs to be at all database-aware. That has already been done to accommodate the quirks of Mysql, Pg, and Oracle so it shouldn't be too terrible a job unless NonStop is missing any major capabilities. -Joel Peshkin > > The documentation at CPAN appears helpful and I'm going down the DBD path, > although I'm spawning a separate path for using the unixODBC driver > directly. > From guy.pyrzak at gmail.com Tue Mar 23 16:31:47 2010 From: guy.pyrzak at gmail.com (Guy Pyrzak) Date: Tue, 23 Mar 2010 09:31:47 -0700 Subject: Mozilla UI team mockup of simpler Bugzilla interface In-Reply-To: References: Message-ID: Lol, This is actually pretty funny because this is basically the direction we've been going in for a bunch of things (see the new search UI). The approach is basically "hide fields" especially those that are empty. To which beltzner told me "we can do this better". Reed said something similar, so it's funny to see the same approach used again. I'm somewhat tempted to say we should have a generalized way of marking some fields as "additional details" and other fields as main fields that way we can implement the "show/hide" concept across the board (on the search page, on the create page and on the edit page). I hope some of the folks at moco have been paying attention to the work we've been doing with the search page and the attachments page and realize that we're all on the same page. I'm happy to write an extension that implements the UI in the screenshots this weekend if Justdave is interested in it for BMO. I think for general use things like whiteboard might not be as used as much unless we're going to say "the whiteboard is how people tag stuff", which is basically how BMO uses it. Any thoughts? -Guy On Tue, Mar 23, 2010 at 8:57 AM, Gervase Markham wrote: > I thought people might be interested in commenting on this :-) > > > http://newdefault.tumblr.com/post/441128727/theres-also-a-mockup-showing-what-happens-if-you > > I think beltzner is behind it, but that's a shared blog, so I'm not > certain. > > Gerv > _______________________________________________ > dev-apps-bugzilla mailing list > dev-apps-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mockodin at gmail.com Tue Mar 23 16:35:36 2010 From: mockodin at gmail.com (Michael Thomas) Date: Tue, 23 Mar 2010 09:35:36 -0700 Subject: Porting Bugzilla to HP NonStop In-Reply-To: <005301caca99$2fe36840$8faa38c0$@com> References: <00d601cac9d0$033a1880$09ae4980$@com> <4BA7D759.8010105@bugzilla.org> <003101caca5a$a185fa60$e491ef20$@com> <4BA8742C.30003@bugzilla.org> <005301caca99$2fe36840$8faa38c0$@com> Message-ID: <6b9407351003230935g2ea4a220oa9b1e1444cca94ac@mail.gmail.com> Those being the only support db platforms. That said to test another db you would need to modify the following: /bugzilla/Bugzilla/Constants.pm Add a section calling the DBD- And you will need to create two files: Bugzilla\DB\.pm Bugzilla\DB\Schema\.pm Take a look at the patch file I have up on http://www.zplace.com that is a port for MSSQL. You may want to start be cloning the Bugzilla\DB\mysql.pm and Bugzilla\DB\Schema\mysql.pm files and edited where needed. Keep in mind that your more or less on your own for support, except where folks are feeling generous, since it is not a supported port. If you can get it working I imagine if you can submit what you did back to the community it might get added, that's my goal for mssql. For my port I found some hard coded instances of functions where assumptions had been made, such as substring, under mssql all three parameters are required not just the first two. Seeing Joel's update, the MSSQL patch is using DBD::ODBC already so you can probably clone part of my code. On Tue, Mar 23, 2010 at 7:57 AM, Randall S. Becker wrote: > Here's the situation: > > Checking for ? ? ? ? ? ? ?DBD-Pg (v1.45) ? ?not found > Checking for ? ? ? ? ? DBD-mysql (v4.00) ? ?not found > Checking for ? ? ? ? ?DBD-Oracle (v1.19) ? ?not found > > As indicated, this box has none of the above three, nor are we going to put those on the box. I'm looking to port to a new database and am looking for advise on doing so. The RDBMS is NonStop SQL/MX, and I'm expert level at that. > > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Max Kanat-Alexander > Sent: March-23-10 3:56 AM > To: developers at bugzilla.org > Subject: Re: Porting Bugzilla to HP NonStop > > On 03/23/2010 12:29 AM, Randall S. Becker wrote: >> True, but we have a head-start from an older port. I'd be happy to pass on PHP ;-). We do have Perl. > > ? ? ? ?Okay. Bugzilla is written in Perl, so why not just use Bugzilla as-is? > >> Bugzilla 2.4.1 Doc had a discussion about porting. Old stuff. Not useful other than "Talk to the developers" > > ? ? ? ?There was no Bugzilla 2.4.1. (And if there was, it would have been from > 1999.) Did you mean 2.14.1? I don't see anything like that in the 2.16 > docs, which are the oldest we have on our website, currently. > > ? ? ? ?-Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla and Perl Services. Everything Else, too. > - > To view or change your list settings, click here: > > > - > To view or change your list settings, click here: > > From mkanat at bugzilla.org Tue Mar 23 19:17:43 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 23 Mar 2010 12:17:43 -0700 Subject: Mozilla UI team mockup of simpler Bugzilla interface In-Reply-To: References: Message-ID: <4BA913D7.3040302@bugzilla.org> On 03/23/2010 08:57 AM, Gervase Markham wrote: > I thought people might be interested in commenting on this :-) > > http://newdefault.tumblr.com/post/441128727/theres-also-a-mockup-showing-what-happens-if-you I'm not sure that anything on the Bikeshed blog is appropriate for general public discussion unless specifically brought to discussion by the author of the post. That could be a very old mockup that beltzner posted, or just something he posted for internal UX discussion. Anyhow, it looks strangely like the Bugzilla 3.0 UI (which was so strongly objected to that mconnor re-designed the UI before it ever went live on bmo) with some hidden fields. Beyond that, without some context on the mockup, it's hard to have a discussion. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Wed Mar 24 12:19:43 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 24 Mar 2010 12:19:43 +0000 Subject: Mozilla UI team mockup of simpler Bugzilla interface In-Reply-To: References: Message-ID: On 23/03/10 16:31, Guy Pyrzak wrote: > Lol, This is actually pretty funny because this is basically the direction > we've been going in for a bunch of things (see the new search UI). It's the way that TidyBug has gone. Are you familiar with that? http://www.squarefree.com/2009/02/26/tidybug/ http://bugzillatips.wordpress.com/2010/02/12/tidybug-simplified-bug-display/ > The approach is basically "hide fields" especially those that are empty. And (at least with TidyBug) to remove the styling on editable fields so they look non-editable until you mouseover them. This has a really significant simplifying effect which I like. > To which beltzner told me "we can do this better". Reed said something > similar, so it's funny to see the same approach used again. :-) > I hope some of the folks at moco have been paying attention to the work > we've been doing with the search page and the attachments page and realize > that we're all on the same page. I hope so. I've been trying to connect the dots on this :-) Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Mar 24 12:22:03 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 24 Mar 2010 12:22:03 +0000 Subject: Mozilla UI team mockup of simpler Bugzilla interface In-Reply-To: References: Message-ID: On 23/03/10 19:17, Max Kanat-Alexander wrote: > I'm not sure that anything on the Bikeshed blog is appropriate for > general public discussion unless specifically brought to discussion by > the author of the post. I think the entire _point_ of the bikeshed is that it's to promote further discussion of things, with the important note that nothing is being construed as anyone's official permission on anything. In fact, beltzner told me he was going to post that to the bikeshed. > Anyhow, it looks strangely like the Bugzilla 3.0 UI (which was so > strongly objected to that mconnor re-designed the UI before it ever went > live on bmo) with some hidden fields. Interesting, and useful historical context. Is there any record of what mconnor disliked about it? Maybe we should reach out to him and ask; I'm happy to do that. > Beyond that, without some context > on the mockup, it's hard to have a discussion. It's hard only if you think the opinions of the person who made the mockup are required in order to have one :-) I think we're having a fin one without them. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mconnor at gmail.com Wed Mar 24 13:46:13 2010 From: mconnor at gmail.com (Mike Connor) Date: Wed, 24 Mar 2010 06:46:13 -0700 (PDT) Subject: Mozilla UI team mockup of simpler Bugzilla interface References: Message-ID: Gerv pinged me via email: > Can you take a couple of minutes to say what you think of the mockup? In mozilla.dev.apps.bugzilla would be best, but if that's too much hassle then I'll pass your comments on. * I support 100% the principle of focusing on the most important details, with progressive disclosure burying the bigger details most people don't care about, but I think there's a couple things that aren't in the initial UI that probably need to be. * Even on scan #5 of that mockup, I keep forgetting where status is, because I start reading with the summary. * Target Milestone is something I'd like to see reflected into primary UI, maybe with the status. * Keywords/Whiteboard feel like they should have the text as text (like depends/blocks), with the (edit) option popping out to a textarea (cleaner to read, and doesn't fail on overflow like the does) * I think given the relative infrequency of editing blocks/depends, we can collapse that field by default and have an edit link. (With this and the bullet above, we've eliminated all of the textfields from the initial view, which would be awesome for readability) * Can we show flags with values in primary UI? Ideally just ?/+, and not minused bugs. (Knowing something is nominated or blocking feels like a key piece of data for users.) * I think I tried Product::Component in b.m.o., but some of the really long component names made that less than awesome. If we can kill the headers, I think it'd work. Maybe just: | Area: [Server Operations \/] [Bugzilla Other Issues \/] or something? > Can you remember what it was about the 3.0 UI you disliked? >From looking again: * Related fields were not grouped sanely (i.e. product and component were in a separate place from the version and platform affected), the scan pattern was like a Tetris block. * Scanning was harder, because it was a mix of 3 columns and 2 columns. * Assignee was over with Reporter/CC list, instead of with TM/ severity, out of a misguided desire to follow a taxonomy (people vs. details) * Bug#/Summary wasn't prominent, and useful metadata (status/keywords/ whiteboard) was kept separate from that info In short, the information grouping was not optimal, and it was hard to process the data rapidly. -- MIke _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From benjamin at smedbergs.us Wed Mar 24 13:58:59 2010 From: benjamin at smedbergs.us (Benjamin Smedberg) Date: Wed, 24 Mar 2010 09:58:59 -0400 Subject: Mozilla UI team mockup of simpler Bugzilla interface In-Reply-To: References: Message-ID: On 3/24/10 9:46 AM, Mike Connor wrote: > * Target Milestone is something I'd like to see reflected into primary > UI, maybe with the status. Hrm, I'm rather opposed to this. The TM on b.m.o rarely reflects reality, and I think it would be better to hide it or remove it entirely than give it prominence. --BDS _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mconnor at gmail.com Wed Mar 24 15:31:34 2010 From: mconnor at gmail.com (Mike Connor) Date: Wed, 24 Mar 2010 08:31:34 -0700 (PDT) Subject: Mozilla UI team mockup of simpler Bugzilla interface References: Message-ID: <8b7c1d5f-7343-4bbc-b127-d30ddb51cab2@l25g2000yqd.googlegroups.com> On Mar 24, 9:58?am, Benjamin Smedberg wrote: > On 3/24/10 9:46 AM, Mike Connor wrote: > > > * Target Milestone is something I'd like to see reflected into primary > > UI, maybe with the status. > > Hrm, I'm rather opposed to this. The TM on b.m.o rarely reflects reality, > and I think it would be better to hide it or remove it entirely than give it > prominence. Weave uses it quite deliberately and we try to keep it reflecting reality as much as possible, FWIW. We could make it a per-product UI choice, and products that have active milestone other than the default would display it, and other products wouldn't have it at all. I am pretty sure that other projects on b.m.o. use this field as part of their workflow. -- Mike _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Fri Mar 26 11:20:54 2010 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 26 Mar 2010 11:20:54 +0000 Subject: Versions and Target Milestones Message-ID: Thinking about it, a few things bug me about the way we currently do versions and target milestones. Have these ideas been thought of before? Is there a position on them? - It seems that these fields actually are values from the same lists - versions are versions in the past, and target milestones are versions in the future. There would be, I think, great advantage in having a unified set of "versions", some of which were marked as "released". Those marked as "released" would be in the "Version" field, and those not marked as "Released" would be in the "Target Milestone" field. One could then also have a parameter that made it so that all bugs targetted at a milestone had to be retargetted before that milestone could be set as Released - good for workflow. This would end the weird thing of having bugs still targetted at "Target Milestones" for releases which had already happened. - Further to the above, the naming is inconsistent. Target Milestone is a name very specific to early Mozilla development. And using "Milestone" and "Version" for the same thing is confusing. Would it make more sense to start calling it "Target" or even "Planned Version"? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From michael.j.tosh at lmco.com Fri Mar 26 14:25:00 2010 From: michael.j.tosh at lmco.com (Tosh, Michael J) Date: Fri, 26 Mar 2010 10:25:00 -0400 Subject: Versions and Target Milestones In-Reply-To: References: Message-ID: <8A06826F0DE9AD4087CEBD52E769C0DC3E69C678@HVXMSPB.us.lmco.com> Gervase Markham wrote: > Thinking about it, a few things bug me about the way we currently do > versions and target milestones. Have these ideas been thought of before? > Is there a position on them? I've combined the fields for my organization on 3.0.8. We have a checkbox in the milestones (because a milestone could also be a date or abstract definition) to say if it should also be included in the list of versions. With this, I also added an is_obsolete flag to that table. I call it "Releases", which to me encompasses both intents. -miketosh _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From ghendricks at novell.com Fri Mar 26 15:21:27 2010 From: ghendricks at novell.com (Gregary Hendricks) Date: Fri, 26 Mar 2010 09:21:27 -0600 Subject: Versions and Target Milestones In-Reply-To: References: Message-ID: <4BAC7C97020000D200075F32@soto.provo.novell.com> >>> On 3/26/2010 at 5:20 AM, in message , Gervase Markham wrote: > Thinking about it, a few things bug me about the way we currently do > versions and target milestones. Have these ideas been thought of before? > Is there a position on them? > > - It seems that these fields actually are values from the same lists - > versions are versions in the past, and target milestones are versions in > the future. There would be, I think, great advantage in having a unified > set of "versions", some of which were marked as "released". Those marked > as "released" would be in the "Version" field, and those not marked as > "Released" would be in the "Target Milestone" field. Novell has taken this appraoch in the integration tool used to manage products. Users enter "releases" and then mark them as already released or planned. Released versions show up in the "Versions" field while planned releases show in TM. > > One could then also have a parameter that made it so that all bugs > targetted at a milestone had to be retargetted before that milestone > could be set as Released - good for workflow. This would end the weird > thing of having bugs still targetted at "Target Milestones" for releases > which had already happened. This would make sense but make it optional. > - Further to the above, the naming is inconsistent. Target Milestone is > a name very specific to early Mozilla development. And using "Milestone" > and "Version" for the same thing is confusing. Would it make more sense > to start calling it "Target" or even "Planned Version"? Again, this is basically the approach we have taken. ++Greg From szabgab at gmail.com Fri Mar 26 17:19:26 2010 From: szabgab at gmail.com (Gabor Szabo) Date: Fri, 26 Mar 2010 20:19:26 +0300 Subject: Releasing Bugzilla to CPAN In-Reply-To: References: Message-ID: I was hoping someone from the Bugzilla team would also comment on my blog. Anyway, the initial patch is here: https://bugzilla.mozilla.org/show_bug.cgi?id=555181 regards Gabor On Sun, Mar 21, 2010 at 11:51 AM, Gabor Szabo wrote: > Hi, > > we had this discussion a few weeks ago. > Unfortunately I did not have time to investigate it further but now at least > I blogged about it > > http://blogs.perl.org/users/gabor_szabo/2010/03/releasing-bugzilla-to-cpan.html > > that entry will soon show up on http://blogs.perl.org/ and on > http://ironman.enlightenedperl.org/ > > It would be nice to see your comments on the blog itself. > > regards > ? Gabor From sushantmishra786 at gmail.com Fri Mar 26 19:25:28 2010 From: sushantmishra786 at gmail.com (sushant) Date: Fri, 26 Mar 2010 12:25:28 -0700 (PDT) Subject: about add ons Message-ID: <3fececfa-2b45-43a9-8c6c-161a79e5bce2@l12g2000pra.googlegroups.com> unable to install any addons like foxtabs in mozilla firefox 3.6.2 of win 7 or in fedora 12 _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From szabgab at gmail.com Sat Mar 27 08:37:33 2010 From: szabgab at gmail.com (Gabor Szabo) Date: Sat, 27 Mar 2010 11:37:33 +0300 Subject: Releasing Bugzilla to CPAN In-Reply-To: References: Message-ID: Max, maybe I was a bit hasty in creating an initial patch that would allow the upload of Bugzilla to CPAN or did I misunderstand your comment from a few weeks ago and you are actually vehemently against uploading Bugzilla to CPAN? Based on the comments on the blog entry and my discussion with others it seems that people would be happy to see Bugzilla on CPAN. By making this move it will push the CPAN toolchain to fill any hole it might have that the current packaging and installation system of Bugzilla fills. So let's discuss this. What does the Bugzilla installation process do that is not available in the current CPAN toolchain? Answering this question might not be easy as I don't know what does the Bugzilla installation process do and you don't know what the CPAN toolchain does. Hence I started to create a Makefile.PL that could be tweaked until it fulfills the needs of Bugzilla and if something is really missing we could ask the toolchain authors to support those features. My recommendation would be to change the version number of Bugzilla to be 3.70_01 and upload it to CPAN ASAP. That would allow people to see it and test it but it will NOT show up in he index so regular people would not be able to install it. (The underscore 01 part means that it is a "developer release") If after a few week or months you don't see progress you can delete it from CPAN and it will be gone. No old unsupported version available from CPAN. For now, I'll fix the issues you mentioned in the bug and we can go on from there. regards Gabor On Fri, Mar 26, 2010 at 8:19 PM, Gabor Szabo wrote: > I was hoping someone from the Bugzilla team would also comment > on my blog. > Anyway, the initial patch is here: > https://bugzilla.mozilla.org/show_bug.cgi?id=555181 > > regards > ? Gabor > > > On Sun, Mar 21, 2010 at 11:51 AM, Gabor Szabo wrote: >> Hi, >> >> we had this discussion a few weeks ago. >> Unfortunately I did not have time to investigate it further but now at least >> I blogged about it >> >> http://blogs.perl.org/users/gabor_szabo/2010/03/releasing-bugzilla-to-cpan.html >> >> that entry will soon show up on http://blogs.perl.org/ and on >> http://ironman.enlightenedperl.org/ >> >> It would be nice to see your comments on the blog itself. >> >> regards >> ? Gabor From szabgab at gmail.com Sat Mar 27 10:51:04 2010 From: szabgab at gmail.com (Gabor Szabo) Date: Sat, 27 Mar 2010 13:51:04 +0300 Subject: updating the Bugzilla website Message-ID: According to http://www.bugzilla.org/docs/release.html#web_site_updates updating the website needs CVS access. Is this still the case or has it also moved to Bazaar? If it has moved already, then please update that page if it is still in CVS, then, are there any plans to move that too to Bazaar? regards Gabor From szabgab at gmail.com Sat Mar 27 11:01:53 2010 From: szabgab at gmail.com (Gabor Szabo) Date: Sat, 27 Mar 2010 14:01:53 +0300 Subject: the release process of Bugzilla Message-ID: As I keep reading about the release process of Bugzilla I noticed that 1) it is still based on CVS http://www.bugzilla.org/docs/release.html#tag_releases 2) There are some scripts that are not in Bazaar? http://www.bugzilla.org/docs/release.html#create_the_tarballs tells me about "Now, there's a script for building Bugzilla tarballs. mkanat at bugzilla.org has the latest version, usually." Is this still kept privately? May I ask that to be added to the repository, maybe in a subdirectory called "tools" ? That would allow me to learn what else need to be done for the packaging of Bugzilla to CPAN. regards Gabor -- Gabor Szabo http://szabgab.com/ From lpsolit at gmail.com Sat Mar 27 13:50:59 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sat, 27 Mar 2010 14:50:59 +0100 Subject: updating the Bugzilla website In-Reply-To: References: Message-ID: <4BAE0D43.8060505@gmail.com> Le 27. 03. 10 11:51, Gabor Szabo a ?crit : > According to http://www.bugzilla.org/docs/release.html#web_site_updates > updating the > website needs CVS access. Is this still the case or has it also moved to Bazaar? It still uses CVS, and there is no plan to move to Bazaar for now. LpSolit From mkanat at bugzilla.org Sat Mar 27 22:26:10 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 27 Mar 2010 15:26:10 -0700 Subject: the release process of Bugzilla In-Reply-To: References: Message-ID: <4BAE8602.7060803@bugzilla.org> On 03/27/2010 04:01 AM, Gabor Szabo wrote: > As I keep reading about the release process of Bugzilla I noticed that > 1) it is still based on CVS > http://www.bugzilla.org/docs/release.html#tag_releases It is, because all of our documentation and download instructions are still based on CVS. Probably the first set of releases to use bzr for the release process will be the 3.7 series (and thus 3.8). However, the older releases will stick with 3.6, because that's what their documentation talks about, and that's what their users are already using. BTW, the Release documentation is slightly out of date, now, because there are two scripts in the bugzilla.org (website) repository that help out with it, bin/do-release.pl (which automates a lot of the website updates), and bin/tag-releases.pl (which helps tag the releases in CVS--I do the bzr tagging manually, because it's so easy). > 2) There are some scripts that are not in Bazaar? > http://www.bugzilla.org/docs/release.html#create_the_tarballs > tells me about > "Now, there's a script for building Bugzilla tarballs. > mkanat at bugzilla.org has the latest version, usually." > > Is this still kept privately? May I ask that to be added to the repository, > maybe in a subdirectory called "tools" ? Sure! That's a great idea. :-) I've added them to the repository, at: bzr://bzr.mozilla.org/bugzilla/misc/build -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Sat Mar 27 22:40:18 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 27 Mar 2010 15:40:18 -0700 Subject: Releasing Bugzilla to CPAN In-Reply-To: References: Message-ID: <4BAE8952.1010607@bugzilla.org> On 03/27/2010 01:37 AM, Gabor Szabo wrote: > did I misunderstand your comment from a few weeks ago > and you are actually vehemently against uploading Bugzilla to CPAN? No, not at all. :-) (FWIW, I'm not "vehement" about any method of installation or distribution--that would imply an emotional involvement instead of a technical consideration, and installation distribution are pretty much entirely about technical considerations, mostly about what's easiest and best for our users.) To clarify what I think about the subject, I responded to your comment on the CPAN-distribution bug: https://bugzilla.mozilla.org/show_bug.cgi?id=555181#c6 > Based on the comments on the blog entry and my discussion with others > it seems that people would be happy to see Bugzilla on CPAN. By making this > move it will push the CPAN toolchain to fill any hole it might have that the > current packaging and installation system of Bugzilla fills. That'd be cool. :-) > So let's discuss this. What does the Bugzilla installation process do that is > not available in the current CPAN toolchain? Answering this question might not > be easy as I don't know what does the Bugzilla installation process do and > you don't know what the CPAN toolchain does. Hmm. I think the primary issue isn't about what checksetup.pl does that CPAN doesn't. We've (or at least, I've) learned over time from the differences in the Debian and Red Hat packaging methods that it's probably better to leave post-install configuration (like setting up the database and so forth) to Bugzilla itself, and packages should just do the actual *installation*--that is, putting files where they belong, and so forth. The problem is that although there's always a standard place for *Perl libraries* that CPAN knows about, and a standard place for binaries in the Filesystem Hierarchy Standard, there is no standard, widely-adopted location for web applications to go. Also, some (actually, a surprising number of) people want to install multiple copies of Bugzilla on the same server, which would involve each copy having its own Bugzilla/ libraries. Yes, people could install the first one from CPAN and the second from the tarball, but then that might get confusing because the *binaries* would be global, and typing "checksetup.pl" would do something different than typing "./checksetup.pl". With the tarball, you just untar it in a directory and that *is* Bugzilla. There's no compilation, no actual installation of the files--that's just it. And for web applications, as far as I know, that's pretty much the standard, unless they're FCGI apps running from a single binary (which Bugzilla isn't). There's also a somewhat-significant issue with Bugzilla itself, which is the bz_locations subroutine in Bugzilla::Constants. The CPAN installer might have to make some manual changes to that, but I think you and I are both familiar with how terrible it is when CPAN installers make manual changes to files (because then things break and go bad when people move files around, not to mention a host of other strange problems). > If after a few week or months you don't see progress you can delete it from CPAN > and it will be gone. No old unsupported version available from CPAN. That's true, so that might be a reasonable compromise. :-) Perhaps you should upload it with your Makefile.PL and changes yourself, after we talk about it a bit just to confirm how things are going to go. I don't yet want the Makefile.PL in normal Bugzilla tarballs--it will confuse people who are trying to install Bugzilla, and installing Bugzilla is hard enough already without any additional confusion. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From hariniachala at gmx.com Sun Mar 28 08:27:43 2010 From: hariniachala at gmx.com (Harini Sirisena) Date: Sun, 28 Mar 2010 13:57:43 +0530 Subject: Self-Introduction: Harini Sirisena Message-ID: <9965219f1003280127v1bb4d49bx285eda2d101aa08e@mail.gmail.com> Hi, My name is Harini Sirisena (IRC: hasilk) and I would like to contribute to Bugzilla development. I am also planning on applying for the 'Better Bugzilla Helper' project of BMO (bugzilla.mozilla.org) for GSoC this year. This is my first time applying for GSoC. I am currently in my final year of study at University of Moratuwa, Sri Lanka (UTC +5.5). I am new to Perl and Template Toolkit but I have experience in web programming using PHP, ASP.net, AJAX and Javascript. The other programming languages I have worked with are Java, C# and C++. Web programming is one of my biggest areas of interest. In addition to web development I have experience working with UI design and content management using Joomla and OpenCMS. I have been trying out the new extension mechanism of Bugzilla and find it a very easy and useful method to add new features to Bugzilla installations. I would especially like to build and contribute new extensions to Bugzilla to extend its UI or to add new functionality. I am currently studying the Bugzilla code and looking for methods in which I can contribute to Bugzilla and I would greatly appreciate any advice from developers in the community. I would also like to thank Bugzilla developers for the great documentation they have provided on bugzilla.org and wiki.mozilla.org/Bugzilla which makes it easier for newcomers to learn Bugzilla code and development process:) best regards Harini -------------- next part -------------- An HTML attachment was scrubbed... URL: From szabgab at gmail.com Sun Mar 28 17:37:36 2010 From: szabgab at gmail.com (Gabor Szabo) Date: Sun, 28 Mar 2010 20:37:36 +0300 Subject: Fwd: [yapc] Call for Talks ending soon! In-Reply-To: References: Message-ID: FYI, maybe someone will give a talk about Bugzilla on YAPC::NA Gabor ---------- Forwarded message ---------- From: Date: Fri, Mar 26, 2010 at 10:19 PM Subject: [yapc] Call for Talks ending soon! To: yapc at pm.org The call for speakers ends next week! ?3/31/2010! ?Get out to the website, get your self registered and get your talks and lighting talks in before it is too late! http://robonperl.blogspot.com/2010/02/call-for-presentations-for-yapcna2010.html ) YAPC::NA::2010 is just around the corner. (Well, in as much as something 8 weeks away is "around the corner.") Last week, I met with Heath Bair and the other organizers and took the position of speaker liaison. So, I should probably talk some about what we're looking for. YAPC::NA::2010 is going to be about "Modern Perl 5". We believe that Perl 5 is a vibrant and living language with many uncharted places it can go. Perl 6 is going to be great, but we can't wait until Christmas for Perl 6. So, we're looking for presentations about Perl 5 in all of its modern glory. Whatcha got? You'll need to register (or login) to the YAPC::NA::2010 website (http://yapc2010.com/), then after registering for the conference, you can submit your CFP. Heath Bair (440) 289-9820 _______________________________________________ yapc mailing list yapc at pm.org http://mail.pm.org/mailman/listinfo/yapc From mkanat at bugzilla.org Sun Mar 28 20:07:26 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 28 Mar 2010 13:07:26 -0700 Subject: Self-Introduction: Harini Sirisena In-Reply-To: <9965219f1003280127v1bb4d49bx285eda2d101aa08e@mail.gmail.com> References: <9965219f1003280127v1bb4d49bx285eda2d101aa08e@mail.gmail.com> Message-ID: <4BAFB6FE.6060309@bugzilla.org> On 03/28/2010 01:27 AM, Harini Sirisena wrote: > My name is Harini Sirisena (IRC: hasilk) and I would like to contribute > to Bugzilla development. Hey Harini! Welcome! :-) > I am also planning on applying for the 'Better > Bugzilla Helper' project of BMO (bugzilla.mozilla.org > ) for GSoC this year. That's great. :-) That's more of a Mozilla-specific project than something that will become part of Bugzilla itself, but maybe if it gets written as an extension, then all Bugzillas could take advantage of it. > I have been trying out the new extension mechanism of Bugzilla and find > it a very easy and useful method to add new features to Bugzilla > installations. I would especially like to build and contribute new > extensions to Bugzilla to extend its UI or to add new functionality. That's great! We definitely always welcome new extensions. > I > am currently studying the Bugzilla code and looking for methods in which > I can contribute to Bugzilla and I would greatly appreciate any advice > from developers in the community. Well, pretty much what's on the Bugzilla:Developers page on the Wiki is the best advice to start with, and then if you have any questions, just come ask us on IRC. > I would also like to thank Bugzilla developers for the great > documentation they have provided on bugzilla.org > and wiki.mozilla.org/Bugzilla which > makes it easier for newcomers to learn Bugzilla code and development > process:) Hey, you're welcome, and thanks for all the nice words about it! :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Sun Mar 28 20:08:35 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 28 Mar 2010 13:08:35 -0700 Subject: Fwd: [yapc] Call for Talks ending soon! In-Reply-To: References: Message-ID: <4BAFB743.8040309@bugzilla.org> On 03/28/2010 10:37 AM, Gabor Szabo wrote: > FYI, maybe someone will give a talk about Bugzilla on YAPC::NA Thanks for letting us know! :-) I won't be able to make it to Ohio for the conference, and I don't know if any other main developer would be able to...? I think talking about the Extensions system or about how we refactored Bugzilla might be an interesting talk, I don't know. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From reps at r-systems.ee Mon Mar 29 16:54:30 2010 From: reps at r-systems.ee (reps) Date: Mon, 29 Mar 2010 09:54:30 -0700 (PDT) Subject: could not translate host name Message-ID: With checksetup.pl seems always good: [root at chaos bugzilla-3.4.4]# ./checksetup.pl * This is Bugzilla 3.4.4 on perl 5.8.8 * Running on Linux 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:47:07 EDT 2007 Checking perl modules... Checking for CGI.pm (v3.21) ok: found v3.49 Checking for Digest-SHA (any) ok: found v5.48 Checking for TimeDate (v2.21) ok: found v2.22 Checking for DateTime (v0.28) ok: found v0.55 Checking for DateTime-TimeZone (v0.71) ok: found v1.13 Checking for DBI (v1.41) ok: found v1.53 Checking for Template-Toolkit (v2.22) ok: found v2.22 Checking for Email-Send (v2.00) ok: found v2.185 Checking for Email-MIME (v1.861) ok: found v1.903 Checking for Email-MIME-Encodings (v1.313) ok: found v1.313 Checking for Email-MIME-Modifier (v1.442) ok: found v1.903 Checking for URI (any) ok: found v1.35 Checking available perl DBD modules... Checking for DBD-Pg (v1.45) ok: found v1.49 Checking for DBD-mysql (v4.00) not found Checking for DBD-Oracle (v1.19) not found The following Perl modules are optional: Checking for GD (v1.20) not found Checking for Chart (v1.0) not found Checking for Template-GD (any) not found Checking for GDTextUtil (any) not found Checking for GDGraph (any) not found Checking for XML-Twig (any) ok: found v3.29 Checking for MIME-tools (v5.406) ok: found v5.420 Checking for libwww-perl (any) ok: found v2.033 Checking for PatchReader (v0.9.4) ok: found v0.9.5 Checking for PerlMagick (any) not found Checking for perl-ldap (any) ok: found v0.34 Checking for Authen-SASL (any) ok: found v2.14 Checking for RadiusPerl (any) ok: found v0.17 Checking for SOAP-Lite (v0.710.06) not found Checking for HTML-Parser (v3.40) ok: found v3.56 Checking for HTML-Scrubber (any) ok: found v0.08 Checking for Email-MIME-Attachment-Stripper (any) ok: found v1.313 Checking for Email-Reply (any) ok: found v1.201 Checking for TheSchwartz (any) ok: found v1.10 Checking for Daemon-Generic (any) ok: found v0.61 Checking for mod_perl (v1.999022) ok: found v2.000003 *********************************************************************** * OPTIONAL MODULES * *********************************************************************** * Certain Perl modules are not required by Bugzilla, but by * * installing the latest version you gain access to additional * * features. * * * * The optional modules you do not have installed are listed below, * * with the name of the feature they enable. Below that table are the * * commands to install each module. * *********************************************************************** * MODULE NAME * ENABLES FEATURE(S) * *********************************************************************** * GD * Graphical Reports, New Charts, Old Charts * * Chart * New Charts, Old Charts * * Template-GD * Graphical Reports * * GDTextUtil * Graphical Reports * * GDGraph * Graphical Reports * * PerlMagick * Optionally Convert BMP Attachments to PNGs * * SOAP-Lite * XML-RPC Interface * *********************************************************************** COMMANDS TO INSTALL OPTIONAL MODULES: GD: /usr/bin/perl install-module.pl GD Chart: /usr/bin/perl install-module.pl Chart::Base Template-GD: /usr/bin/perl install-module.pl Template::Plugin::GD::Image GDTextUtil: /usr/bin/perl install-module.pl GD::Text GDGraph: /usr/bin/perl install-module.pl GD::Graph PerlMagick: /usr/bin/perl install-module.pl Image::Magick SOAP-Lite: /usr/bin/perl install-module.pl SOAP::Lite To attempt an automatic install of every required and optional module with one command, do: /usr/bin/perl install-module.pl --all Reading ./localconfig... Checking for DBD-Pg (v1.45) ok: found v1.49 Checking for PostgreSQL (v8.00.0000) ok: found v08.02.0600 Removing existing compiled templates... Precompiling templates...done. Fixing file permissions... Now that you have installed Bugzilla, you should visit the 'Parameters' page (linked in the footer of the Administrator account) to ensure it is set up as you wish - this includes setting the 'urlbase' option to the correct URL. [root at chaos bugzilla-3.4.4]# , but if I start from browser i get following error : Can't connect to the database. Error: could not translate host name "operatiiv.r-systems.ee" to address: Temporary failure in name resolution Best regards Raivo _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Mon Mar 29 20:06:51 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 29 Mar 2010 13:06:51 -0700 Subject: could not translate host name In-Reply-To: References: Message-ID: <4BB1085B.1090501@bugzilla.org> On 03/29/2010 09:54 AM, reps wrote: > Can't connect to the database. > Error: could not translate host name "operatiiv.r-systems.ee" to > address: Temporary failure in name resolution Hi Raivo. This question is more appropriate for the support-bugzilla mailing list, described here: http://www.bugzilla.org/support/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From justdave at bugzilla.org Tue Mar 30 01:42:01 2010 From: justdave at bugzilla.org (David Miller) Date: Mon, 29 Mar 2010 21:42:01 -0400 Subject: Fwd: [yapc] Call for Talks ending soon! In-Reply-To: <4BAFB743.8040309@bugzilla.org> References: <4BAFB743.8040309@bugzilla.org> Message-ID: <4BB156E9.6020601@bugzilla.org> Max Kanat-Alexander wrote on 3/28/10 4:08 PM: > On 03/28/2010 10:37 AM, Gabor Szabo wrote: >> FYI, maybe someone will give a talk about Bugzilla on YAPC::NA > > Thanks for letting us know! :-) > > I won't be able to make it to Ohio for the conference, and I don't know > if any other main developer would be able to...? > > I think talking about the Extensions system or about how we refactored > Bugzilla might be an interesting talk, I don't know. :-) The location is actually close enough to me that I could probably get there easily, unfortunately I will be camping with my son's Boy Scout troop that week. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Tue Mar 30 02:38:40 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 29 Mar 2010 19:38:40 -0700 Subject: Bugzilla 3.6 Coming Soon Message-ID: <4BB16430.40806@bugzilla.org> Hey folks. So, all 3.6 blockers are resolved (or will be resolved soon). I'm planning to release Bugzilla 3.6 on April 6 if nothing comes up. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From brian at schuth.com Tue Mar 30 14:39:56 2010 From: brian at schuth.com (Brian Schuth) Date: Tue, 30 Mar 2010 10:39:56 -0400 Subject: Self-Introduction: Brian Schuth Message-ID: <2895551e1003300739h12ac26foe5435d4d76104698@mail.gmail.com> I am Brian Schuth; irc nickname bschuth; located in Eastport, Maine, USA. I spend most of my time doing Oracle PL/SQL, Javascript & ASP development, but I did many, many years of perl, including doing an adaptation of my own to run bugzilla on Oracle and IIS about a decade ago. I'm inspired to join the developers' list at the moment because of a bug in Oracle querying that I'd like to fix/get fixed; Oracle-specific problems are probably where I could be most useful. bjs -- Brian Schuth 162 Water St Eastport, ME 04631 +1 207 853 0823 email:brian at schuth.com , bschuth at neriscience.com, -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Tue Mar 30 15:17:54 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 30 Mar 2010 17:17:54 +0200 Subject: Self-Introduction: Brian Schuth In-Reply-To: <2895551e1003300739h12ac26foe5435d4d76104698@mail.gmail.com> References: <2895551e1003300739h12ac26foe5435d4d76104698@mail.gmail.com> Message-ID: <4BB21622.5020200@gmail.com> Le 30. 03. 10 16:39, Brian Schuth a ?crit : > I'm inspired to join the developers' list at the moment because of a bug in > Oracle querying that I'd like to fix/get fixed; Oracle-specific problems are > probably where I could be most useful. Hello Brian, And welcome! We are definitely looking for new contributors focusing on Oracle, so there is a lot to do in this area for sure. :) LpSolit From szabgab at gmail.com Tue Mar 30 15:56:02 2010 From: szabgab at gmail.com (Gabor Szabo) Date: Tue, 30 Mar 2010 18:56:02 +0300 Subject: Releasing Bugzilla to CPAN In-Reply-To: <4BAE8952.1010607@bugzilla.org> References: <4BAE8952.1010607@bugzilla.org> Message-ID: On Sun, Mar 28, 2010 at 1:40 AM, Max Kanat-Alexander wrote: > On 03/27/2010 01:37 AM, Gabor Szabo wrote: >> did I misunderstand your comment from a few weeks ago >> and you are actually vehemently against uploading Bugzilla to CPAN? > > ? ? ? ?No, not at all. :-) (FWIW, I'm not "vehement" about any method of > installation or distribution--that would imply an emotional involvement > instead of a technical consideration, Sorry, I keep forgetting I am the only one who is emotionally involved in the open source projects he is working on. Others are in it only for the money. ;-) >> So let's discuss this. What does the Bugzilla installation process do that is >> not available in the current CPAN toolchain? Answering this question might not >> be easy as I don't know what does the Bugzilla installation process do and >> you don't know what the CPAN toolchain does. > > ? ? ? ?Hmm. I think the primary issue isn't about what checksetup.pl does that > CPAN doesn't. We've (or at least, I've) learned over time from the > differences in the Debian and Red Hat packaging methods that it's > probably better to leave post-install configuration (like setting up the > database and so forth) to Bugzilla itself, and packages should just do > the actual *installation*--that is, putting files where they belong, and > so forth. > > ? ? ? ?The problem is that although there's always a standard place for *Perl > libraries* that CPAN knows about, and a standard place for binaries in > the Filesystem Hierarchy Standard, there is no standard, widely-adopted > location for web applications to go. Also, some (actually, a surprising > number of) people want to install multiple copies of Bugzilla on the > same server, which would involve each copy having its own Bugzilla/ > libraries. Yes, people could install the first one from CPAN and the > second from the tarball, but then that might get confusing because the > *binaries* would be global, and typing "checksetup.pl" would do > something different than typing "./checksetup.pl". I guess if someone wants to install multiple versions of Bugzilla she already needs to know a bit more than just blindly follow the instructions. BTW I think I'd recommend running "perl checksetup.pl" and not "./checksetup.pl" as the former also works on windows and AFAIK the latter not. With Padre we make sure all the extra files (e.g. translation files, templates etc) are installed in the share/ directory and then we use File::ShareDir to locate those files during run-time. my $share_dir = File::ShareDir::dist_dir('Padre'); The installation is very simple, we call install_share; (or actually nowdays install_share_with_mofiles;) that installs everything that is in the ./share/ directory of the distribution. > > ? ? ? ?With the tarball, you just untar it in a directory and that *is* > Bugzilla. There's no compilation, no actual installation of the > files--that's just it. And for web applications, as far as I know, > that's pretty much the standard, unless they're FCGI apps running from a > single binary (which Bugzilla isn't). > > ? ? ? ?There's also a somewhat-significant issue with Bugzilla itself, which > is the bz_locations subroutine in Bugzilla::Constants. The CPAN > installer might have to make some manual changes to that, but I think > you and I are both familiar with how terrible it is when CPAN installers > make manual changes to files (because then things break and go bad when > people move files around, not to mention a host of other strange problems). We could modify the perl Makefile.PL process to ask the user for the target directory where she wants to install the files and copy all the files there instead of some directory in @INC. >> If after a few week or months you don't see progress you can delete it from CPAN >> and it will be gone. No old unsupported version available from CPAN. > > ? ? ? ?That's true, so that might be a reasonable compromise. :-) > > ? ? ? ?Perhaps you should upload it with your Makefile.PL and changes > yourself, after we talk about it a bit just to confirm how things are > going to go. I don't yet want the Makefile.PL in normal Bugzilla > tarballs--it will confuse people who are trying to install Bugzilla, and > installing Bugzilla is hard enough already without any additional confusion. I don't think that would be a good strategy for several reasons. One of them is that would mean I start to maintain a privately maintained fork of Bugzilla. Even with the fairly minimal changes it would still be a fork. Not something I'd like to do. The other one is that my whole point of action here is not only to get Bugzilla on CPAN but to get it done so by the core Bugzilla team. I know this might be some change in the way you work with Bugzilla but maybe it will actually help you get some more Perl developers on the team. BTW, You know you can exclude the Makefile.PL from the tarball generated by your script... ... but I hear that you do actually feel that installing Bugzilla is hard. Maybe put out a call on the blog - have you already added the Bugzilla blog to the Perl blog aggregators? - to get some help making the Bugzilla installation simpler. There might be some people out there who would want to help with that. regards Gabor From mkanat at bugzilla.org Tue Mar 30 21:26:36 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 30 Mar 2010 14:26:36 -0700 Subject: Releasing Bugzilla to CPAN In-Reply-To: References: <4BAE8952.1010607@bugzilla.org> Message-ID: <4BB26C8C.5020801@bugzilla.org> On 03/30/2010 08:56 AM, Gabor Szabo wrote: > Sorry, I keep forgetting I am the only one who is emotionally involved in the > open source projects he is working on. Others are in it only for the money. ;-) Hahaha. I'm involved in Bugzilla because I like it, for sure. :-) But the elements that surround Bugzilla are technical elements, not emotional ones. :-) If I were involved in the development of Perl or another project, I might be emotional about that. :-) > I guess if someone wants to install multiple versions of Bugzilla she already > needs to know a bit more than just blindly follow the instructions. No, actually, it more or less works with blindly following the instructions, as long as you do the Apache config twice for different directories, and name the databases differently. > BTW I think I'd recommend running "perl checksetup.pl" and not > "./checksetup.pl" as the former also works on windows and AFAIK the latter not. Mmm, no, because Bugzilla uses /usr/bin/perl and "perl" may not be /usr/bin/perl, which could be quite confusing when checksetup.pl says that all the modules are installed and then Bugzilla doesn't work. > With Padre we make sure all the extra files (e.g. translation files, > templates etc) > are installed in the share/ directory and then we use File::ShareDir to locate > those files during run-time. That's a possibility.... > We could modify the perl Makefile.PL process to ask the user for the target > directory where she wants to install the files and copy all the files there > instead of some directory in @INC. That could possibly work, for the web files. I just don't like adding a step to installation. > I know this might be some change in the way you work with Bugzilla but > maybe it will actually help you get some more Perl developers on the team. Yeah, but I don't necessarily feel that a distribution method should be focused on (or used for the reason of) developers, when the product being distributed is for end users (or in our case, sysadmins who are mostly not developers). CPAN is mostly focused around developers because it 99% or more distributes only libraries, and Bugzilla isn't a library. > BTW, You know you can exclude the Makefile.PL from the tarball > generated by your script... That's a good point. I'd probably do that, but it wouldn't help for people who use bzr or CVS to checkout or upgrade, which is a fair number of people. Also, even a simple "bzr status" would show that Makefile.PL was missing, which would be slightly weird. Alternately, there could be a script that added Makefile.PL to the distribution for CPAN, which might be better. > Maybe put out a call on the blog - have you already added the Bugzilla > blog to the Perl blog aggregators? > to get some help making the Bugzilla installation simpler. There might > be some people out there who would want to help with that. I've actually been working on that for several years, so it's getting better. At this point, I don't think it's something that a brand-new contributor would be able to dig into--it's something you'd have to have been hacking on Bugzilla for at least a few months to understand. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From szabgab at gmail.com Wed Mar 31 05:49:25 2010 From: szabgab at gmail.com (Gabor Szabo) Date: Wed, 31 Mar 2010 08:49:25 +0300 Subject: Releasing Bugzilla to CPAN In-Reply-To: <4BB26C8C.5020801@bugzilla.org> References: <4BAE8952.1010607@bugzilla.org> <4BB26C8C.5020801@bugzilla.org> Message-ID: On Wed, Mar 31, 2010 at 12:26 AM, Max Kanat-Alexander wrote: > > ? ? ? ?Yeah, but I don't necessarily feel that a distribution method should be > focused on (or used for the reason of) developers, when the product > being distributed is for end users (or in our case, sysadmins who are > mostly not developers). CPAN is mostly focused around developers because > it 99% or more distributes only libraries, and Bugzilla isn't a library. There are quite a number of applications on CPAN starting from small ones such as 'ack' via desktop applications such as Padre to some web applications. Actually I see CPAN as the way to distribute the source code and when it is relevant I'd recommend a separate, batteries inside or binary distribution. >> BTW, You know you can exclude the Makefile.PL from the tarball >> generated by your script... > > ? ? ? ?That's a good point. I'd probably do that, but it wouldn't help for > people who use bzr or CVS to checkout or upgrade, which is a fair number > of people. Also, even a simple "bzr status" would show that Makefile.PL > was missing, which would be slightly weird. I am not sure why bzr status would show Makefile.PL is missing but I hope those who are using Bugzilla straight from the repository know what they do. After all, if I understand correctly, they can easily update themselves to some very buggy development state of the code base. Gabor From mkanat at bugzilla.org Wed Mar 31 20:03:15 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 31 Mar 2010 13:03:15 -0700 Subject: Releasing Bugzilla to CPAN In-Reply-To: References: <4BAE8952.1010607@bugzilla.org> <4BB26C8C.5020801@bugzilla.org> Message-ID: <4BB3AA83.1060206@bugzilla.org> On 03/30/2010 10:49 PM, Gabor Szabo wrote: > There are quite a number of applications on CPAN starting from small > ones such as 'ack' via desktop applications such as Padre Yeah, and I see no problem with desktop apps, since they have standard directory locations in the FHS. > to some web applications. I'd be interested to see which web applications are distributed on CPAN, and how they do it. > Actually I see CPAN as the way to distribute the source code and when > it is relevant I'd recommend a separate, batteries inside or binary > distribution. I can see that, that makes sense. > I am not sure why bzr status would show Makefile.PL is missing Because if you delete a file that's in the repo, it will show as missing. > but I hope those > who are using Bugzilla straight from the repository know what they do. > After all, > if I understand correctly, they can easily update themselves to some very buggy > development state of the code base. No, actually, we recommend that even normal users upgrade using CVS, currently, which will be bzr for 3.7 and above. All the tarballs we send out retain the "CVS" directories currently, and will likely retain the ".bzr" directory (probably as a lightweight checkout) too. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too.