From justdave at bugzilla.org Thu Sep 2 18:57:41 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 02 Sep 2004 14:57:41 -0400 Subject: 2.18rc3 push Message-ID: <41376D25.8000305@bugzilla.org> Just a heads up, it'd be really cool to get 2.18rc3 out this weekend. There's a number of bugs still on the RC list that need to be knocked off first. Since we're hoping this will be the last RC before final, we really do need to kill off the entire list before we ship this time. You can find the RC list here: http://bugzilla.mozilla.org/buglist.cgi?product=Bugzilla&resolution=---&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=blocking2.18%2B I am back from my travels, and mostly settled back in at home, so I should be around a little more again for approvals and so forth (and you can still pick on Myk, too, if I'm not fast enough for you). -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From kiko at async.com.br Thu Sep 2 23:04:54 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 2 Sep 2004 20:04:54 -0300 Subject: Wrapping HTML in templates Message-ID: <20040902230453.GC5314@async.com.br> Jouni's giving me a hard time because I'm reluctant to wrap HTML in templates. I'm trying to figure out what the right way to do this is; it isn't as trivial as it seems. This may pass as ironical to people who know me for being a strict 72-char wrapper; I just don't think this rule applies very well to the whitespace-intolerant nature of HTML, in particular, HTML links. So here's a public cry for help that others may enjoy as well: a) How does one wrap a long link which isn't broken by template statements?

Skip all this nonsense, and go back to the query page\n"; b) How does one wrap a long link which *is* broken by template statements? File / c) How does one wrap a long HTML statement that includes tags (and therefore doesn't like spurious spacing here and there) such as:
[% collapsed ? '(+)' : '(-)' %] Yes, this last one is horrible. Yes, parts of it could be broken into separate lines. The question is: is it worth it if parts of it won't be wrappable anyway? Here's a try:
[% collapsed ? '(+)' : '(-)' %] [...]
Is it really that much better? I've tended to use the policy: if a large portion of the line isn't wrappable, don't bother with wrapping smaller parts of it unless it makes things a lot better. Is that a bad policy? Note that one alternative is wrapping *inside* tags and TT statements. Something like unfolding the above td into:
[% collapsed ? '(+)' : '(-)' %] I really think that's evil and makes the code much harder to follow, but I may be convinced otherwise. Note that we can't simply break around the because the link text expands to cover whitespace in many cases. Nothing convinces me that wrapping HTML makes it easier to read so far. I'd be really happy if some consensus is reached; I'm really not a newbie to Bugzilla or to development, and I don't know what to do in most of these cases (that is, if I'm actually doing something wrong ), so it's probable that either I'm being clueless or it's really not such a trivial matter. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From timeless at myrealbox.com Thu Sep 2 23:57:10 2004 From: timeless at myrealbox.com (timeless) Date: Thu, 02 Sep 2004 16:57:10 -0700 Subject: Wrapping HTML in templates In-Reply-To: <20040902230453.GC5314@async.com.br> References: <20040902230453.GC5314@async.com.br> Message-ID: <4137B356.5080200@myrealbox.com> Christian Robottom Reis wrote: > Jouni's giving me a hard time because I'm reluctant to wrap HTML in > templates. I'm trying to figure out what the right way to do this is; it > isn't as trivial as it seems. This may pass as ironical to people who > know me for being a strict 72-char wrapper; I just don't think this rule > applies very well to the whitespace-intolerant nature of HTML, in > particular, HTML links. > > So here's a public cry for help that others may enjoy as well: > > a) How does one wrap a long link which isn't broken by template > statements? > >

Skip all this nonsense, and go back to the query page\n";

Skip all this nonsense, and go back to the query page "; > > b) How does one wrap a long link which *is* broken by template > statements? > > File / File / > c) How does one wrap a long HTML statement that includes tags > (and therefore doesn't like spurious spacing here and there) such > as: > >
[% collapsed ? '(+)' : '(-)' %]
[% collapsed ? '(+)' : '(-)' %] > Yes, this last one is horrible. Yes, parts of it could be broken into > separate lines. The question is: is it worth it if parts of it won't be > wrappable anyway? Here's a try: > > > > > > > >
[% collapsed ? '(+)' : '(-)' %] > [...] >
> > Is it really that much better? > > I've tended to use the policy: if a large portion of the line isn't > wrappable, don't bother with wrapping smaller parts of it unless it > makes things a lot better. Is that a bad policy? > > Note that one alternative is wrapping *inside* tags and TT statements. > Something like unfolding the above td into: > >
onclick="return twisty_click(this)">[% > collapsed ? '(+)' : '(-)' %] type="checkbox" name="[% file.filename FILTER html %]"[% > collapsed ? '' : ' checked' %] style="display: none"> [% collapsed ? '(+)' : '(-)' %] > I really think that's evil and makes the code much harder to follow, but > I may be convinced otherwise. Note that we can't simply break around the > because the link text expands to cover whitespace in many cases. > > Nothing convinces me that wrapping HTML makes it easier to read so far. the reason to wrap is to own blame for as few characters as possible :). > I'd be really happy if some consensus is reached; I'm really not a > newbie to Bugzilla or to development, and I don't know what to do in > most of these cases (that is, if I'm actually doing something wrong > ), so it's probable that either I'm being clueless or it's really > not such a trivial matter. From bugzilla at glob.com.au Fri Sep 3 01:45:14 2004 From: bugzilla at glob.com.au (bugzilla at glob.com.au) Date: Fri, 3 Sep 2004 09:45:14 +0800 (WST) Subject: chinese text in bug reports? Message-ID: <20040903014514.E93354BC367@sweep.bur.st> > This is set in Bugzilla/CGI.pm. > Locate the line that says: > $cgi->charset(""); > Change that to: > $cgi->charset("UTF-8"); > > Bugzilla will eventually ship with this set to UTF-8, but we don't yet > because there's no clean way to convert legacy data, and it would break > anyone upgrading from an older Bugzilla. how about making it a boolean parameter (because we don't have enough) that checksetup sets to true on the first run (when the admin account is created) or to false if the parameter doesn't already exist. that way new installs will get UTF-8, existing won't, but it can be enabled manually. begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From jpyeron at pdinc.us Fri Sep 3 01:52:41 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Thu, 2 Sep 2004 21:52:41 -0400 (EDT) Subject: chinese text in bug reports? In-Reply-To: <20040903014514.E93354BC367@sweep.bur.st> Message-ID: is there a b.m.o bug for this? On Fri, 3 Sep 2004 bugzilla at glob.com.au wrote: > > This is set in Bugzilla/CGI.pm. > > Locate the line that says: > > $cgi->charset(""); > > Change that to: > > $cgi->charset("UTF-8"); > > > > Bugzilla will eventually ship with this set to UTF-8, but we don't yet > > because there's no clean way to convert legacy data, and it would break > > anyone upgrading from an older Bugzilla. > > > how about making it a boolean parameter (because we don't have enough) that > checksetup sets to true on the first run (when the admin account is created) > or to false if the parameter doesn't already exist. > > that way new installs will get UTF-8, existing won't, but it can be enabled > manually. > > > > begin-base64 644 signature.gif > R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p > XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf > h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH > N1PRMXimiLUGt3ElVimlgbllWAAAOw== > ==== > > - > To view or change your list settings, click here: > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Partner & Sr. Manager Pyerotechnics Development, Inc. - - +1 (443) 451-2697 500 West University Parkway #1S - - +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From justdave at bugzilla.org Fri Sep 3 03:09:49 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 02 Sep 2004 23:09:49 -0400 Subject: chinese text in bug reports? In-Reply-To: References: Message-ID: <4137E07D.9050507@bugzilla.org> Jason Pyeron wrote: > is there a b.m.o bug for this? http://bugzilla.mozilla.org/show_bug.cgi?id=bz-charset -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Fri Sep 3 03:11:16 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 02 Sep 2004 23:11:16 -0400 Subject: chinese text in bug reports? In-Reply-To: <20040903014514.E93354BC367@sweep.bur.st> References: <20040903014514.E93354BC367@sweep.bur.st> Message-ID: <4137E0D4.20502@bugzilla.org> bugzilla at glob.com.au wrote: >>Bugzilla will eventually ship with this set to UTF-8, but we don't yet >>because there's no clean way to convert legacy data, and it would break >>anyone upgrading from an older Bugzilla. > > how about making it a boolean parameter (because we don't have enough) that > checksetup sets to true on the first run (when the admin account is created) > or to false if the parameter doesn't already exist. > > that way new installs will get UTF-8, existing won't, but it can be enabled > manually. The other thing stopping us from doing that is email. The summaries need to be MIMEWord-encoded if they contain any non-ASCII characters. Once that's being done, this sounds great. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From kiko at async.com.br Fri Sep 3 12:22:38 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 3 Sep 2004 09:22:38 -0300 Subject: chinese text in bug reports? In-Reply-To: <20040903014514.E93354BC367@sweep.bur.st> References: <20040903014514.E93354BC367@sweep.bur.st> Message-ID: <20040903122238.GA583@async.com.br> On Fri, Sep 03, 2004 at 09:45:14AM +0800, bugzilla at glob.com.au wrote: > how about making it a boolean parameter (because we don't have enough) that > checksetup sets to true on the first run (when the admin account is created) > or to false if the parameter doesn't already exist. Well, careful when saying "if the parameter doesn't already exist" because on b.m.o., for one, the parameter won't exist but we don't want it on anyway. This should really only be enable for new installations -- perhaps that means only installations where longdescs is empty *and* no parameter exists. What do you think? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From chicks at chicks.net Fri Sep 3 13:36:46 2004 From: chicks at chicks.net (Christopher Hicks) Date: Fri, 3 Sep 2004 09:36:46 -0400 (EDT) Subject: chinese text in bug reports? In-Reply-To: <20040903122238.GA583@async.com.br> References: <20040903014514.E93354BC367@sweep.bur.st> <20040903122238.GA583@async.com.br> Message-ID: On Fri, 3 Sep 2004, Christian Robottom Reis wrote: > On Fri, Sep 03, 2004 at 09:45:14AM +0800, bugzilla at glob.com.au wrote: >> how about making it a boolean parameter (because we don't have enough) that >> checksetup sets to true on the first run (when the admin account is created) >> or to false if the parameter doesn't already exist. > > Well, careful when saying "if the parameter doesn't already exist" > because on b.m.o., for one, the parameter won't exist but we don't want > it on anyway. Why wouldn't the paramater exist? Don't all of the config parameters exist in every install? Am I missing some fundamental facet of how bz works? > This should really only be enable for new installations -- I'm pretty sure that's the aim. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From bugzilla at glob.com.au Fri Sep 3 13:57:26 2004 From: bugzilla at glob.com.au (bugzilla at glob.com.au) Date: Fri, 3 Sep 2004 21:57:26 +0800 (WST) Subject: chinese text in bug reports? Message-ID: <20040903135726.76D904BC5FA@sweep.bur.st> > >> how about making it a boolean parameter (because we don't have enough) > >> that checksetup sets to true on the first run (when the admin account is > >> created) or to false if the parameter doesn't already exist. > > > > Well, careful when saying "if the parameter doesn't already exist" > > because on b.m.o., for one, the parameter won't exist but we don't want > > it on anyway. hrm, perhaps pseudocode would make it clearer: checksetup.pl updateparams // adds param(ut8) with default value of false .. if (bz database has no users) prompt user for admin email, etc set param(ut8) to true > Why wouldn't the paramater exist? Don't all of the config parameters > exist in every install? Am I missing some fundamental facet of how bz > works? when you add a parameter to defparams.pl, it's doesn't exist in data/params until checksetup calls Bugzilla::Config::UpdateParams() begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From kiko at async.com.br Fri Sep 3 14:05:59 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 3 Sep 2004 11:05:59 -0300 Subject: chinese text in bug reports? In-Reply-To: <20040903135726.76D904BC5FA@sweep.bur.st> References: <20040903135726.76D904BC5FA@sweep.bur.st> Message-ID: <20040903140559.GB1327@async.com.br> On Fri, Sep 03, 2004 at 09:57:26PM +0800, bugzilla at glob.com.au wrote: > checksetup.pl > > updateparams // adds param(ut8) with default value of false > .. > if (bz database has no users) > prompt user for admin email, etc > set param(ut8) to true Ah, perfect. I had missed this "has no users" bit. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From kiko at async.com.br Fri Sep 3 20:25:52 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 3 Sep 2004 17:25:52 -0300 Subject: [Fwd: Re: Wrapping HTML in templates] In-Reply-To: <4138A342.30002@heikniemi.net> References: <4138A342.30002@heikniemi.net> Message-ID: <20040903202552.GK1327@async.com.br> So this one starts with another practical question. Here I have: [% FILTER closed(isclosed) +%][% terms.bug %] [%+ bugid %][% END %]: [%+ bug.summary FILTER html %][[% INCLUDE buginfo %]] This one is tricky. First answer is: [% FILTER closed(isclosed) %] [% terms.bug %] [%+ bugid %] [% END %] : [%+ bug.summary FILTER html %] [[% INCLUDE buginfo %]] This is obviously wrong: it adds a space before the (because of the newline after FILTER), and a space between and , because of the newline there too. It also adds spaces around and between the spans. The obvious alternative to the first problem: [% FILTER closed(isclosed) -%] [% terms.bug %] [%+ bugid %] or: [% FILTER closed(isclosed) %][% terms.bug %] [%+ bugid %] both leave me unsatisfied, but let's assume I have to choose between them. I haven't even started discussing , so let's start now: [% FILTER closed(isclosed) %][% terms.bug %] [%+ bugid %]: [%+ bug.summary FILTER html %][[% INCLUDE buginfo %]] But no, Jouni will never accept that . Let's try some more: [% FILTER closed(isclosed) %][% terms.bug %] [%+ bugid %]: [%+ bug.summary FILTER html %][[% INCLUDE buginfo %]] But that violates the 80-char line rule as well. And at this point, I don't know what to do, and I've wasted 1 hour of my life trying to figure out decent ways of getting this to wrap correctly. While I have always strived to get indentation and wrapping correct, I feel there are a lot of better things that I could spend my time on than this. I'm sure you all will agree, and this is why I call for the following guideline: If the wrapping and indentation of a block of a spacing-sensitive TT text doesn't look really nice, you can *ask* or [nit] about it, but given that in many situations it's close to impossible to get right, don't block review on it. [1] Anyone have a clue why that doesn't work? I think it has to do with FILTER outputting its own HTML. Note however that even if it did, I can sit down and contrive an example of where the FILTER itself is *not* the culprit and that there simply is no way to avoid the wrapping and spacing issue presented here. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From jouni at heikniemi.net Fri Sep 3 16:16:45 2004 From: jouni at heikniemi.net (Jouni Heikniemi) Date: Fri, 03 Sep 2004 19:16:45 +0300 Subject: Wrapping HTML in templates In-Reply-To: <20040902230453.GC5314@async.com.br> References: <20040902230453.GC5314@async.com.br> Message-ID: <413898ED.90606@heikniemi.net> Christian Robottom Reis wrote: > Jouni's giving me a hard time because I'm reluctant to wrap HTML in > templates. I'm trying to figure out what the right way to do this is; it > isn't as trivial as it seems. This may pass as ironical to people who > know me for being a strict 72-char wrapper; I just don't think this rule > applies very well to the whitespace-intolerant nature of HTML, in > particular, HTML links. ;-) Here are my two cents. But to start off: No, I don't think it's a trivial matter, and no, I don't think 80 chars is an ?berstrict border we must obey at all costs. If wrapping results in bizarre code, let's ignore it. The rule is there to clean up code, not to promote itself. However, I disagree with your thoughts on the "whitespace-intolerant nature of HTML" - HTML by itself is very whitespace-tolerant, although the issue of links expanding to a single whitespace around the actual link texts is somewhat problematic. However, wrapping inside the elements is not a new concept, and it's one we're already recommending in the devguide. I think the guide's two golden rules on HTML templates are pretty good: # Indentation - HTML Templates should have a 2-space indent. # Line Length - You shouldn't extend lines past 80 characters - instead, break lines, in the middle of multi-attributed HTML tags if necessary. > a) How does one wrap a long link which isn't broken by template > statements? >

Skip all this nonsense, and go back to the query page\n"; Well, this one is easy, since you can just wrap the text. Then again, I wouldn't bother in _every_ situation. I think the biggest point here is that the non-visible part of the line (assume everything beyond 80 chars) shouldn't contain surprises. In that particular example, it doesn't. I'd have a better feeling about; it _is_ more readable anyway.

Skip all this nonsense, and go back to the query page > b) How does one wrap a long link which *is* broken by template > statements? > File / I am under the impression that we've been developing a practice of wrapping before a TT tag. For that example, I prefer File / > c) How does one wrap a long HTML statement that includes tags > (and therefore doesn't like spurious spacing here and there) such > as: That is difficult. Before I go after your example, let me note you about a couple of different tactics used elsewhere, neither of which I would be ready to incorporate into devguide but which might save you at some point: Link text Continues Here (that particular demo blows, but you get the idea with SGML comments) A similar approach: Link text Continues Here However, that one's very ill-suited to closing tags, so I think it has very limited usability. > I've tended to use the policy: if a large portion of the line isn't > wrappable, don't bother with wrapping smaller parts of it unless it > makes things a lot better. Is that a bad policy? Perhaps to your surprise, I think it's a good policy. It's just that overusing it destroys whatever clarity we've reached by aiming for the 80 char line length. To look at your example: >

onclick="return twisty_click(this)">[% > collapsed ? '(+)' : '(-)' %] type="checkbox" name="[% file.filename FILTER html %]"[% > collapsed ? '' : ' checked' %] style="display: none"> Yes, this is ugly too. It's ugly among other things because you're increasing the indentation all the way, so the readability of the actual hierarchy suffers. These are some of the cases where SGML commenting the linefeed may actually help pretty significantly; it allows you to keep indentation in check while preserving at least some wrapping freedom. One more thing: When facing a hard wrapping problem, I often first cut slack on the indentation rules of irrelevant elements to give more horizontal space. Here's a quick shot which goes to one extreme with grouping "irrelevant" tags on the same line; that might be pushing it. Also note that you usually _can_ have whitespace at the beginning/end of flow/block content (like ; that's different from inline content like ). [% collapsed ? '(+)' : '(-)' %]
Well, that's not the best I've seen or made, but I think it beats the 250 char line. There's a lot you could work on, but I think works the same as your original example (I can't easily test the interdiff patch locally :-() and perhaps more readable. At least you can see the whole thing at a glance. What do you think? Jouni Ps. Hey, you could avoid using the by starting the latter tag with [% "<" %], thus invoking pre_chomp. O:-) From tero_niemela at yahoo.com Sun Sep 5 13:51:55 2004 From: tero_niemela at yahoo.com (Tero Niemela) Date: Sun, 5 Sep 2004 06:51:55 -0700 (PDT) Subject: Other tools (FYI) Message-ID: <20040905135155.86880.qmail@web61301.mail.yahoo.com> Hey ya, I made a very short evaluation of bug reporting tools for my project and below is the list of the tools I compared. My point with this posting is that if you haven't heard of these tools, go check them out, there might some good ideas to implement in bugzilla, too. (Yes, I ended up recommending Bugzilla, it's easy to use and commonly used although I noticed the as many competing solutions are trumpeting: bugzilla is mainly for bug reporting only, others are useful also in request tracking, support, process control. Anyways, thanks for your hard work!) JIRA: http://www.atlassian.com/software/jira/ "You can forget Bugzilla. JIRA beats it hands down." :) ExtraView: http://www.sesame.com/ Request Tracker: http://www.bestpractical.com/rt/ GNATS: http://www.gnu.org/software/gnats/ Bugzero: http://www.websina.com/bugzero/index.html Lots of others are listed here, with direct links to short evaluations: http://www.websina.com/bugzero/misc/vendors.html Thanks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From bz at barnson.org Sun Sep 5 14:57:22 2004 From: bz at barnson.org (Barnboy) Date: Sun, 5 Sep 2004 08:57:22 -0600 Subject: Other tools (FYI) In-Reply-To: <20040905135155.86880.qmail@web61301.mail.yahoo.com> References: <20040905135155.86880.qmail@web61301.mail.yahoo.com> Message-ID: <20040905145722.GF87725@barnson.org> On Sun, Sep 05, 2004 at 06:51:55AM -0700, Tero Niemela wrote: > (Yes, I ended up recommending Bugzilla, it's easy to > use and commonly used Why do you say that you recommend Bugzilla, when you actually recommend BugZero? -- Matthew P. Barnson - - - - Thought for the moment: ARCHDUKE FERDINAND FOUND ALIVE -- FIRST WORLD WAR A MISTAKE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From tero_niemela at yahoo.com Mon Sep 6 14:55:31 2004 From: tero_niemela at yahoo.com (Tero Niemela) Date: Mon, 6 Sep 2004 07:55:31 -0700 (PDT) Subject: Other tools (FYI) In-Reply-To: <20040905145722.GF87725@barnson.org> Message-ID: <20040906145531.84722.qmail@web61301.mail.yahoo.com> > Why do you say that you recommend Bugzilla, when you > actually recommend BugZero? I'm not quite sure how you made this conclusion. The BugZero page I mentioned was there just because it listed a great number of other rather similar tools. I (we) use Bugzilla. _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From chicks at chicks.net Mon Sep 6 15:45:11 2004 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 6 Sep 2004 11:45:11 -0400 (EDT) Subject: Other tools (FYI) In-Reply-To: <20040906145531.84722.qmail@web61301.mail.yahoo.com> References: <20040906145531.84722.qmail@web61301.mail.yahoo.com> Message-ID: On Mon, 6 Sep 2004, Tero Niemela wrote: > I'm not quite sure how you made this conclusion. The BugZero page I > mentioned was there just because it listed a great number of other > rather similar tools. I (we) use Bugzilla. I don't think your post indicated any preference for BugZero. I for one appreciated your list of links. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From mkgnu at gmx.net Mon Sep 6 16:44:53 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Mon, 06 Sep 2004 09:44:53 -0700 Subject: Other tools (FYI) In-Reply-To: <20040906145531.84722.qmail@web61301.mail.yahoo.com> References: <20040906145531.84722.qmail@web61301.mail.yahoo.com> Message-ID: <1094489092.4612.897.camel@syd.mkgnu.net> But the bottom of http://www.websina.com/bugzero/misc/vendors.html reads "May we recommend you the following bug tracking and help desk customer support software: >>> BUGZERO BUGZERO BUGZERO BUGZERO BUGZERO BUGZERO BUGZERO " On Mon, 2004-09-06 at 07:55, Tero Niemela wrote: > > Why do you say that you recommend Bugzilla, when you > > actually recommend BugZero? > > I'm not quite sure how you made this conclusion. The > BugZero page I mentioned was there just because it > listed a great number of other rather similar tools. I > (we) use Bugzilla. > > > > _______________________________ > Do you Yahoo!? > Express yourself with Y! Messenger! Free. Download now. > http://messenger.yahoo.com > - > To view or change your list settings, click here: > > From chicks at chicks.net Mon Sep 6 17:03:01 2004 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 6 Sep 2004 13:03:01 -0400 (EDT) Subject: Other tools (FYI) In-Reply-To: <1094489092.4612.897.camel@syd.mkgnu.net> References: <20040906145531.84722.qmail@web61301.mail.yahoo.com> <1094489092.4612.897.camel@syd.mkgnu.net> Message-ID: On Mon, 6 Sep 2004, Kristis Makris wrote: > But the bottom of http://www.websina.com/bugzero/misc/vendors.html reads > > > "May we recommend you the following bug tracking and help desk customer > support software: >>>> BUGZERO BUGZERO BUGZERO BUGZERO BUGZERO BUGZERO BUGZERO " Linking to something that's obviously biased doesnt' make the poster so biased. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From venkateshs at ivega.com Tue Sep 7 09:44:27 2004 From: venkateshs at ivega.com (Venkatesh Sharma) Date: Tue, 7 Sep 2004 15:14:27 +0530 Subject: testing bugzilla Message-ID: <976C79A69CF9D411BF9A00508B2CECEB05C9F227@MAIL> I am using Bugzilla 2.17.6. I have applied several patches from the BMO. what I would like to know is, are there any standard test cases for testing any of the functionalities in bugzilla ?. If there is any I would save a lot of time. could someone help me? Thanks & Regards Venkatesh Sharma From burnus at gmx.de Tue Sep 7 10:35:16 2004 From: burnus at gmx.de (Tobias Burnus) Date: Tue, 07 Sep 2004 12:35:16 +0200 Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching of templates/en/ Message-ID: <413D8EE4.5070305@gmx.de> Hello, since this a kind of FAQ regarding bugzilla-de, which is frequently set up as languages=de,en and defaultlanguage=en, I'm thinking of changing the current accept-languages--languages matching. See also bug 258246, http://bugzilla.mozilla.org/show_bug.cgi?id=258246 ------------------------------------ Current behaviour: HTTP ACCEPT LANGUAGES: en matches templates/{en,en-gb,en-us,en-gb-cockney}/ HTTP ACCEPT LANGUAGES: en-gb only matches templates/{en-gb,en-gb-cockney} This is according to the specs: # Per RFC 1766 and RFC 2616 any language tag matches also its # primary tag. That is 'en' (accept language) matches 'en-us', # 'en-uk' etc. but not the otherway round. (This is unfortunally # not very clearly stated in those RFC; see comment just over 14.5 # in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4) And makes sense, but it is not very intuitive. Being in Germany I'd set 'de-de' in the browser. The w3c's comment suggest that the browser then ask to add/automatically adds 'de' as well. But for instance Mozilla doesn't do this. The question is: Should we change the behaviour of Bugzilla? That is 'en-gb' should match 'en' (and (?) 'en-*'?). Should this be optional? Or what is the right (TM) way to proceed? I currently recommend: ln -s de de-at ln -s de de-be ln -s de de-ch ln -s de de-de ln -s de de-lu and "languages = de-at,de-be,de-ch,de-de,de-lu,en", defaultlanguage=en But this is quite cumbersom. ------------------------------------ One option would be to add a boolean option to defparams.pl. Any better ideas? Tobias From PCampbell at ourvacationstore.com Tue Sep 7 20:02:53 2004 From: PCampbell at ourvacationstore.com (Patrick Campbell) Date: Tue, 7 Sep 2004 13:02:53 -0700 Subject: Buzilla 2.16.5 and InnoDB compatibility Message-ID: <202DB470B8484B469E8B4302E44A7139091DF007@mail.ourvacationstore.com> Hello, I apologize if this is seemingly self explanatory but I was unable to derive anything from google searches. We are currently running Bugzilla 2.16.5 and MySQL 3.23.58 with MyISAM. Interested in running InnoDB for increased overall performance, specifically with writes. It is unclear if we can simply enable InnoDB in MySQL and convert the table types or if this will cause critical failures with Bugzilla due to the differences in query syntaxes between MyISAM and InnoDB. Finally, is this something that should be necessary? Our db has ~2500 bugs. Patrick Campbell OurVacationStore.com Website Administrator pcampbell at ourvacationstore.com From gerv at mozilla.org Tue Sep 7 23:06:44 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 08 Sep 2004 00:06:44 +0100 Subject: testing bugzilla In-Reply-To: <976C79A69CF9D411BF9A00508B2CECEB05C9F227@MAIL> References: <976C79A69CF9D411BF9A00508B2CECEB05C9F227@MAIL> Message-ID: <413E3F04.5000008@mozilla.org> Venkatesh Sharma wrote: > I am using Bugzilla 2.17.6. I have applied several patches from the BMO. > what I would like to know is, are there any standard test cases for testing > any of the functionalities in bugzilla ?. If there is any I would save a lot > of time. could someone help me? There are the tests - execute runtests.sh. However, it doesn't really test function as such. Gerv From bugreport at peshkin.net Tue Sep 7 23:29:40 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 07 Sep 2004 16:29:40 -0700 Subject: Buzilla 2.16.5 and InnoDB compatibility In-Reply-To: <202DB470B8484B469E8B4302E44A7139091DF007@mail.ourvacationstore.com> References: <202DB470B8484B469E8B4302E44A7139091DF007@mail.ourvacationstore.com> Message-ID: <413E4464.9030105@peshkin.net> Patrick Campbell wrote: >Hello, > >I apologize if this is seemingly self explanatory but I was unable to derive >anything from google searches. > >We are currently running Bugzilla 2.16.5 and MySQL 3.23.58 with MyISAM. >Interested in running InnoDB for increased overall performance, specifically >with writes. > >It is unclear if we can simply enable InnoDB in MySQL and convert the table >types or if this will cause critical failures with Bugzilla due to the >differences in query syntaxes between MyISAM and InnoDB. > >Finally, is this something that should be necessary? Our db has ~2500 bugs. > > > No. You cannot just switch to InnoDB. There are many sites that dwarf yours. Carefully examine the limits of your current performance before doing anything. Very few performance issues scale with the number of bugs. If you are interested in improving database performance, upgrade to MySQL 4.0 and consider upgrading to Bugzilla 2.18 and using a shadow database. From jpyeron at pdinc.us Tue Sep 7 23:35:33 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Tue, 7 Sep 2004 19:35:33 -0400 (EDT) Subject: Buzilla 2.16.5 and InnoDB compatibility In-Reply-To: <413E4464.9030105@peshkin.net> Message-ID: I don't remember any MyISAM specific details, if there are could you list some? On Tue, 7 Sep 2004, Joel Peshkin wrote: > Patrick Campbell wrote: > > >It is unclear if we can simply enable InnoDB in MySQL and convert the table > >types or if this will cause critical failures with Bugzilla due to the > >differences in query syntaxes between MyISAM and InnoDB. > > > No. You cannot just switch to InnoDB. > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Partner & Sr. Manager Pyerotechnics Development, Inc. - - +1 (443) 451-2697 500 West University Parkway #1S - - +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From bugreport at peshkin.net Wed Sep 8 00:23:56 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 07 Sep 2004 17:23:56 -0700 Subject: Buzilla 2.16.5 and InnoDB compatibility In-Reply-To: References: Message-ID: <413E511C.80805@peshkin.net> Jason Pyeron wrote: >I don't remember any MyISAM specific details, if there are could you list >some? > > > > Start with fulltext index. From timeless at myrealbox.com Wed Sep 8 13:10:04 2004 From: timeless at myrealbox.com (timeless) Date: Wed, 08 Sep 2004 06:10:04 -0700 Subject: [Fwd: Re: Wrapping HTML in templates] In-Reply-To: <20040903202552.GK1327@async.com.br> References: <4138A342.30002@heikniemi.net> <20040903202552.GK1327@async.com.br> Message-ID: <413F04AC.9070900@myrealbox.com> Christian Robottom Reis wrote: > So this one starts with another practical question. Here I have: > > [% FILTER closed(isclosed) +%][% terms.bug %] [%+ bugid %][% END %]: [%+ bug.summary FILTER html %][[% INCLUDE buginfo %]] i still like my style: [% FILTER closed(isclosed) %][% terms.bug %] [%+ bugid %] [% END %]: [%+ bug.summary FILTER html %] [[% INCLUDE buginfo %]] From justdave at bugzilla.org Wed Sep 8 19:33:39 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 08 Sep 2004 15:33:39 -0400 Subject: UI Changes Message-ID: <413F5E93.1030900@bugzilla.org> We all agreed a while back that we were going to let Kiko give Bugzilla a UI overhaul (making it more friendly to use, etc), with his only roadblock being to get it past myself and Myk. Kiko has a few people employed for him currently who he's got working on this, and it's of course slowing them down to wait for approvals that lately are coming with lots of negative reviews (which may not be a bad thing, but more on that later). Kiko insists that some of the later work will build on the earlier patches and when it's all done, it'll look beautiful, even if a lot of the in-between steps wind up making it worse short-term. That said, if that actually turns out to be the case, it would make it a lot easier for approvals to be able to see the final product first. We're also less than a week away from freezing for 2.20, which means landing potentially ugly intermediate steps now is probably a bad thing. What I'm going to do is give Kiko a branch to play on, with a few conditions on it. We successfully used a branch for the group system rewrite, and although it is in smaller pieces, this is a similar magnitude change, so we ought to be able to make it work. The conditions: 1) I'll set up an install on landfill that pulls his branch regularly so we can all visit and see how it's working. 2) Separate patches for each change still need to be maintained. He can indicate on the status whiteboard if he's checked it in on the branch. This is so that each change can still be individually reviewed as it goes in when we pull them back to the trunk, but this way we'll have a better idea what the final product will be when we get to that point, and changes can still be made. 3) The branch will need to be synced with the trunk regularly so the effects of new stuff on the trunk can be taken into account. 4) We are under no obligation to take anything to the trunk. But if it all turns out the way it's advertised, hopefully we'll want to :) The patches can be reviewed and pulled to the trunk piecemeal as we get time after we branch for 2.20, and things that look ugly, but "there's additional patches coming that'll make it much better" we can wait until those additional patches are available so we can see if that's really the case, and then take them all at once when it's pretty. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mapopa at gmail.com Thu Sep 9 10:07:09 2004 From: mapopa at gmail.com (marius popa) Date: Thu, 9 Sep 2004 13:07:09 +0300 Subject: porting to firebird Message-ID: i have seen this bug http://bugzilla.mozilla.org/show_bug.cgi?id=249254 and is a good time to start working on it :) Where should i start ? 1.Check out bugzilla development version from cvs ? 2.Maybe to take a look at postgresql port and patches ? ps: any hints are welcome From kiko at async.com.br Thu Sep 9 12:03:37 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 9 Sep 2004 09:03:37 -0300 Subject: porting to firebird In-Reply-To: References: Message-ID: <20040909120337.GC548@async.com.br> On Thu, Sep 09, 2004 at 01:07:09PM +0300, marius popa wrote: > 1.Check out bugzilla development version from cvs ? > 2.Maybe to take a look at postgresql port and patches ? Yes to both. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From gerv at mozilla.org Thu Sep 9 13:17:40 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 09 Sep 2004 14:17:40 +0100 Subject: Joel On Software quote Message-ID: <414057F4.5060203@mozilla.org> http://www.joelonsoftware.com/articles/NotJustUsability.html "Since then, I've become even more devoted to the idea of the value of good social interface design: we bring in experts like Clay Shirky (a pioneer in the field), we do bold experiments on the poor citizens of the Joel on Software discussion group (many of which are so subtle as to be virtually unnoticeable, for example, the fact that we don't show you the post you're replying to while you type your reply in hopes of cutting down quoting, which makes it easier to read a thread), and we're investing heavily in advanced algorithms to reduce discussion group spam." Joel believes that cutting down quoting, rather than encouraging it, is good social interface design :-) Gerv From chicks at chicks.net Thu Sep 9 15:17:06 2004 From: chicks at chicks.net (Christopher Hicks) Date: Thu, 9 Sep 2004 11:17:06 -0400 (EDT) Subject: Joel On Software quote In-Reply-To: <414057F4.5060203@mozilla.org> References: <414057F4.5060203@mozilla.org> Message-ID: On Thu, 9 Sep 2004, Gervase Markham wrote: > http://www.joelonsoftware.com/articles/NotJustUsability.html > > "Since then, I've become even more devoted to the idea of the value of good > social interface design: we bring in experts like Clay Shirky (a pioneer in > the field), we do bold experiments on the poor citizens of the Joel on > Software discussion group (many of which are so subtle as to be virtually > unnoticeable, for example, the fact that we don't show you the post you're > replying to while you type your reply in hopes of cutting down quoting, which > makes it easier to read a thread), and we're investing heavily in advanced > algorithms to reduce discussion group spam." > > Joel believes that cutting down quoting, rather than encouraging it, is good > social interface design :-) Joel is always right for Joel's Universe and Joel is certainly good food for thought in other universes, but in this case the food leaves me feeling a bit ill. In the Chicks Universe where I live having people clued enough to quote makes problems like chat spam nearly nonexistant and certainly not enough of an issue that anyone has complained in ages. Conversations (particularly in terms of bugs) tend to drag in additional participatings through time and can be somewhat complex. Expecting new participants to read the whole bug to get up to speed on the issues works for some folks some of the time, but quoting provides the opportunity to contextify subsequent comments enough that diving all the way in isn't absolutely necessary. For instance, there's no reason for the LDAP admin to need to know or wade through all of the screen layout niggling that's gone on to answer which LDAP schema we need to work from. The new bugzilla Reply feature has been very popular and appreciated in our bugzilla for providing just enough context for somebody that's newly cc'd into the bug. The concept of forcing people to wade through and establish their own context instead seems unnecessarily cruel. I think Joel's idea of social interface design is fundamentally flawed because it seems to be trying to solve cultural problems in software. The resulting software then fails to work worth a darn for people that don't share those cultural problems. In this case Joel's pet culture can't persuade people to quote just enough to provide context for their new comments. I've certainly been frustrated by similar things on mailing lists. Why do people quote entire digests to say "me too"? I suspect many of us have witnessed people militantly asking folks not to reply to things to start a new thread. So the sorts of things that frustrate Joel are by no means unique to his culture. But there are other cultures that don't share those behavior issues. Designing software so that it makes it harder for people to quote would just irritate the user in these other cultures. I deal with academics and scientists using my software and providing feedback. These people have no difficulty quoting ten or 12 different previous items and the result makes sense and actually moves the discussion along toward getting the software done. Shackling these folks who can adeptly deal with synthesizing on that level with the a system that discouraged providing context would seem tragic to me. Please don't take any of this to say that I'm totally opposed to influencing user behavior by software design. But doing so is something that is likely as in this case to lead to niche software that doesn't "scale" to other cultures. When your effort to influence shackles some you've gone beyond influencing. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From timeless at myrealbox.com Thu Sep 9 17:43:20 2004 From: timeless at myrealbox.com (timeless) Date: Thu, 09 Sep 2004 10:43:20 -0700 Subject: Joel On Software quote In-Reply-To: References: <414057F4.5060203@mozilla.org> Message-ID: <41409638.7080209@myrealbox.com> Gervase Markham wrote: > Joel believes that cutting down quoting, rather than encouraging it, > is good social interface design :-) i'm not always a fan of joel's, but in this case i have to agree. Christopher Hicks wrote: > Joel is always right for Joel's Universe and Joel is certainly good food > for thought in other universes, but in this case the food leaves me > feeling a bit ill. the use of quoting @bmo makes me feel more than a bit ill. > In the Chicks Universe where I live having people > clued enough to quote makes problems like chat spam nearly nonexistant > and certainly not enough of an issue that anyone has complained in ages. you don't live in my real world. i'll gladly forward the quote garbage from my inbox. it's a flood so believe me you should decline my offer. all garbage is certified as having come from bugzilla-daemon at mozilla.org > Conversations (particularly in terms of bugs) tend to drag in additional > participatings through time and can be somewhat complex. Expecting new > participants to read the whole bug to get up to speed on the issues > works for some folks some of the time, but quoting provides the > opportunity to contextify subsequent comments enough that diving all the > way in isn't absolutely necessary. so send them a link with the relevant items highlighted. you can do this in bonsai, e.g. suppose i wanted to point you to the changes to show_bug.cgi where we moved to using .pm files, i'd just offer: http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/webtools/bugzilla/show_bug.cgi&mark=1.20,1.24,1.26 you could quickly read just the items that mattered, and i wouldn't need to make a checkin into the log which said "interesting modularization changes are:
followed by 10-15 lines quoting all of those lines which are already in the log
. > For instance, there's no reason for > the LDAP admin to need to know or wade through all of the screen layout > niggling that's gone on to answer which LDAP schema we need to work > from. The new bugzilla Reply feature has been very popular and > appreciated in our bugzilla for providing just enough context for > somebody that's newly cc'd into the bug. The concept of forcing people > to wade through and establish their own context instead seems > unnecessarily cruel. In your system it might work, but I'm still waiting for one person who uses bmo to point me to 5 cases where quoting was useful. This is a real invitation. From preed at sigkill.com Thu Sep 9 18:21:48 2004 From: preed at sigkill.com (J. Paul Reed) Date: Thu, 9 Sep 2004 11:21:48 -0700 Subject: Joel On Software quote In-Reply-To: <41409638.7080209@myrealbox.com> References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> Message-ID: <20040909182148.GA25251@sigkill.com> On 09 Sep 2004 at 10:43:20, timeless arranged the bits on my disk to say: > Gervase Markham wrote: > >Joel believes that cutting down quoting, rather than encouraging it, > >is good social interface design :-) > > i'm not always a fan of joel's, but in this case i have to agree. > > Christopher Hicks wrote: > >Joel is always right for Joel's Universe and Joel is certainly good food > >for thought in other universes, but in this case the food leaves me > >feeling a bit ill. > > the use of quoting @bmo makes me feel more than a bit ill. > > >In the Chicks Universe where I live having people > >clued enough to quote makes problems like chat spam nearly nonexistant > >and certainly not enough of an issue that anyone has complained in ages. > > you don't live in my real world. i'll gladly forward the quote garbage > from my inbox. it's a flood so believe me you should decline my offer. > > all garbage is certified as having come from bugzilla-daemon at mozilla.org Am I the only one who finds it amusing that you selectively (and appropriately) quoted the relevant material? You know... so you could respond to it and we'd know what the hell you're talking about? (Yes, you can ignore the irony that I quoted way more material than I was responding to... but I did it on purpose to show the usefulness of your quoting. You would've had to have written two emails to make it entirely clear what you were responding to; alternatively, you could've gone the attribution route, but that can become a huge problem when discussions become heated.) As Chicks said, Joel *always* provides food for thought. Unfortunately, Joel also always thinks Joel's right (huh.... that's a familiar observed trait). And Joel isn't always right, because Joel doesn't always have all of the requirements. "Because Joel said we should" is a really bad reason to do anything. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed Math, my dear boy, is nothing more than the lesbian sister of biology. -- Peter Griffin, Family Guy I use PGP; you should use PGP too... if only to piss off John Ashcroft From myk at mozilla.org Thu Sep 9 22:59:26 2004 From: myk at mozilla.org (Myk Melez) Date: Thu, 09 Sep 2004 15:59:26 -0700 Subject: UI Changes In-Reply-To: <413F5E93.1030900@bugzilla.org> References: <413F5E93.1030900@bugzilla.org> Message-ID: <4140E04E.80406@mozilla.org> David Miller wrote: > What I'm going to do is give Kiko a branch to play on, with a few > conditions on it. We successfully used a branch for the group system > rewrite, and although it is in smaller pieces, this is a similar > magnitude change, so we ought to be able to make it work. Branches are forks, so they're dangerous as well as promising. I'm troubled by this branch, because the recent UI patches I've seen from the branchers (bugs 232659, 251656, 253014) have needed work to land and sometimes included changes I've rejected, some of which have subsequently landed on the branch. The more such changes (whether needing work or rejected) land on the branch, the harder it will be to land pieces of the branch on the trunk, and the less likely it will be to happen. That would be bad for all concerned and most of all for Bugzilla. So bear in mind the following advice for the branch: As with other Bugzilla hacking, keep your patches maximally atomic, making one discrete feature change in each patch. Not only does this prevent controversial or ultimately rejected changes from holding up integration of the rest, it makes iterative integration possible, keeping the trunk and branch in sync as much as possible. Also, keep to current Bugzilla coding standards, or hash out changes on the trunk and on the developers list. It will make integration significantly more complicated if we have to consider changes to Bugzilla coding practice in addition to the functional changes being integrated from the branch. Finally, if you propose changes, whether in discussion or patches, and the changes are rejected, don't land them on the branch. Doing so just makes integrating related and proximate changes harder. -myk From prasad_kadbane at yahoo.co.in Fri Sep 10 11:38:20 2004 From: prasad_kadbane at yahoo.co.in (prasad) Date: Fri, 10 Sep 2004 17:08:20 +0530 Subject: Problem with Graphs in Bugzilla 2.17.4 Message-ID: <4141922C.7050905@yahoo.co.in> Hi , I am having a problem with my instance of Bugzilla. 1. On the Generate Report page(by following the link of Graphical Reports) when i select the horizontal aswell as vertical axis and select Bar or pie then the graphs are not displayed. 2. But in case of Line the Line graph is displayed. 3. But on following either the Bar or pie graph links which are on the page displaying Line graph the appropriate Bar or Pie graphs are displayed properly. 4. one thing i have got and not understood is that the parameters passed to the CGI programs for displaying Bar Graphs in both cases are different. please give me a solution to this problem.......................... From gerv at mozilla.org Fri Sep 10 22:10:57 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 10 Sep 2004 23:10:57 +0100 Subject: Problem with Graphs in Bugzilla 2.17.4 In-Reply-To: <4141922C.7050905@yahoo.co.in> References: <4141922C.7050905@yahoo.co.in> Message-ID: <41422671.2060503@mozilla.org> prasad wrote: > I am having a problem with my instance of Bugzilla. Then you need to be asking in the newsgroup: news://news.mozilla.org/netscape.public.mozilla.webtools . > 1. On the Generate Report page(by following the link of Graphical > Reports) when i select the horizontal aswell as vertical axis and > select Bar or pie then the graphs are not displayed. When you post to the newsgroup, you need to give more detail - e.g. what parameters you are choosing. > 4. one thing i have got and not understood is that the parameters > passed to the CGI programs for displaying Bar Graphs in both cases are > different. When you post to the newsgroup, you need to give examples. Gerv From gerv at mozilla.org Fri Sep 10 22:26:29 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 10 Sep 2004 23:26:29 +0100 Subject: Joel On Software quote In-Reply-To: <20040909182148.GA25251@sigkill.com> References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> Message-ID: <41422A15.2050606@mozilla.org> >>Gervase Markham wrote: >> >>>Joel believes that cutting down quoting, rather than encouraging it, >>>is good social interface design :-) Just to clarify: I brought this up merely because the quoting thing was quite controversial, rather than because I'm grinding an axe. I haven't seen much quoting abuse in b.m.o. - but then, I might not be looking in the right places. J. Paul Reed wrote: > Am I the only one who finds it amusing that you selectively (and > appropriately) quoted the relevant material? > > You know... so you could respond to it and we'd know what the hell you're > talking about? But email is a different medium to bugs. In bugs, all the comments are there in order. In email, the email a person is replying to could be just above it, 50 messages above it, filed in another folder or deleted. Gerv From gerv at mozilla.org Sun Sep 12 16:24:00 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 12 Sep 2004 17:24:00 +0100 Subject: Wrapping HTML in templates In-Reply-To: <4137B356.5080200@myrealbox.com> References: <20040902230453.GC5314@async.com.br> <4137B356.5080200@myrealbox.com> Message-ID: <41447820.3070403@mozilla.org> timeless wrote: > class="file_table" > > > >
References: <20040902230453.GC5314@async.com.br> Message-ID: <41447821.8090104@mozilla.org> Christian Robottom Reis wrote: > So here's a public cry for help that others may enjoy as well: Here's my view :-) Looking at Jouni's, we seem to have a lot in common. > a) How does one wrap a long link which isn't broken by template > statements? > >

Skip all this nonsense, and go back to the query page\n"; Easy - in the middle of the text. > b) How does one wrap a long link which *is* broken by template > statements? > > File / Current practice seems to be to wrap at the beginning of a statement. So: File / > c) How does one wrap a long HTML statement that includes tags > (and therefore doesn't like spurious spacing here and there) such > as: > >
[% collapsed ? '(+)' : '(-)' %] One doesn't wrap such a thing. One does what you suggest: > > > > > > >
[% collapsed ? '(+)' : '(-)' %] > [...] >
... and then wraps the middle as follows:
[% collapsed ? '(+)' : '(-)' %] > I've tended to use the policy: if a large portion of the line isn't > wrappable, don't bother with wrapping smaller parts of it unless it > makes things a lot better. Is that a bad policy? Yes. :-) Tags should always be nested if possible (as in your second example). Then, do your best with what's left. > Note that one alternative is wrapping *inside* tags and TT statements. Evil for TT statements. OK for tags, if you break it up at attribute boundaries and align attributes, like I did above. Gerv From gerv at mozilla.org Sun Sep 12 16:28:54 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 12 Sep 2004 17:28:54 +0100 Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching In-Reply-To: <413D8EE4.5070305@gmx.de> References: <413D8EE4.5070305@gmx.de> Message-ID: <41447946.4060901@mozilla.org> Tobias Burnus wrote: > The question is: Should we change the behaviour of Bugzilla? That is > 'en-gb' should match 'en' (and (?) 'en-*'?). Should this be optional? Or > what is > the right (TM) way to proceed? There certainly shouldn't be an option. We should pick the best algorithm that works with what's out there and use it. My Mozilla has Accept-Language: en-us, en;q=0.5. Which isn't accurate, but then I don't install UK language packs. It does however give both en-xx and en. Does e.g. the German language pack not change it to de-de,de;q=0.5? Whatever, I think that if someone sends de-de and we don't have a de-de but do have a de, we should certainly match that rather than failing or falling back to the default. Makes perfect sense. Gerv From kiko at async.com.br Sun Sep 12 16:46:26 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Sun, 12 Sep 2004 13:46:26 -0300 Subject: Wrapping HTML in templates In-Reply-To: <41447821.8090104@mozilla.org> References: <20040902230453.GC5314@async.com.br> <41447821.8090104@mozilla.org> Message-ID: <20040912164626.GA3487@www.async.com.br> On Sun, Sep 12, 2004 at 05:24:01PM +0100, Gervase Markham wrote: > > [% collapsed ? '(+)' : '(-)' %] > type="checkbox" name="[% file.filename FILTER html %]"[% > > ... and then wraps the middle as follows: > > > [% collapsed ? '(+)' : '(-)' %] This produces different output from the above; compare both and you'll understand why wrapping this isn't as trivial as following a guideline. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From justdave at bugzilla.org Sun Sep 12 21:01:02 2004 From: justdave at bugzilla.org (David Miller) Date: Sun, 12 Sep 2004 17:01:02 -0400 Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching In-Reply-To: <41447946.4060901@mozilla.org> References: <413D8EE4.5070305@gmx.de> <41447946.4060901@mozilla.org> Message-ID: <4144B90E.1030001@bugzilla.org> Gervase Markham wrote: > Whatever, I think that if someone sends de-de and we don't have a de-de > but do have a de, we should certainly match that rather than failing or > falling back to the default. Makes perfect sense. But that's not what the RFC says, and it's not how Apache works for the built-in content-negotiation it can do. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Sun Sep 12 21:21:27 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 12 Sep 2004 22:21:27 +0100 Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching In-Reply-To: <4144B90E.1030001@bugzilla.org> References: <413D8EE4.5070305@gmx.de> <41447946.4060901@mozilla.org> <4144B90E.1030001@bugzilla.org> Message-ID: <4144BDD7.3030304@mozilla.org> David Miller wrote: > But that's not what the RFC says, and it's not how Apache works for the > built-in content-negotiation it can do. But isn't it common-sense? Someone sends: Accept-Language: de-de, fr And we have a choice of de and en, with default as en. What would be the sensible thing to serve them? Looking at it another way, what would break if we made this change? Gerv From justdave at bugzilla.org Sun Sep 12 21:50:56 2004 From: justdave at bugzilla.org (David Miller) Date: Sun, 12 Sep 2004 17:50:56 -0400 Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching In-Reply-To: <4144BDD7.3030304@mozilla.org> References: <413D8EE4.5070305@gmx.de> <41447946.4060901@mozilla.org> <4144B90E.1030001@bugzilla.org> <4144BDD7.3030304@mozilla.org> Message-ID: <4144C4C0.7030802@bugzilla.org> Gervase Markham wrote: > David Miller wrote: > >> But that's not what the RFC says, and it's not how Apache works for >> the built-in content-negotiation it can do. > > But isn't it common-sense? > > Someone sends: > Accept-Language: de-de, fr > > And we have a choice of de and en, with default as en. What would be the > sensible thing to serve them? Going by the RFC (and mimicking Apache's behavior) we would send them en. > Looking at it another way, what would break if we made this change? From RFC 1766: (language identification codes) There is no guaranteed relationship between languages whose tags start out with the same series of subtags; especially, they are NOT guraranteed to be mutually comprehensible, although this will sometimes be the case. In otherwords, we can't depend on the presence of a generic "xx" to be compatible with "xx-yy" RFC 1766 has actually been obsoleted by RFC 3066, which replaced the above paragraph with one identical to the first one I'm quoting from RFC 2616 below. From RFC 2616: (HTTP/1.1) Section 14.4 Note: This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always true that if a user understands a language with a certain tag, then this user will also understand all languages with tags for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case. [....] Note: When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest in such a case to add "en" to get the best matching behavior. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Sun Sep 12 22:28:13 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 12 Sep 2004 23:28:13 +0100 Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching In-Reply-To: <4144C4C0.7030802@bugzilla.org> References: <413D8EE4.5070305@gmx.de> <41447946.4060901@mozilla.org> <4144B90E.1030001@bugzilla.org> <4144BDD7.3030304@mozilla.org> <4144C4C0.7030802@bugzilla.org> Message-ID: <4144CD7D.8000805@mozilla.org> David Miller wrote: > In otherwords, we can't depend on the presence of a generic "xx" to be > compatible with "xx-yy" I can see why they say that, to cover their backs - but surely it is in fact true in 99% of cases? If, as Tobias asserts, there are a bunch of misconfigured clients out there sending only de-de and not de, surely this trumps the possibility that someone sending pt-BR would rather have en than a generic pt? Gerv From tobias.burnus at physik.fu-berlin.de Mon Sep 13 09:50:35 2004 From: tobias.burnus at physik.fu-berlin.de (Tobias Burnus) Date: Mon, 13 Sep 2004 11:50:35 +0200 Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching In-Reply-To: <4144CD7D.8000805@mozilla.org> References: <413D8EE4.5070305@gmx.de> <41447946.4060901@mozilla.org> <4144B90E.1030001@bugzilla.org> <4144BDD7.3030304@mozilla.org> <4144C4C0.7030802@bugzilla.org> <4144CD7D.8000805@mozilla.org> Message-ID: <41456D6B.8060409@physik.fu-berlin.de> Hello, Gervase Markham wrote: > David Miller wrote: > >> In otherwords, we can't depend on the presence of a generic "xx" to >> be compatible with "xx-yy" > > I can see why they say that, to cover their backs - but surely it is > in fact true in 99% of cases? > > If, as Tobias asserts, there are a bunch of misconfigured clients out > there sending only de-de and not de, surely this trumps the > possibility that someone sending pt-BR would rather have en than a > generic pt? I tried Mozilla 1.7.2; when I set the languages to 'de-de','en-gb','fr-fr' it sends only the following: HTTP_ACCEPT_LANGUAGE de-de,en-gb;q=0.7,fr-fr;q=0.3 This is according to RFC -- though it should have asked whether I also want to have de/en/fr. Tobias From chicks at chicks.net Mon Sep 13 14:09:29 2004 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 13 Sep 2004 10:09:29 -0400 (EDT) Subject: Wrapping HTML in templates In-Reply-To: <41447821.8090104@mozilla.org> References: <20040902230453.GC5314@async.com.br> <41447821.8090104@mozilla.org> Message-ID: On Sun, 12 Sep 2004, Gervase Markham wrote: > File / Am I missing something or would this produce a URL with a newline in it? -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From chicks at chicks.net Mon Sep 13 14:11:58 2004 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 13 Sep 2004 10:11:58 -0400 (EDT) Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching In-Reply-To: <4144CD7D.8000805@mozilla.org> References: <413D8EE4.5070305@gmx.de> <41447946.4060901@mozilla.org> <4144B90E.1030001@bugzilla.org> <4144BDD7.3030304@mozilla.org> <4144C4C0.7030802@bugzilla.org> <4144CD7D.8000805@mozilla.org> Message-ID: On Sun, 12 Sep 2004, Gervase Markham wrote: > David Miller wrote: >> In otherwords, we can't depend on the presence of a generic "xx" to be >> compatible with "xx-yy" > > I can see why they say that, to cover their backs - but surely it is in fact > true in 99% of cases? I thought the Intenet Way was to be strict in what you send and liberal in what you accept? > If, as Tobias asserts, there are a bunch of misconfigured clients out > there sending only de-de and not de, surely this trumps the possibility > that someone sending pt-BR would rather have en than a generic pt? Are German client the main problem here? If so can't we make an exception for the wayward German clients and accept de-de as de and leave the rest as is? -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From chicks at chicks.net Mon Sep 13 14:14:39 2004 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 13 Sep 2004 10:14:39 -0400 (EDT) Subject: Joel On Software quote In-Reply-To: <41422A15.2050606@mozilla.org> References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> Message-ID: On Fri, 10 Sep 2004, Gervase Markham wrote: > J. Paul Reed wrote: >> Am I the only one who finds it amusing that you selectively (and >> appropriately) quoted the relevant material? >> >> You know... so you could respond to it and we'd know what the hell you're >> talking about? > > But email is a different medium to bugs. In bugs, all the comments are there > in order. In email, the email a person is replying to could be just above it, > 50 messages above it, filed in another folder or deleted. Yes, but think about a BZ comment that had 20 different minor tweaks that needed to be made to the software. I find it much easier to read the developers response if its interlaced with the 20 points from the end user rather than reading something like "As relates to comment 12 item 3, done. As relates to comment 12 item 4, will be done. As relates to comment 12 item 5, can you clarify whether you want upright widgets or upside down widgets?" -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From kiko at async.com.br Mon Sep 13 14:15:25 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 13 Sep 2004 11:15:25 -0300 Subject: Wrapping HTML in templates In-Reply-To: References: <20040902230453.GC5314@async.com.br> <41447821.8090104@mozilla.org> Message-ID: <20040913141525.GE545@async.com.br> On Mon, Sep 13, 2004 at 10:09:29AM -0400, Christopher Hicks wrote: > On Sun, 12 Sep 2004, Gervase Markham wrote: > >File / > > Am I missing something or would this produce a URL with a newline in it? I *think* TT's PRE_CHOMP (which is active in Bugzilla) will take care of that, but there's an issue with newlines and spacing not behaving as I think it should (but apparently its intentional) that may interfere; testing is golden. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From gerv at mozilla.org Mon Sep 13 15:42:40 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 13 Sep 2004 16:42:40 +0100 Subject: Wrapping HTML in templates In-Reply-To: References: <20040902230453.GC5314@async.com.br> <41447821.8090104@mozilla.org> Message-ID: <4145BFF0.6040803@mozilla.org> Christopher Hicks wrote: > On Sun, 12 Sep 2004, Gervase Markham wrote: > >> File / > > Am I missing something or would this produce a URL with a newline in it? Carefully designed so that PRE_CHOMP means it won't. I don't know what kiko's issue is, but this has always worked fine for me. Gerv From gerv at mozilla.org Mon Sep 13 17:30:16 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 13 Sep 2004 18:30:16 +0100 Subject: Joel On Software quote In-Reply-To: References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> Message-ID: <4145D928.8020804@mozilla.org> Christopher Hicks wrote: > Yes, but think about a BZ comment that had 20 different minor tweaks > that needed to be made to the software. My reaction to that, if each point was separate, would be to trout the user for putting too many issues in the same bug :-) Gerv From chicks at chicks.net Mon Sep 13 19:22:50 2004 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 13 Sep 2004 15:22:50 -0400 (EDT) Subject: quoting, tasks, semantics In-Reply-To: <4145D928.8020804@mozilla.org> References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> <4145D928.8020804@mozilla.org> Message-ID: On Mon, 13 Sep 2004, Gervase Markham wrote: > Christopher Hicks wrote: >> Yes, but think about a BZ comment that had 20 different minor tweaks that >> needed to be made to the software. > > My reaction to that, if each point was separate, would be to trout the user > for putting too many issues in the same bug :-) I understand where you're coming from, but I disagree. The examples that come to mind are cases where we have a bug to write a simple web application. Naturally people don't know what they want until they get what they've already asked for, so there end up being a slew of tweaks. Since I'm getting paid to do this I don't really care how many tweaks they come up with. From a semantic perspective you might consider the tweaks to be bugs in and of themselves, but to me tweaks are to bugs as threads are to processes. In other words, tweaks and tasks are like bugs, but they're light weight and they don't require as much overhead. Practically speaking, expecting folks to make a new bug for every tweak would be ridiculous and a significant overhead for the bug reporter and the developer. It would be nice if bugzilla supported tasks within bugs and this is something we discussed on the mailing list some time ago. (Given my experience trying to get a simple patch accepted I decided not to take on something as big as adding tasks within bugzilla. I still plan to get back to the longdescs primary key issue one of these days.) So I've settled on integrating some web groupware into bugzilla, but I'm not sure which yet. Dicole is the front runner currently. In the mean time, being able to reply to tweak lists using the reply feature and keeping a running list of things to do in the bug comments gets me by. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From gerv at mozilla.org Mon Sep 13 21:04:22 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 13 Sep 2004 22:04:22 +0100 Subject: quoting, tasks, semantics In-Reply-To: References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> <4145D928.8020804@mozilla.org> Message-ID: <41460B56.7010805@mozilla.org> Christopher Hicks wrote: > I understand where you're coming from, but I disagree. > > The examples that come to mind are cases where we have a bug to write a > simple web application. I'd argue if you have a single bug for an entire web application, something's wrong already :-) Regardless, I would close that bug when finished rather than attempt to re-use it for post-release feedback. > Naturally people don't know what they want > until they get what they've already asked for, so there end up being a > slew of tweaks. Since I'm getting paid to do this I don't really care > how many tweaks they come up with. From a semantic perspective you > might consider the tweaks to be bugs in and of themselves, but to me > tweaks are to bugs as threads are to processes. If it's so small that it's not worth filing a bug about, then it can be implemented without discussion after you've seen the comment/got the email. If it requires discussion, then it's worth filing a bug about IMO. Also, getting them to file bugs puts a small barrier in the way, so that only things they care enough about to spend 30 seconds filing a bug report on get into the system. This might eliminate quite a few frivolous requests. > In other words, tweaks > and tasks are like bugs, but they're light weight and they don't require > as much overhead. Practically speaking, expecting folks to make a new > bug for every tweak would be ridiculous and a significant overhead for > the bug reporter and the developer. It depends how good your customised enter_bug.cgi template is. ;-) Gerv From mkgnu at gmx.net Mon Sep 13 21:12:56 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Mon, 13 Sep 2004 14:12:56 -0700 Subject: [ham] Re: quoting, tasks, semantics In-Reply-To: References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> <4145D928.8020804@mozilla.org> Message-ID: <1095109976.3159.79.camel@syd.mkgnu.net> I missed previous discussions on this topic. > as threads are to processes. In other words, tweaks and tasks are like > bugs, but they're light weight and they don't require as much overhead. > Practically speaking, expecting folks to make a new bug for every tweak > would be ridiculous and a significant overhead for the bug reporter and > the developer. I just wanted to mention that I often run across this problem of also having to keep such a list of tweaks. And when the tweaks within a bug cross multiple components (e.g. ComponentA and, almost always, Documentation) I'm unsure what to do. I definitely lose some traceability of which bugs touch which components. Arguably one can add a master "Task" bug with a list of dependencies for its completion, but we may lose some information doing this when producing release documents. I can envision producing a high-level release notes document (from Scmbug) that states "Added Feature A" by looking at Tasks that were implemented between revisions. A lower-level release notes documents can list the list of bugs (or tweaks if you wish) that had to be implemented to complete the Task. Arguably, all of the above can be applied by flagging master Task bugs with a keyword and querying for those (which is what I'm doing now). Just wanted to bring up the point that bugs+tweaks affect how release documents can be automatically produced. From justdave at bugzilla.org Mon Sep 13 22:04:45 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 13 Sep 2004 18:04:45 -0400 Subject: Database Schema chart In-Reply-To: References: <4071F6C4.9060700@bugzilla.org> Message-ID: <4146197D.7080102@bugzilla.org> Shane H. W. Travis wrote: > You may or may not remember me; in April of this year, I contacted you about > the Database Schema chart, and how it was out of date, and would you like me > to update it for you. Well, as life happens, as soon as I promised I would I > got dragged off onto another project for six months, and it completely fell > through the cracks. > > As of late last week, I'm back doing Bugzilla work for the company, and this > is one of the things that I wanted to bang out while I've got bugzilla-time > to spare. My apologies for disappearing off the radar completely; I have > never forgotten that I said I'd do it, though, and it's been bugging me that > I never got it finished. I was wracked with guilt, and would like to make it > up to you now. :) > > I looked through some of the documentation links for bugzilla today, and > found this one: > > http://bugzilla.mozilla.org/show_bug.cgi?id=183216 > > where just last week! you posted a work-in-progress version using dia. As it > happens, I was able to get someone to install dia for me on the main > Bugzilla machine (which is slow as a pregnant pig with about as much > memory). Was a real PITA to open this and work with it, but it could be > done. > > > What I'm wondering, therefore, is: > > a) is someone else already doing this, or was this sort of a raw info dump > on a slightly-slack afternoon? If the former, then I'll thank them and > apologize to you for not getting it done sooner; if the latter, then I'll > try and pick it up and run with it. Yeah, I was in the UK for work last month, and spent the return flight working on that. I haven't had a chance to touch it since, and I'm not aware of anyone else that's said they were going to, so by all means feel free to take it on. :) > b) is this the preferred format (dia)? I ask because I have access to both > corel and visio, either of which could produce better-looking diagrams (and > be a lot easier for me to work with). Dia is *great* for a free tool, but it > does seem rather... primitive. Yeah, Dia is the preferred format, mostly because it is free, and it's easier for the average developer to get their hands on it and update the chart next time we make schema changes. > c) Is this the preferred style? There seems to be a lot more information on > this W-I-P than there was on the 'original' schema -- foreign keys, uniques, > listings of enumerations, etc. That sort of stuff really clutters up the > page, I can tell, but some people may consider it necessary. (If you're > going to do it in Dia, foreign keys probably ARE necessary, since I can't > find a way to make good clean lines to show interconnections between the > tables.) Yeah, it was my intention to draw lines... the generic "square-cornered" lines with arrows on the ends seemed to work best for the couple I tried (there are two or three drawn so far). It will take a lot of rearranging the tables on the document to get the lines to make sense. I just added tables where there was blank space to get all the data entry done. For the immense size of the data on there, it may work best to rearrange the tables into logical areas of functionality, and actually put each functional area on a separate page, and have arrows that need to lead out of that functional area just end in midair saying what they point at (and maybe a short arrow inbound on the other end to point out the reference to it). Functional areas might be: group security (all the xxx_group_map tables), User profiles (profiles and profiles_activity, perhaps mix this with groups if it fits), Bugs (bugs, cc, depends, duplicates, etc), Products (products, components, versions, milestones, etc), and so on. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mkanat at kerio.com Mon Sep 13 22:59:53 2004 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Mon, 13 Sep 2004 15:59:53 -0700 Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching In-Reply-To: <4144C4C0.7030802@bugzilla.org> References: <413D8EE4.5070305@gmx.de> <41447946.4060901@mozilla.org> <4144B90E.1030001@bugzilla.org> <4144BDD7.3030304@mozilla.org> <4144C4C0.7030802@bugzilla.org> Message-ID: <1095116393.24196.99.camel@localhost.localdomain> > Gervase Markham wrote: > > David Miller wrote: > > > >> But that's not what the RFC says, and it's not how Apache works for > >> the built-in content-negotiation it can do. > > > > But isn't it common-sense? > > > > Someone sends: > > Accept-Language: de-de, fr > > > > And we have a choice of de and en, with default as en. What would be the > > sensible thing to serve them? My best guess as to the reasoning behind the RFC has probably to do with Asian languages, where the thing after the dash is incredibly important. For example, as far as I'm aware, there are dialects of Chinese that cannot be read or understood easily by other people who also speak a language called "Chinese." I'm not sure if there are Western languages that have this issue. Still, I would think that it's better to serve the user something that they can at least attempt to use, rather than give them nothing. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From mkanat at kerio.com Mon Sep 13 23:01:21 2004 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Mon, 13 Sep 2004 16:01:21 -0700 Subject: Joel On Software quote In-Reply-To: References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> Message-ID: <1095116480.24196.101.camel@localhost.localdomain> On Mon, 2004-09-13 at 07:14, Christopher Hicks wrote: > Yes, but think about a BZ comment that had 20 different minor tweaks that > needed to be made to the software. I find it much easier to read the > developers response if its interlaced with the 20 points from the end user [snip] I agree. People should quote when it makes sense, and not quote when it doesn't make sense. It's all about whatever makes it easiest for the reader, who is usually an overworked developer. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From mkanat at kerio.com Mon Sep 13 23:05:59 2004 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Mon, 13 Sep 2004 16:05:59 -0700 Subject: Database Schema chart In-Reply-To: <4146197D.7080102@bugzilla.org> References: <4071F6C4.9060700@bugzilla.org> <4146197D.7080102@bugzilla.org> Message-ID: <1095116759.24196.104.camel@localhost.localdomain> On Mon, 2004-09-13 at 15:04, David Miller wrote: > Yeah, Dia is the preferred format, mostly because it is free, and it's > easier for the average developer to get their hands on it and update the > chart next time we make schema changes. You know, I'd say that SVG is the best format, since that can be opened in almost any vector drawing program. For example, I've actually discovered that I prefer OpenOffice Draw 1.1 for my diagrams -- it has the best interface and does everything that I need. I found that it's difficult to make easily printable diagrams in Dia, though it's very easy to make diagrams that are larger than one page (trade-off). -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From gerv at mozilla.org Mon Sep 13 23:07:54 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 14 Sep 2004 00:07:54 +0100 Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching In-Reply-To: <1095116393.24196.99.camel@localhost.localdomain> References: <413D8EE4.5070305@gmx.de> <41447946.4060901@mozilla.org> <4144B90E.1030001@bugzilla.org> <4144BDD7.3030304@mozilla.org> <4144C4C0.7030802@bugzilla.org> <1095116393.24196.99.camel@localhost.localdomain> Message-ID: <4146284A.5060102@mozilla.org> Max Kanat-Alexander wrote: > My best guess as to the reasoning behind the RFC has probably to do > with Asian languages, where the thing after the dash is incredibly > important. For example, as far as I'm aware, there are dialects of > Chinese that cannot be read or understood easily by other people who > also speak a language called "Chinese." In the Chinese case, they all read the same thing - it's the pronunciation which is different between Mandarin and Cantonese. (There may well be a language where your point holds, but Chinese is not it. :-) > Still, I would think that it's better to serve the user something that > they can at least attempt to use, rather than give them nothing. ...or English ;-) Gerv From tobias.burnus at physik.fu-berlin.de Tue Sep 14 08:42:53 2004 From: tobias.burnus at physik.fu-berlin.de (Tobias Burnus) Date: Tue, 14 Sep 2004 10:42:53 +0200 Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching In-Reply-To: <41447946.4060901@mozilla.org> References: <413D8EE4.5070305@gmx.de> <41447946.4060901@mozilla.org> Message-ID: <4146AF0D.40903@physik.fu-berlin.de> Hello, Gervase Markham wrote: > Tobias Burnus wrote: > >> The question is: Should we change the behaviour of Bugzilla? That is >> 'en-gb' should match 'en' (and (?) 'en-*'?). Should this be optional? >> Or what is >> the right (TM) way to proceed? > > There certainly shouldn't be an option. We should pick the best > algorithm that works with what's out there and use it. Well, in principle our algorithm is according to the spec and therefore already the best. > My Mozilla has Accept-Language: en-us, en;q=0.5. Which isn't accurate, > but then I don't install UK language packs. It does however give both > en-xx and en. Does e.g. the German language pack not change it to > de-de,de;q=0.5? Well, I use the English version of Mozilla with the manual setting "de-de","en-gb","fr-fr" and it correctly sends de-de,en-gb;q=0.7,fr-fr;q=0.3. Mozilla didn't asked me whether I would like to have de/en/fr as well. (And I heard that Mozilla 'de-at' sets only "de-at" and not "de-de", but I haven't checked it myself.) > Whatever, I think that if someone sends de-de and we don't have a > de-de but do have a de, we should certainly match that rather than > failing or falling back to the default. Makes perfect sense. i.e. de => ./de-*/, de-de => ./de/ and (of cause) de-de => ./de-de/ and de => ./de/ ? > In the Chinese case, they all read the same thing - it's the > pronunciation which is different between Mandarin and Cantonese. > (There may well be a language where your point holds, but Chinese is > not it. :-) Well, then there are also the long and the short signs (traditional/simplified), I frankly don't know in how far they pose problems, but I'd expect that most Chinese prefer Chinese to English independed of the kind of signs. Tobias From chicks at chicks.net Tue Sep 14 12:34:20 2004 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 14 Sep 2004 08:34:20 -0400 (EDT) Subject: quoting, tasks, semantics In-Reply-To: <41460B56.7010805@mozilla.org> References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> <4145D928.8020804@mozilla.org> <41460B56.7010805@mozilla.org> Message-ID: On Mon, 13 Sep 2004, Gervase Markham wrote: > I'd argue if you have a single bug for an entire web application, something's > wrong already :-) Regardless, I would close that bug when finished rather > than attempt to re-use it for post-release feedback. I did close it and subsequently a few bugs have been opened and closed and one bug has been there for little spelling tweaks and such. The main motivation was that we had reached over 100 comments, some of which went on for a few screens in and of themselves. I understand that it may seem odd to have one bug for an "entire" web application, but in the minds of the people paying the money (who get bills that show time applied to specific bugs) and to me this small web application was "one thing to do", so logically it should mostly be in one bug. > If it's so small that it's not worth filing a bug about, then it can be > implemented without discussion after you've seen the comment/got the > email. If it requires discussion, then it's worth filing a bug about > IMO. You're welcome to that opinion, but given that the user has little way of knowing which tweaks are going to require follow up questions I don't see that it's practical. And in most cases the follow up questions were eventually answered in a simple fashion, so there wasn't a lot of going around and around on the same issue. > Also, getting them to file bugs puts a small barrier in the way, so that > only things they care enough about to spend 30 seconds filing a bug > report on get into the system. This might eliminate quite a few > frivolous requests. Not likely in this case. These folks write the checks that keep the roof over my head, so I'm truly not inclined to discourage their filing of bugs. I have clients that I have to file all the bugs myself and they just get cc'd on the bugs they care about, so having clients that are willing to file stuff directly into bugzilla at all is a godsend to me. [ Would it be wrong for me to point out that you seem to be following Joel's bad example of influencing behavior through software design? ] >> In other words, tweaks and tasks are like bugs, but they're light weight >> and they don't require as much overhead. Practically speaking, expecting >> folks to make a new bug for every tweak would be ridiculous and a >> significant overhead for the bug reporter and the developer. > > It depends how good your customised enter_bug.cgi template is. ;-) To some degree, yes, but mostly no. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From gerv at mozilla.org Tue Sep 14 13:24:22 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 14 Sep 2004 14:24:22 +0100 Subject: quoting, tasks, semantics In-Reply-To: References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> <4145D928.8020804@mozilla.org> <41460B56.7010805@mozilla.org> Message-ID: <4146F106.3000909@mozilla.org> Christopher Hicks wrote: > I understand that it may seem odd to have one bug for an "entire" web > application, but in the minds of the people paying the money (who get > bills that show time applied to specific bugs) and to me this small web > application was "one thing to do", so logically it should mostly be in > one bug. So how about a tracking bug as the "one bug"? I'm sure they'd understand that you need to break a task down into more manageable pieces... > [ Would it be wrong for me to point out that you seem to be following > Joel's bad example of influencing behavior through software design? ] I actually think it's perfectly reasonable to influence behaviour through software design - but perhaps that's another debate. (For example, newsreaders default to putting the user's cursor at the top of a reply to try and prevent them adding "Me too!" to the bottom of 300 lines of quoting.) Anyway, I still think we don't want to try and implement "sub-bugs" in Bugzilla. Because we'll end up with a situation where people want different statuses for the sub-bugs, and other sub-bug specific fields, until you end up almost re-inventing bugs and meta-bugs, just down one level. IMO, the bug should remain the individual unit. If it's too heavyweight for a particular use, the interface can be customised to remove many of the fields. You can track a group of connected bugs using the dependency tree view. Gerv From chicks at chicks.net Wed Sep 15 03:11:59 2004 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 14 Sep 2004 23:11:59 -0400 (EDT) Subject: quoting, tasks, semantics In-Reply-To: <4146F106.3000909@mozilla.org> References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> <4145D928.8020804@mozilla.org> <41460B56.7010805@mozilla.org> <4146F106.3000909@mozilla.org> Message-ID: On Tue, 14 Sep 2004, Gervase Markham wrote: > IMO, the bug should remain the individual unit. If it's too heavyweight for a > particular use, the interface can be customised to remove many of the fields. > You can track a group of connected bugs using the dependency tree view. I once felt that bugs and tasks were semantically similar enough to share the same underlying structure and just have a flag indicating "which kind it is", but the groupware integration I'm imagining would work much smoother if tasks were their own thing. Most of the groupware apps have a task concept on their own. I'm not expecting it to be rocket science to allow a user to create/complete tasks within the groupware or bugzilla. I'll show you the results in a few weeks hopefully. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From mkgnu at gmx.net Wed Sep 15 06:05:20 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Tue, 14 Sep 2004 23:05:20 -0700 Subject: [ham] Re: quoting, tasks, semantics In-Reply-To: References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> <4145D928.8020804@mozilla.org> <41460B56.7010805@mozilla.org> <4146F106.3000909@mozilla.org> Message-ID: <1095227953.1571.5.camel@syd.mkgnu.net> On Tue, 2004-09-14 at 20:11, Christopher Hicks wrote: > On Tue, 14 Sep 2004, Gervase Markham wrote: > > IMO, the bug should remain the individual unit. If it's too heavyweight for a > > particular use, the interface can be customised to remove many of the fields. > > You can track a group of connected bugs using the dependency tree view. > > I once felt that bugs and tasks were semantically similar enough to share > the same underlying structure and just have a flag indicating "which kind > it is", but the groupware integration I'm imagining would work much > smoother if tasks were their own thing. Most of the groupware apps have a > task concept on their own. I'm not expecting it to be rocket science to > allow a user to create/complete tasks within the groupware or bugzilla. > I'll show you the results in a few weeks hopefully. How about proposing to users a convention where task bugs are flagged with a keyword (e.g. TASK or REQ), and have them define custom queries to display tasks. Then a bug can serve both roles, tasks and sub-bugs. And the groupware integration can behave differently when a bug has this keyword set. From kiko at async.com.br Wed Sep 15 19:32:04 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 15 Sep 2004 16:32:04 -0300 Subject: [ham] Re: quoting, tasks, semantics In-Reply-To: <1095227953.1571.5.camel@syd.mkgnu.net> References: <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> <4145D928.8020804@mozilla.org> <41460B56.7010805@mozilla.org> <4146F106.3000909@mozilla.org> <1095227953.1571.5.camel@syd.mkgnu.net> Message-ID: <20040915193204.GD2525@async.com.br> On Tue, Sep 14, 2004 at 11:05:20PM -0700, Kristis Makris wrote: > How about proposing to users a convention where task bugs are flagged > with a keyword (e.g. TASK or REQ), and have them define custom queries > to display tasks. Then a bug can serve both roles, tasks and sub-bugs. > And the groupware integration can behave differently when a bug has this > keyword set. It's my opinion that this really needs a separate field instead of overloading keywords -- something like Issue Type, which can be used to differentiate between categories of issues (bug, enhancement, customer issue, installation problem, etc). OTOH, we know what the policy is towards adding fields to the bugs table. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From justdave at bugzilla.org Thu Sep 16 18:14:03 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 16 Sep 2004 14:14:03 -0400 Subject: Volunteers needed for 2.18rc3 release Message-ID: <4149D7EB.2060203@bugzilla.org> The time has come to get 2.18rc3 out the door, finally! We will also be releasing 2.16.7 and 2.19.1 at the same time, so we'll have three releases going out. But we need a couple major non-code tasks done that most of the core team is too busy to take on right now. If you can help out with any of these items, please give a holler! 1) We need a status update page created to let everyone know what's been going on in the project since we released 2.18rc1. (we never did one for 2.18rc2). There's usually a section where I give a little blurb about roadmap type stuff, which you can just leave space for and I'll add it, but primarily compiling the lists of all the things that have been checked in since the last status update (on all three branches!) and a paragraph or two about each of the new features that have been added on the trunk since then (most of which can be compiled by using the bonsai queries found on http://www.bugzilla.org/status/changes.html ) 2) We need a page designed for the website which gives everything you need to know about creating and editing documentation for Bugzilla. This page should have the following goals in mind: - Make it easy for people to find things that need to be documented. - Make it easy for people to contribute documentation changes even if they don't know how to or don't have the patience to set up DocBook. - Explain how to set up DocBook in case they do have the patience. The "easy to find stuff to document" section should include links to queries into Bugzilla for open bugs in the documentation component of the Bugzilla product, and for resolved bugs in any other component of the Bugzilla product that have the documentation, documentation2.18, or documentation2.16 flags requested. We have three branches of the documentation which are being actively maintained right now, and any changes being made need to be made to any branch it applies to. (2.16, 2.18, and current development) #2 above is important to me. It'd really make my day to be able to release Bugzilla 2.18 with complete documentation, and the best way to make that happen at this point is to get lots of volunteers to help out with it. Volunteers are useless if they don't know what to do, though, so the documentation page should be designed with that primary overall goal in mind. Help the volunteers be able to make themselves useful! :) Then I can include a link to that page in the 2.18rc3 announcement to encourage people to help out. Going along with that, the documentation request flags are a new thing, and it's not as straightforward as a separate bug (but it's a time saver for the people working on code to just tick the box that says "this needs documentation" when they close the bug). Documentation patches can be posted to the same bug as the code. Request review on the patch when it gets posted. We'll need to add a query to the page also that searches for bugs with documentation requested that have patches with review requested, since they won't be as easy to find with the bug being resolved already. If that's all as clear as mud, please help me straighten it out :) Thanks! -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Thu Sep 16 18:23:58 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 16 Sep 2004 14:23:58 -0400 Subject: Volunteers needed for 2.18rc3 release In-Reply-To: <4149D7EB.2060203@bugzilla.org> References: <4149D7EB.2060203@bugzilla.org> Message-ID: <4149DA3E.3020704@bugzilla.org> David Miller wrote: > 1) We need a status update page created to let everyone know what's been > going on in the project since we released 2.18rc1. (we never did one > for 2.18rc2). There's usually a section where I give a little blurb > about roadmap type stuff, which you can just leave space for and I'll > add it, but primarily compiling the lists of all the things that have > been checked in since the last status update (on all three branches!) > and a paragraph or two about each of the new features that have been > added on the trunk since then (most of which can be compiled by using > the bonsai queries found on > http://www.bugzilla.org/status/changes.html ) Examples of previous status updates are at http://www.bugzilla.org/status/ -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From zach at zachlipton.com Thu Sep 16 22:44:57 2004 From: zach at zachlipton.com (Zach Lipton) Date: Thu, 16 Sep 2004 15:44:57 -0700 Subject: Volunteers needed for 2.18rc3 release In-Reply-To: <4149DA3E.3020704@bugzilla.org> References: <4149D7EB.2060203@bugzilla.org> <4149DA3E.3020704@bugzilla.org> Message-ID: <1095374712.24695620@r31.dngr.org> I'd be happy to do the status update (yes I really am alive...). What's the timeframe looking like for the release? --zach (Sent wirelessly from a tiny keyboard, please excuse all typos) On Thu, 16 Sep 2004 11:44am, David Miller wrote: > David Miller wrote: > >> 1) We need a status update page created to let everyone know what's >> been >> going on in the project since we released 2.18rc1. (we never did >> one >> for 2.18rc2). There's usually a section where I give a little blurb >> about roadmap type stuff, which you can just leave space for and >> I'll >> add it, but primarily compiling the lists of all the things that >> have >> been checked in since the last status update (on all three >> branches!) >> and a paragraph or two about each of the new features that have been >> added on the trunk since then (most of which can be compiled by >> using >> the bonsai queries found on >> http://www.bugzilla.org/status/changes.html ) > > Examples of previous status updates are at > http://www.bugzilla.org/status/ > > -- > Dave Miller Project Leader, Bugzilla Bug Tracking System > http://www.justdave.net/ http://www.bugzilla.org/ > - > To view or change your list settings, click here: > From justdave at bugzilla.org Fri Sep 17 03:07:14 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 16 Sep 2004 23:07:14 -0400 Subject: Volunteers needed for 2.18rc3 release In-Reply-To: <1095374712.24695620@r31.dngr.org> References: <4149D7EB.2060203@bugzilla.org> <4149DA3E.3020704@bugzilla.org> <1095374712.24695620@r31.dngr.org> Message-ID: <414A54E2.1010701@bugzilla.org> Zach Lipton wrote: > I'd be happy to do the status update (yes I really am alive...). What's > the timeframe looking like for the release? As soon as the status update and the docs webpage are done. Those are the only things holding it up. :) All the blocker bugs are resolved or waiting for review. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From Kamal.Ahmed at esecurity.net Fri Sep 17 23:47:30 2004 From: Kamal.Ahmed at esecurity.net (Kamal Ahmed) Date: Fri, 17 Sep 2004 19:47:30 -0400 Subject: Change in localconfig resulting in error Message-ID: <5513C07DE400274F9D90FF87B861873F58CA65@va-ex01> Hi, I tried to add a severity in localconfig, and now I am getting the following error: Server error! The server encountered an internal error and was unable to complete your request. Error message: Premature end of script headers: index.cgi If you think this is a server error, please contact the webmaster Error 500 What should I do, please help. I cannot access the bugzilla system. And I am getting in a panic mode. Thanks, -Kamal. From Kamal.Ahmed at esecurity.net Sat Sep 18 00:11:08 2004 From: Kamal.Ahmed at esecurity.net (Kamal Ahmed) Date: Fri, 17 Sep 2004 20:11:08 -0400 Subject: Need Your Help, Please Message-ID: <5513C07DE400274F9D90FF87B861873F58CA67@va-ex01> Dave, I tried to add a severity in localconfig, and now I am getting the following error: I ran ./checksetup.pl after that and got no errors. Server error! The server encountered an internal error and was unable to complete your request. Error message: Premature end of script headers: index.cgi If you think this is a server error, please contact the webmaster Error 500 What should I do, please help. I cannot access the bugzilla system. And I am getting in a panic mode. Thanks, -Kamal. From gerv at mozilla.org Sat Sep 18 11:23:00 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 18 Sep 2004 12:23:00 +0100 Subject: bug 258246: RFC: Accept language header: 'en-gb' and matching In-Reply-To: <4146AF0D.40903@physik.fu-berlin.de> References: <413D8EE4.5070305@gmx.de> <41447946.4060901@mozilla.org> <4146AF0D.40903@physik.fu-berlin.de> Message-ID: <414C1A94.5030209@mozilla.org> Tobias Burnus wrote: > Well, in principle our algorithm is according to the spec and therefore > already the best. Interesting definition of "best" :-) Most web browser implementations de facto partially disagree with this... >> Whatever, I think that if someone sends de-de and we don't have a >> de-de but do have a de, we should certainly match that rather than >> failing or falling back to the default. Makes perfect sense. > > i.e. de => ./de-*/, de-de => ./de/ and (of cause) de-de => ./de-de/ and > de => ./de/ ? If you get de-de, you first try de-de, then de, then fall back. > Well, then there are also the long and the short signs > (traditional/simplified), I frankly don't know in how far they pose > problems, but I'd expect that most Chinese prefer Chinese to English > independed of the kind of signs. I don't think we want to start matching a sent zh-TW against zh-*, e.g. zh-CN. That way does like problems, I agree. But falling de-de back to de (i.e., matching the stem exactly, rather than by prefix) seems reasonable to me. Gerv From gerv at mozilla.org Sat Sep 18 12:15:11 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 18 Sep 2004 13:15:11 +0100 Subject: Change in localconfig resulting in error In-Reply-To: <5513C07DE400274F9D90FF87B861873F58CA65@va-ex01> References: <5513C07DE400274F9D90FF87B861873F58CA65@va-ex01> Message-ID: <414C26CF.7030205@mozilla.org> Kamal Ahmed wrote: > Hi, Hi :-) developers at bugzilla.org is not the place to get Bugzilla support. You are better off asking in the newsgroup: news://news.mozilla.org/netscape.public.mozilla.webtools . > What should I do, please help. I cannot access the bugzilla system. And > I am getting in a panic mode. If you really need to access the system, then undo your change. :-) You did back the file up, right? When you repost your question in .webtools, you will need to be much more specific about exactly what you changed, and say what error appeared in your Apache error log. Gerv From chicks at chicks.net Mon Sep 20 14:31:47 2004 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 20 Sep 2004 10:31:47 -0400 (EDT) Subject: [ham] Re: quoting, tasks, semantics In-Reply-To: <1095227953.1571.5.camel@syd.mkgnu.net> References: <414057F4.5060203@mozilla.org> <41409638.7080209@myrealbox.com> <20040909182148.GA25251@sigkill.com> <41422A15.2050606@mozilla.org> <4145D928.8020804@mozilla.org> <41460B56.7010805@mozilla.org> <4146F106.3000909@mozilla.org> <1095227953.1571.5.camel@syd.mkgnu.net> Message-ID: On Tue, 14 Sep 2004, Kristis Makris wrote: > How about proposing to users a convention where task bugs are flagged > with a keyword (e.g. TASK or REQ), and have them define custom queries > to display tasks. Then a bug can serve both roles, tasks and sub-bugs. > And the groupware integration can behave differently when a bug has this > keyword set. There are several reasons. When I query for "all the bugs in project X" I don't want to have to say "that are actually bugs". When I query for bugs I want to get only bugs back. Something being a bug means something different than something that is a task. I've already got bugs that use a keyword and status white board of "ongoing" so I don't have to make and kill bugs for small tasks, but I still want to be able to bill the .1 to the client. This has saved much trouble, but its also been frustrating because now I have to realize that the ongoing bugs need to be excluded from my query. The other area this already frustrates me is that it affects my bug totals. I like to watch the bug counts go up and down as we work on projects for different clients and clean out the accumulation of "do it when you get around to it" sorts of bugs. Now I have to look at the graph and say, ok that's 10 high because there are these "not quite bugs" in there. The thought of how awful this would be if every bug had 0-n tasks associated with it is just too ugly to imagine. If you don't feel that a bug and a task have different semantic meanings and you don't pay any attention to bug counts over time then treating a task as a new kind of special bug is fine for you. I'm considering implementation methods and bugxula looks like it has lots of potential. Does the bugxula developer happen to be on this list? :) -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From justdave at bugzilla.org Thu Sep 23 05:28:16 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 23 Sep 2004 01:28:16 -0400 Subject: mozilla-webtools support Message-ID: <41525EF0.5030605@bugzilla.org> As lots of people have been trying out the 2.18 release candidates, we've been getting a lot of traffic on mozilla-webtools, and quite frankly, I don't have time to reply to all of it, and I'm assuming that picture is the same for many of the other core developers. There's been a lot of posts to mozilla-webtools going unanswered in the last couple weeks, and the customer support guy in me (I used to answer phone tech support for a living in a prior job) is absolutely hating seeing all the people looking for support and not getting it. I know I've heard that many of the people who read this list (developers) don't read mozilla-webtools because there's too much traffic to keep up with, but if anyone happens to have some time on their hands and is pretty knowledgeable about Bugzilla, feel free to answer some of the posts. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Thu Sep 23 08:37:30 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 23 Sep 2004 09:37:30 +0100 Subject: mozilla-webtools support In-Reply-To: <41525EF0.5030605@bugzilla.org> References: <41525EF0.5030605@bugzilla.org> Message-ID: <41528B4A.3030108@mozilla.org> David Miller wrote: > I know I've heard that many of the people who read this list > (developers) don't read mozilla-webtools because there's too much > traffic to keep up with, but if anyone happens to have some time on > their hands and is pretty knowledgeable about Bugzilla, feel free to > answer some of the posts. I just did a run through and answered quite a few. But I won't support Win32 (no experience), groups (no understanding) or mail problems (on principle). A lot of the questions were similar. We need to look at making a better FAQ, perhaps... Gerv From Brent.Funk at expeditors.com Thu Sep 23 14:01:19 2004 From: Brent.Funk at expeditors.com (Brent.Funk at expeditors.com) Date: Thu, 23 Sep 2004 07:01:19 -0700 Subject: Brent Funk is out of the office. Message-ID: I will be out of the office starting 09/23/2004 and will not return until 09/27/2004. I will respond to your message when I return. From stu at asyn.com Thu Sep 23 14:02:51 2004 From: stu at asyn.com (Stuart Donaldson) Date: Thu, 23 Sep 2004 07:02:51 -0700 Subject: Charting system - Editing series queries Message-ID: <4152D78B.6090108@asyn.com> Is it possible yet to edit the series queries in the new charting system? Or maybe to delete them if you no longer use them? How about copying the series query to a new product? I am upgrading my installation and want to start using the new charting system (very cool by the way!) and I expect some time to tune the queries to what i want. And then I need to be able to apply them to multiple products. Any ideas? Thanks... -Stuart- From bugzilla-developers at sethdaniel.org Thu Sep 23 22:13:34 2004 From: bugzilla-developers at sethdaniel.org (Seth Daniel) Date: Thu, 23 Sep 2004 15:13:34 -0700 Subject: LDAP TLS patch (ref: bug 250916) Message-ID: <20040923221334.GA29982@sethdaniel.org> Hello, I see that there is a bug open for adding LDAP TLS support to the LDAP authentication backend for bugzilla. Is there any traction besides what is in the bugzilla database? (I am guessing not). https://bugzilla.mozilla.org/show_bug.cgi?id=250916 My patch does a bit more than the patch that is currently attached to the above bug. Sometimes the LDAP server will request that the client present a client certificate. If the client does not present a certificate then (depending on the server configuration) the clients request to start tls could be rejected. We are currently using this patch with Bugzilla 2.18rc2 where I work. I would appreciate all the help I can get with this patch and eventually getting TLS support in the Bugzilla release(s). The patch below applies cleanly to CVS HEAD. Thanks. --- Bugzilla/Auth/Verify/LDAP.pm 2004-09-23 16:58:09.000000000 -0700 +++ Bugzilla/Auth/Verify/LDAP.pm.new 2004-09-23 16:58:43.000000000 -0700 @@ -67,6 +67,39 @@ return (AUTH_ERROR, undef, "connect_failed"); } + my $LDAPUseTLS = Param("LDAPUseTLS"); + if ($LDAPUseTLS) { + my %start_tls_opts = (); + + my $LDAPCAPath = Param("LDAPCAPath"); + my $LDAPCAFile = Param("LDAPCAFile"); + if (defined($LDAPCAFile)) { + $start_tls_opts{verify} = 'require'; + $start_tls_opts{cafile} = $LDAPCAFile; + } + elsif (defined($LDAPCAPath)) { + $start_tls_opts{verify} = 'require'; + $start_tls_opts{capath} = $LDAPCAPath; + } + else { + $start_tls_opts{verify} = 'none'; + } + + my $LDAPCertFile = Param("LDAPCertFile"); + if (defined($LDAPCertFile)) { + $start_tls_opts{clientcert} = $LDAPCertFile; + } + + my $LDAPKeyFile = Param("LDAPKeyFile"); + if (defined($LDAPCertFile)) { + $start_tls_opts{clientkey} = $LDAPKeyFile; + } + + if (!$LDAPconn->start_tls(%start_tls_opts)) { + return(AUTH_ERROR, undef, "Unable to start TLS"); + } + } + my $mesg; if (Param("LDAPbinddn")) { my ($LDAPbinddn,$LDAPbindpass) = split(":",Param("LDAPbinddn")); --- defparams.pl 2004-09-23 14:20:14.000000000 -0700 +++ defparams.pl.new 2004-09-23 16:57:19.000000000 -0700 @@ -410,6 +410,47 @@ }, { + name => 'LDAPUseTLS', + desc => 'Use START TLS when connecting to the LDAP server', + type => 'b', + default => '0' + }, + + { + name => 'LDAPCAFile', + desc => 'Full path to CA certificate (only used if LDAPUseTLS is true). ' . + 'Do not set if you use LDAPCAPath.', + type => 't', + default => '' + }, + + { + name => 'LDAPCAPath', + desc => 'Full path to CA certificate directory (only used if LDAPUseTLS ' . + 'is true). Do not set if you use LDAPCAFile.', + type => 't', + default => '' + }, + + { + name => 'LDAPCertFile', + desc => 'Full path to LDAP client certificate (only used if LDAPUseTLS ' . + 'is true). This is only needed if the server requires that the' . + 'client pass a certificate to the server.', + type => 't', + default => '' + }, + + { + name => 'LDAPKeyFile', + desc => 'Full path to LDAP client key (only used if LDAPUseTLS ' . + 'is true). This is only needed if the server requires that the' . + 'client pass a certificate to the server.', + type => 't', + default => '' + }, + + { name => 'LDAPuidattribute', desc => 'The name of the attribute containing the user\'s login name.', type => 't', From chicks at chicks.net Thu Sep 23 23:18:29 2004 From: chicks at chicks.net (Christopher Hicks) Date: Thu, 23 Sep 2004 19:18:29 -0400 (EDT) Subject: Grumpy "Bugzilla" article on OSNews Message-ID: http://osnews.com/story.php?news_id=8361 This is a very bitchy article, but the only reason it mentions bugzilla specifically is because its the most popular OSS bug tracker. The author ("Dennis Heuer, is a 34-years old german social scientist concentrating on human-computer-interaction (HCI) and e-learning.") is complaining about the way people treat bug reporters via bugzilla. Since he's complaining specifically about how bugs have been dealt with on the mozilla project one of you in moz officialdom might want to see if he's full of it or if he's got a valid beef. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From justdave at bugzilla.org Thu Sep 23 23:44:01 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 23 Sep 2004 19:44:01 -0400 Subject: Grumpy "Bugzilla" article on OSNews In-Reply-To: References: Message-ID: <41535FC1.8050206@bugzilla.org> Christopher Hicks wrote: > http://osnews.com/story.php?news_id=8361 > > This is a very bitchy article, but the only reason it mentions bugzilla > specifically is because its the most popular OSS bug tracker. The > author ("Dennis Heuer, is a 34-years old german social scientist > concentrating on human-computer-interaction (HCI) and e-learning.") is > complaining about the way people treat bug reporters via bugzilla. > > Since he's complaining specifically about how bugs have been dealt with > on the mozilla project one of you in moz officialdom might want to see > if he's full of it or if he's got a valid beef. Already been done, many times over. :) Read the reader comments on the bottom of the article. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From chicks at chicks.net Fri Sep 24 01:24:50 2004 From: chicks at chicks.net (Christopher Hicks) Date: Thu, 23 Sep 2004 21:24:50 -0400 (EDT) Subject: Grumpy "Bugzilla" article on OSNews In-Reply-To: <41535FC1.8050206@bugzilla.org> References: <41535FC1.8050206@bugzilla.org> Message-ID: On Thu, 23 Sep 2004, David Miller wrote: > Already been done, many times over. :) Read the reader comments on the > bottom of the article. OMG. Sorry for missing that there were comments. Its a braindead day. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From chicks at chicks.net Fri Sep 24 02:02:27 2004 From: chicks at chicks.net (Christopher Hicks) Date: Thu, 23 Sep 2004 22:02:27 -0400 (EDT) Subject: [cgiapp] Re: Status of upcoming release? In-Reply-To: <4152D039.7050601@yale.edu> References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> Message-ID: On Thu, 23 Sep 2004, Peter Masiar wrote on the cgiapp mailing list: > If you are interested in using SVN, you might be interested also in TRAC: > GPL-ed integrated source code archive, bug/ticket tracking, and wiki. Really > integrated, commit message "fixied bug #123" will close it in bug tracker, > code diff can link to bug description, comment in bug tracker can link to > wiki page, and back. Pretty neat as free software goes. > > http://www.edgewall.com/products/trac/ > > Warning: it's in python. > I am sorry nothing fully integrated like this is available in perl, AFAIK. To me this is a truly sad state of affairs. Trac is a fine example of what can be done on the web these days. It's also lacking real database support, many of the nice features of BZ, and its written in that space-scoped language that has syphoned off a few of Perl's practitioners. But there are still lots of features in Trac that I want, that look very nice, that would make my life as a developer easier, and to the best of my recollection that have been declared beyond the scope of BZ. And I want those features without throwing out bugzilla. So as far as I can tell to get something like this done we need a new project to build a superset of BZ's functionality. Off the top of my head this is what I'm hoping to achieve: - SVN/CVS/Arch integration - source code browser - integrated wiki - links between source code browser, bug tracker, and wiki - tasks - project management - Web, XUL, and SOAP interfaces - server side written Perl (obviously) - checkpoint new comments in progress without posting them - ability to predate comments so that time entries can be added asynchronously to when the work is done (1) Am I right that going in this direction would be counter to the express position of the core devs? (2) Is there anyone out there interested in doing something like this? I've got folks here on staff who I can get to generate the XUL and related JS/CSS to make an attractive mozilla-based client. They all use BZ and share my frustrations to some degree so I don't think it'll take a lot of arm twisting to get a nice interface together. That leaves the SOAP server which I'm happy to do large chunks of and the web interface which I could care less about. (3) What would you like to see in a BZ superset, IDE sort of thing? (4) I recall somebody doing cvs integration and posting about it on the list. Has anyone done something similar for svn? -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From bugzilla at sethdaniel.org Fri Sep 24 02:12:45 2004 From: bugzilla at sethdaniel.org (Seth Daniel) Date: Thu, 23 Sep 2004 19:12:45 -0700 Subject: [cgiapp] Re: Status of upcoming release? In-Reply-To: References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> Message-ID: <20040924021245.GA19776@sethdaniel.org> On Thu, Sep 23, 2004 at 10:02:27PM -0400, Christopher Hicks wrote: > (4) I recall somebody doing cvs integration and posting about it on the > list. Has anyone done something similar for svn? The closest thing I am aware of is SCMbug which is CVS/SVN integration. http://www.public.asu.edu/~makrists/scmbug/ http://freshmeat.net/projects/scmbug/ -- seth / @sethdaniel.org When I was little, I went into a pet shop and they asked how big I'd get. From mkgnu at gmx.net Fri Sep 24 05:20:06 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Thu, 23 Sep 2004 22:20:06 -0700 Subject: [ham] Re: [cgiapp] Re: Status of upcoming release? In-Reply-To: <20040924021245.GA19776@sethdaniel.org> References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> <20040924021245.GA19776@sethdaniel.org> Message-ID: <1096003206.32636.18.camel@syd.mkgnu.net> On Thu, 2004-09-23 at 19:12, Seth Daniel wrote: > On Thu, Sep 23, 2004 at 10:02:27PM -0400, Christopher Hicks wrote: > > (4) I recall somebody doing cvs integration and posting about it on the > > list. Has anyone done something similar for svn? > > The closest thing I am aware of is SCMbug which is CVS/SVN integration. > > http://www.public.asu.edu/~makrists/scmbug/ > http://freshmeat.net/projects/scmbug/ I have Arch integration planned too, after a version description document generator is implemented and, inherently, a few things are redesigned. I see value in autogenerating release documents by running a script, rather than manually draft those each time. There are some limitations in existing SCM systems(CVS mostly) that make this difficult to handle generically at the moment (specifically http://bugzilla.mkgnu.net/show_bug.cgi?id=436). SCM systems need to become a little more aware of the need for integration. But so do bug-trackers; specifically providing a field that stores the SCM username to assist in an SCM to bug-tracker username translation. From bugzilla at sethdaniel.org Fri Sep 24 02:12:45 2004 From: bugzilla at sethdaniel.org (Seth Daniel) Date: Thu, 23 Sep 2004 19:12:45 -0700 Subject: [cgiapp] Re: Status of upcoming release? In-Reply-To: References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> Message-ID: <20040924021245.GA19776@sethdaniel.org> On Thu, Sep 23, 2004 at 10:02:27PM -0400, Christopher Hicks wrote: > (4) I recall somebody doing cvs integration and posting about it on the > list. Has anyone done something similar for svn? The closest thing I am aware of is SCMbug which is CVS/SVN integration. http://www.public.asu.edu/~makrists/scmbug/ http://freshmeat.net/projects/scmbug/ -- seth / @sethdaniel.org When I was little, I went into a pet shop and they asked how big I'd get. - To view or change your list settings, click here: From mkanat at kerio.com Fri Sep 24 14:12:20 2004 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Fri, 24 Sep 2004 07:12:20 -0700 Subject: Significant Enhancements to Bugzilla (WAS Re: [cgiapp] Re: Status of upcoming release?) In-Reply-To: References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> Message-ID: <1096035140.7310.5.camel@max.localdomain> On Thu, 2004-09-23 at 19:02, Christopher Hicks wrote: > [snip] I want > those features without throwing out bugzilla. So as far as I can tell to > get something like this done we need a new project to build a superset of > BZ's functionality. [snip] I'd also like a lot of those features that you mentioned. Of course, I think: (1) It's important not to violate the Unix Philosophy. One Tool, One Use. There are all sorts of good reasons for this philosophy, proven over many decades. Of course, there's nothing wrong with throwing together a lot of tools and integrating them well. (2) We already can't get enough developers and reviewers just to code the features that people want in a *bugtracker*. If we 10x the project, where are we going to get all those developers? Perhaps we could get them for a little bit off the initial excitement, but still, it's important to have people stick around for the long-term and maintain their code, more than a year. -Max From peter.masiar at yale.edu Fri Sep 24 14:11:56 2004 From: peter.masiar at yale.edu (Peter Masiar) Date: Fri, 24 Sep 2004 10:11:56 -0400 Subject: [cgiapp] SVN with integrated bug tracker Was: Status of upcoming release? In-Reply-To: References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> Message-ID: <41542B2C.8020201@yale.edu> Christopher Hicks wrote: > On Thu, 23 Sep 2004, Peter Masiar wrote on the cgiapp mailing list: > >> If you are interested in using SVN, you might be interested also in >> TRAC: GPL-ed integrated source code archive, bug/ticket tracking, and >> wiki. Really integrated, commit message "fixied bug #123" will close >> it in bug tracker, code diff can link to bug description, comment in >> bug tracker can link to wiki page, and back. Pretty neat as free >> software goes. >> >> http://www.edgewall.com/products/trac/ >> >> Warning: it's in python. >> I am sorry nothing fully integrated like this is available in perl, >> AFAIK. > > To me this is a truly sad state of affairs. Trac is a fine example of > what can be done on the web these days. Another similar project is GForge, GPL fork of SourceForge. In PHP. Basically both PHP and python have 'integrated project repository' app which every software shop needs, as a start of hacking - but perl community as usual tries TIMTOWDI. If this 'integrated bug tracker' was C::A based, it would be smart way to sneak C::A to perl shops. > It's also lacking real database > support, many of the nice features of BZ, and its written in that > space-scoped language that has syphoned off a few of Perl's > practitioners. But there are still lots of features in Trac that I want, > that look very nice, that would make my life as a developer easier, and > to the best of my recollection that have been declared beyond the scope > of BZ. Does it mean developing new BZ+, based on C::A framework? > And I want those features without throwing out bugzilla. So as > far as I can tell to get something like this done we need a new project > to build a superset of BZ's functionality. > > Off the top of my head this is what I'm hoping to achieve: > > - SVN/CVS/Arch integration I would go for SVN first. CVS is past, and Arch has different philosophy (is distributed). SVN server is central code repository, and natural place for central bug tracking database and wiki with project docs. > - source code browser > - integrated wiki There was (a year ago) one project in East Asia (IIRC Taiwan), using RT bug tracker framework and Kwiki wiki engine, but then they had all docs in chinese - then :-( Kwiki rather easy to install and was simple in previous version, but it's not using CGI:App based framework. But I heard Kwiki author, Ingy, is from Portland and a friend of Ward Cunningham, of the first wiki fame. Thay want to implement FIT test framework into Kwiki. Ingy is also paid to work FT on wikis for Social Text. I also prefer wiki which stores page as text files (with metadata if needed), and not in database. Because if you have SVN, why not to use it for keeping track of versions of wiki pages, right? As a fact, I'll suggest to for every project to have *two wikis* (1) technical docs, meeting notes, XP iterations and what you have (2) second separate wiki with user's help pages - web-based help is IMHO natural for web-based apps. > - links between source code browser, bug tracker, and wiki Exactly. Very important. So ie you can enter wiki markup [[bug:1234]] in code comments, and it will be linked to hyperlink to a bug number 1234 in BZ when viewed in code browser. IIRC there was perl-based CVS viever, but it is obsolete now and viewCVS is standard - again python-based. :-( > - tasks > - project management Twiki has plugins for XP-style project management, GPL-ed ideas can be stolen, but Twiki codebase is a mess. Also GForge handles projects, with graphs and all. > - Web, XUL, and SOAP interfaces > - server side written Perl (obviously) > - checkpoint new comments in progress without posting them > - ability to predate comments so that time entries can be added > asynchronously to when the work is done Not sure about usecases for this functionality. Will page versions in wiki be enough for this? > (1) Am I right that going in this direction would be counter to the > express position of the core devs? Code devs of what package? Bugzilla? Trac? Kwiki? C::A? > (2) Is there anyone out there interested in doing something like this? I am. But I am already spread way too thin. :-( Again, this kind of package would be IMHO a great way to promote C::A framework. But it is much more work that just creating C::A based wiki, and wiki as example of C::A based app was rejected on the list before - but times, people, and opinions can change? :-) > I've got folks here on staff who I can get to generate the XUL and > related JS/CSS to make an attractive mozilla-based client. They all use > BZ and share my frustrations to some degree so I don't think it'll take > a lot of arm twisting to get a nice interface together. That leaves the > SOAP server which I'm happy to do large chunks of and the web interface > which I could care less about. > > (3) What would you like to see in a BZ superset, IDE sort of thing? > > (4) I recall somebody doing cvs integration and posting about it on the > list. Has anyone done something similar for svn? > -- Peter Masiar From jpyeron at pdinc.us Fri Sep 24 16:26:51 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Fri, 24 Sep 2004 12:26:51 -0400 (EDT) Subject: cvs commit tracking??? Message-ID: I feel silly, but is there an easy way to track bz cvs commits? (file,version)[] msg we have too many patches against BZ to track by hand any more. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager #1 2739 Saint Paul Street - - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From slamm at yahoo-inc.com Fri Sep 24 16:37:47 2004 From: slamm at yahoo-inc.com (Steve Lamm) Date: Fri, 24 Sep 2004 09:37:47 -0700 Subject: cvs commit tracking??? In-Reply-To: References: Message-ID: <20040924163747.GN12975@yahoo-inc.com> On 24/09/04 12:26 -0400, Jason Pyeron wrote: > > > I feel silly, but is there an easy way to track bz cvs commits? Jud Dagnall recently added a feature for this. If you add something like "[bug 12345]" to a cvs commit message, cvs will automatically add a comment to that bug (same message that cvs emails for commit notifications). You can even fix bugs by including "[fix bug 12345]". -slamm > > > (file,version)[] > msg > > > we have too many patches against BZ to track by hand any more. > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > - - > - Jason Pyeron PD Inc. http://www.pdinc.us - > - Partner & Sr. Manager #1 2739 Saint Paul Street - > - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - > - - > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you > have received it in error, purge the message from your system and > notify the sender immediately. Any other use of the email by you > is prohibited. > > > > - > To view or change your list settings, click here: > > From kiko at async.com.br Fri Sep 24 16:38:35 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 24 Sep 2004 13:38:35 -0300 Subject: cvs commit tracking??? In-Reply-To: References: Message-ID: <20040924163835.GE706@async.com.br> On Fri, Sep 24, 2004 at 12:26:51PM -0400, Jason Pyeron wrote: > I feel silly, but is there an easy way to track bz cvs commits? I don't know exactly what you mean. You can look at bonsai and tinderbox, and cvsps lets you groups CVS checkins into patchsets. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From micklweiss at gmx.net Fri Sep 24 16:40:13 2004 From: micklweiss at gmx.net (Mick Weiss) Date: Fri, 24 Sep 2004 12:40:13 -0400 Subject: cvs commit tracking??? In-Reply-To: References: Message-ID: <41544DED.8030901@gmx.net> Jason Pyeron wrote: > > I feel silly, but is there an easy way to track bz cvs commits? > > > (file,version)[] > msg > > > we have too many patches against BZ to track by hand any more. > > Why not Bonsai? For instance, all changes that were made in the last day: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=Bugzilla&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=day&mindate=&maxdate=&cvsroot=%2Fcvsroot Or were you looking for something else? Best Regards, - Mick (o> Web / software developer ( ) UNIX Systems Admin --- ~ www.mickweiss.com ~ From slamm at yahoo-inc.com Fri Sep 24 17:24:27 2004 From: slamm at yahoo-inc.com (Steve Lamm) Date: Fri, 24 Sep 2004 10:24:27 -0700 Subject: cvs commit tracking??? In-Reply-To: <20040924163747.GN12975@yahoo-inc.com> References: <20040924163747.GN12975@yahoo-inc.com> Message-ID: <20040924172427.GA10704@yahoo-inc.com> On 24/09/04 09:37 -0700, Steve Lamm wrote: > On 24/09/04 12:26 -0400, Jason Pyeron wrote: > > > > > > I feel silly, but is there an easy way to track bz cvs commits? I feel silly now too. My ealier response assumed that you worked at Yahoo! and that you were writing to one of our internal mailing lists. -slamm From kiko at async.com.br Fri Sep 24 17:29:27 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 24 Sep 2004 14:29:27 -0300 Subject: cvs commit tracking??? In-Reply-To: <20040924172427.GA10704@yahoo-inc.com> References: <20040924163747.GN12975@yahoo-inc.com> <20040924172427.GA10704@yahoo-inc.com> Message-ID: <20040924172927.GG706@async.com.br> On Fri, Sep 24, 2004 at 10:24:27AM -0700, Steve Lamm wrote: > On 24/09/04 09:37 -0700, Steve Lamm wrote: > > On 24/09/04 12:26 -0400, Jason Pyeron wrote: > > > > > > > > > I feel silly, but is there an easy way to track bz cvs commits? > > I feel silly now too. My ealier response assumed that you worked > at Yahoo! and that you were writing to one of our internal mailing > lists. It's too late now. We want to see your patches . Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From chicks at chicks.net Fri Sep 24 17:55:10 2004 From: chicks at chicks.net (Christopher Hicks) Date: Fri, 24 Sep 2004 13:55:10 -0400 (EDT) Subject: [cgiapp]/[devs.bz] SVN with integrated bug tracker In-Reply-To: <41542B2C.8020201@yale.edu> References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> <41542B2C.8020201@yale.edu> Message-ID: [this thread was started on the bz mailing list after a discussion on the cgiapp mailing list. For those folks on the cgiapp mailing list getting cc'd on this for the first time, check out http://bugzilla.org/cgi-bin/mj_wwwusr?user=&passw=&list=developers&brief=on&func=archive-get-part&extra=200409/85 to get caught up.] On Fri, 24 Sep 2004, Peter Masiar wrote: > Another similar project is GForge, GPL fork of SourceForge. In PHP. I've not looked at it recently. Does anybody have any experience with it? I'm willing to consider any features that people would like to see eventually. But one of my sincere motivations is to end up with a pure Perl solution eventually. So if GForge would be a good place to start in terms of database design or features, we could use pieces of it while we're building other things. We don't have to be pure perl from the beginning. But we'd need somebody willing to code in PHP to smooth over the rough edges in the mean time. > Basically both PHP and python have 'integrated project repository' app > which every software shop needs, as a start of hacking - but perl > community as usual tries TIMTOWDI. If this 'integrated bug tracker' was > C::A based, it would be smart way to sneak C::A to perl shops. Yes, but at least personally I'm more interested in pushing Apache::ASP out into the world. But if you're willing to step up and do the web portion of things I'm certainly happy enough to leave such decisions to you. > Does it mean developing new BZ+, based on C::A framework? Nothing is set in concrete yet. >> And I want those features without throwing out bugzilla. So as far as I >> can tell to get something like this done we need a new project to build a >> superset of BZ's functionality. >> >> Off the top of my head this is what I'm hoping to achieve: >> >> - SVN/CVS/Arch integration > > I would go for SVN first. CVS is past, and Arch has different philosophy (is > distributed). SVN server is central code repository, and natural place for > central bug tracking database and wiki with project docs. We're on the same page here. >> - source code browser >> - integrated wiki > > There was (a year ago) one project in East Asia (IIRC Taiwan), using RT > bug tracker framework and Kwiki wiki engine, but then they had all docs > in chinese - then :-( Personally I'm leaning toward TWiki, but I'm not a wiki afficianado except for occassionally using wikipedia, so I'm very open to suggestions here. > Kwiki rather easy to install and was simple in previous version, but > it's not using CGI:App based framework. But I heard Kwiki author, Ingy, > is from Portland and a friend of Ward Cunningham, of the first wiki > fame. Thay want to implement FIT test framework into Kwiki. Ingy is also > paid to work FT on wikis for Social Text. Sounds cool. > I also prefer wiki which stores page as text files (with metadata if > needed), and not in database. Agreed. > Because if you have SVN, why not to use it for keeping track of versions > of wiki pages, right? Absolutely. > As a fact, I'll suggest to for every project to have *two wikis* > (1) technical docs, meeting notes, XP iterations and what you have > (2) second separate wiki with user's help pages - web-based help is IMHO > natural for web-based apps. Yes, yes, yes. >> - links between source code browser, bug tracker, and wiki > > Exactly. Very important. > > So ie you can enter wiki markup [[bug:1234]] in code comments, and it will be > linked to hyperlink to a bug number 1234 in BZ when viewed in code browser. !!! :) > IIRC there was perl-based CVS viever, but it is obsolete now and viewCVS is > standard - again python-based. :-( cvsmonitor is nice as well. >> - tasks >> - project management > > Twiki has plugins for XP-style project management, GPL-ed ideas can be > stolen, but Twiki codebase is a mess. If Twiki does what we want in most respects that would prevent it from being a stop gap. I wasn't impressed with the layout of how stuff got installed if you followed the instructions, but I didn't see anything else that horrified me when I installed it, but that was a year ago. > Also GForge handles projects, with graphs and all. [In neanderthal man voice.] Want more graphs to print on color printer! I've never felt the sourceforge graphs were anything beyond functional. That's an area that BZ does better about in the areas that BZ graphs. >> - Web, XUL, and SOAP interfaces >> - server side written Perl (obviously) >> - checkpoint new comments in progress without posting them >> - ability to predate comments so that time entries can be added >> asynchronously to when the work is done > > Not sure about usecases for this functionality. Will page versions in wiki be > enough for this? Maybe. The use case is that if somebody is on site and putting time and notes into a PDA then it may be a few days before that gets transferred into bugzilla. For purposes of billing being able to have the "effective primary date of the note" be different than the "actual real time that bugzilla ended up with the note" would make life much easier. My only grief with using BZ for billing is this precise issue. I'll be happy to throw that code into the stone soup naturally. >> (1) Am I right that going in this direction would be counter to the >> express position of the core devs? > > Code devs of what package? Bugzilla? Trac? Kwiki? C::A? Bugzilla. >> (2) Is there anyone out there interested in doing something like this? > > I am. But I am already spread way too thin. :-( Then we may be stuck with a Moz client or Apache::ASP! :) > Again, this kind of package would be IMHO a great way to promote C::A > framework. I agree. I've done a few projects in C::A and I liked it. For doing development on this scale I much prefer Apache::ASP though. > But it is much more work that just creating C::A based wiki, and wiki as > example of C::A based app was rejected on the list before - but times, > people, and opinions can change? :-) Its a matter of someone being willing to take the time to code it. But yes, it would be great for the community. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From jpyeron at pdinc.us Fri Sep 24 18:11:11 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Fri, 24 Sep 2004 14:11:11 -0400 (EDT) Subject: Need to receive notice when cvs-mirror.mozilla.org has a checkin was: cvs commit tracking??? In-Reply-To: <20040924172927.GG706@async.com.br> Message-ID: I'm sorry. I meant that I need to receive notice when someone submits a patch to the mozilla's cvs. -jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager #1 2739 Saint Paul Street - - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From justdave at bugzilla.org Fri Sep 24 18:33:37 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 24 Sep 2004 14:33:37 -0400 Subject: Need to receive notice when cvs-mirror.mozilla.org has a checkin In-Reply-To: References: Message-ID: <41546881.7020903@bugzilla.org> Jason Pyeron wrote: > I meant that I need to receive notice when someone submits a patch to the > mozilla's cvs. We actually have a read-only mailing list that all the commit messages get posted to. Bet that's exactly what you're looking for. :) http://bugzilla.org/cgi-bin/mj_wwwusr?func=lists-long-full&extra=cvs-checkins -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From jpyeron at pdinc.us Fri Sep 24 18:48:58 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Fri, 24 Sep 2004 14:48:58 -0400 (EDT) Subject: Need to receive notice when cvs-mirror.mozilla.org has a checkin In-Reply-To: <41546881.7020903@bugzilla.org> Message-ID: is there an archive for this list? On Fri, 24 Sep 2004, David Miller wrote: Jason Pyeron wrote: > I meant that I need to receive notice when someone submits a patch to the > mozilla's cvs. We actually have a read-only mailing list that all the commit messages get posted to. Bet that's exactly what you're looking for. :) http://bugzilla.org/cgi-bin/mj_wwwusr?func=lists-long-full&extra=cvs-checkins -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager #1 2739 Saint Paul Street - - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From micklweiss at gmx.net Fri Sep 24 18:56:27 2004 From: micklweiss at gmx.net (Mick Weiss) Date: Fri, 24 Sep 2004 14:56:27 -0400 Subject: Need to receive notice when cvs-mirror.mozilla.org has a checkin In-Reply-To: References: Message-ID: <41546DDB.3050703@gmx.net> Jason Pyeron wrote: > > is there an archive for this list? > > > On Fri, 24 Sep 2004, David Miller wrote: > > Jason Pyeron wrote: > > >>I meant that I need to receive notice when someone submits a patch to the >>mozilla's cvs. > > > We actually have a read-only mailing list that all the commit messages > get posted to. Bet that's exactly what you're looking for. :) > > http://bugzilla.org/cgi-bin/mj_wwwusr?func=lists-long-full&extra=cvs-checkins > > > Jason, For that, just use Bonsai. Best Regards, - Mick (o> Web / software developer ( ) UNIX Systems Admin --- ~ www.mickweiss.com ~ From jpyeron at pdinc.us Fri Sep 24 19:16:33 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Fri, 24 Sep 2004 15:16:33 -0400 (EDT) Subject: Need to receive notice when cvs-mirror.mozilla.org has a checkin In-Reply-To: <41546DDB.3050703@gmx.net> Message-ID: I am trying to make an automated script based on checkins. I will need to parse the format. To do that I will need "examples" or as an alternative the source for the script which mails... any know where to find that? On Fri, 24 Sep 2004, Mick Weiss wrote: Jason Pyeron wrote: > > is there an archive for this list? > Jason, For that, just use Bonsai. Best Regards, -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager #1 2739 Saint Paul Street - - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From justdave at bugzilla.org Fri Sep 24 19:26:30 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 24 Sep 2004 15:26:30 -0400 Subject: Need to receive notice when cvs-mirror.mozilla.org has a checkin In-Reply-To: References: Message-ID: <415474E6.4070806@bugzilla.org> Jason Pyeron wrote: > is there an archive for this list? Yes, it should be linked to from the same page, but looking at it now, I see that it isn't. There *is* an example message in the FAQ for the list though. I'll go fiddle with the settings and see if I can make the archive work... okay, all fixed. should be a "Message Archive" link on there now. > On Fri, 24 Sep 2004, David Miller wrote: > > http://bugzilla.org/cgi-bin/mj_wwwusr?func=lists-long-full&extra=cvs-checkins -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From micklweiss at gmx.net Fri Sep 24 19:32:28 2004 From: micklweiss at gmx.net (Mick Weiss) Date: Fri, 24 Sep 2004 15:32:28 -0400 Subject: Need to receive notice when cvs-mirror.mozilla.org has a checkin In-Reply-To: References: Message-ID: <4154764C.6020205@gmx.net> Jason Pyeron wrote: > I am trying to make an automated script based on checkins. > I will need to parse the format. > To do that I will need "examples" > > or as an alternative the source for the script which mails... > any know where to find that? > > On Fri, 24 Sep 2004, Mick Weiss wrote: > > Jason Pyeron wrote: > >>is there an archive for this list? >> > > > Jason, > > For that, just use Bonsai. > > Best Regards, > > What is this script supposed to do? Perhaps it has already been done? You could get the info from bonsai and write some perl to mess with it. Thats not too hard to accomplish. - Mick (o> Web / software developer ( ) UNIX Systems Admin --- ~ www.mickweiss.com ~ From travis at SEDSystems.ca Fri Sep 24 18:31:10 2004 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Fri, 24 Sep 2004 12:31:10 -0600 (CST) Subject: {Virus?} Re: Database Schema chart In-Reply-To: <4146197D.7080102@bugzilla.org> References: <4071F6C4.9060700@bugzilla.org> <4146197D.7080102@bugzilla.org> Message-ID: Warning: This message has had one or more attachments removed Warning: (bugzilla.zip). Warning: Please read the "Syndicomm-Attachment-Warning.txt" attachment(s) for more information. On Mon, 13 Sep 2004, David Miller wrote: > > What I'm wondering, therefore, is: > > > > a) is someone else already doing this > > I'm not aware of anyone else that's said they were going to, so by all > means feel free to take it on. :) Okay... so I did, and it's done. Took longer than I'd though (both from when I originally promised it in March, and from when I said again I'd do it now) but there's something finished now. Not quite what you were hoping for (see below) but I hope it'll do. > > b) is this the preferred format (dia)? I ask because I have access to both > > corel and visio, either of which could produce better-looking diagrams (and > > be a lot easier for me to work with). Dia is *great* for a free tool, but it > > does seem rather... primitive. > > Yeah, Dia is the preferred format, mostly because it is free, and it's > easier for the average developer to get their hands on it and update the > chart next time we make schema changes. Okay. I tried working with dia... I really did. I just couldn't finish with it, though, because the whole thing was just looking so damn *ugly* and I felt like I was trying to sew with mittens on. I don't do a lot of diagram work any more, but when I do I like things to look just so... so I picked up the half-finished job I'd done on the 2.16 schema in CorelDraw and finished it. The result is attached to this document as a zip in three different formats: * Original corel draw document, so that you've got a copy. (You told me that all you guys had was the .jpg from the last schema diagram.) * 1-to-1 size .jpg with standard compression: original filesize of 8MB, 'shrunk' to 2MB. This is a high-res image from the .cdr file that you can play with for importing/exporting. * The results of a generic 'publish to the web' sort of wizard inside Corel Draw: one .html file and a directory of images. As I said, this is schema for 2.16; I know that it's rather late to be doing this, but it's where I started and it's what I understand. (I haven't been following the 2.17/2.18 progression much at all, so I don't grok the pattern of what's been added and how it inter-relates just yet. I figured that this would get me back in the game, and be a good starting point for me for 2.18... or if I end up having to ditch again, at least you're further ahead than you were. What I'd like before going on to 2.18 is some constructive criticism on the results. I know what I did isn't how you had it laid out; it more mirrors the schema diagrams done for 2.14 and before. That was intentional; your initial diagrams had a great deal of information on them, but it was a tad overwhelming and confusing. I thought that this was clear without being (too) cluttered, and was able to convey the relationships well. I'd like you to tell me what's important to you, though. If you really really REALLY want all those enum-listings, foreign keys, unique, multiple, etc. on the schema chart, let me know and I'll see what I can do to work it in. Basically, provide me with some feedback that I can use to start working with 2.18 (Should I have posted this to the appropriate log item too? I'm really not used to working with open source projects, so I tend to interact with one person better... but if there's a right and wrong way of doing stuff like this please let me know and I'll work on following procedure.) > For the immense size of the data on there, it may work best to rearrange > the tables into logical areas of functionality, and actually put each > functional area on a separate page... I'm quite pleased that I was able to get all of 2.16 on a single page, but I have no such illusions that I'll be able to do so with 2.18 without shrinking it to unreadability... so yeah, split across two pages would probably do it. Once I have some feedback on this (the image, the process, anything) I'll start working on 2.18. Since I've got a pretty hefty base to start from now (lots of learned/re-learned skills in doing the 2.16 one, and most of the tables haven't changed that much since 2.16) it should be a relatively painless process to update it. Sincerely; Shane Travis | Physics is like sex. Sure, it may give some travis at sedsystems.ca | practical results, but that's not why we Saskatoon, Saskatchewan | do it. -- Richard Feynman -------------- next part -------------- This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "bugzilla.zip" is on the list of unacceptable attachments for this site and has been replaced by this warning message. If you wish to receive a copy of the original email, please visit http://www.syndicomm.com/service/ and choose the "Email problem" selection. Please state in your request that you want the original mail to be delivered, and include the lines between the --BEGIN-- and --END-- markings below in your request. --BEGIN-- At Fri Sep 24 11:40:42 2004 the virus scanner said: MailScanner: Too many masquerading viruses in Zip files. Syndicomm will never send official communication with attached files. (bugzilla.zip) Quarantine Message ID: sinclair:20040924/i8OIdELn004891 --END-- -- Postmaster MailScanner thanks transtec Computers for their support From jpyeron at pdinc.us Fri Sep 24 20:14:09 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Fri, 24 Sep 2004 16:14:09 -0400 (EDT) Subject: Need to receive notice when cvs-mirror.mozilla.org has a checkin In-Reply-To: <4154764C.6020205@gmx.net> Message-ID: We have many patches against BZ, we dont want them to bitrot, but due to budget constraints, we cannot check them as often as we like. We have a semi automated way of checking against bitrot, and just relying on cvs up to spew C's is not going to work as a substitute. Now that we have all our patches organized with some meta data and test cases, all we need is to run the procedures when the file changes, and post a needs review note to our developers. can bonsai push? can bonsai tell me that cvs ci file1 file2 file3? we need the simplest of information: file, rev file, rev file, rev On Fri, 24 Sep 2004, Mick Weiss wrote: > > I am trying to make an automated script based on checkins. > > I will need to parse the format. > > To do that I will need "examples" > > > > Jason, > > > > For that, just use Bonsai. > > > > Best Regards, > > > > > > What is this script supposed to do? Perhaps it has already been done? > You could get the info from bonsai and write some perl to mess with it. > > Thats not too hard to accomplish. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager #1 2739 Saint Paul Street - - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From jpyeron at pdinc.us Fri Sep 24 20:16:11 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Fri, 24 Sep 2004 16:16:11 -0400 (EDT) Subject: {Virus?} Re: Database Schema chart In-Reply-To: Message-ID: On Fri, 24 Sep 2004, Shane H. W. Travis wrote: >Warning: This message has had one or more attachments removed >Warning: (bugzilla.zip). >Warning: Please read the "Syndicomm-Attachment-Warning.txt" attachment(s) for more information. can you post this in a bug, or some other permanent site? feel frre to email it to me if you need us to post it on web From travis at SEDSystems.ca Fri Sep 24 18:31:10 2004 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Fri, 24 Sep 2004 12:31:10 -0600 (CST) Subject: Database Schema chart In-Reply-To: <4146197D.7080102@bugzilla.org> References: <4071F6C4.9060700@bugzilla.org> <4146197D.7080102@bugzilla.org> Message-ID: On Mon, 13 Sep 2004, David Miller wrote: > > What I'm wondering, therefore, is: > > > > a) is someone else already doing this > > I'm not aware of anyone else that's said they were going to, so by all > means feel free to take it on. :) Okay... so I did, and it's done. Took longer than I'd though (both from when I originally promised it in March, and from when I said again I'd do it now) but there's something finished now. Not quite what you were hoping for (see below) but I hope it'll do. > > b) is this the preferred format (dia)? I ask because I have access to both > > corel and visio, either of which could produce better-looking diagrams (and > > be a lot easier for me to work with). Dia is *great* for a free tool, but it > > does seem rather... primitive. > > Yeah, Dia is the preferred format, mostly because it is free, and it's > easier for the average developer to get their hands on it and update the > chart next time we make schema changes. Okay. I tried working with dia... I really did. I just couldn't finish with it, though, because the whole thing was just looking so damn *ugly* and I felt like I was trying to sew with mittens on. I don't do a lot of diagram work any more, but when I do I like things to look just so... so I picked up the half-finished job I'd done on the 2.16 schema in CorelDraw and finished it. The result is attached to this document as a zip in three different formats: * Original corel draw document, so that you've got a copy. (You told me that all you guys had was the .jpg from the last schema diagram.) * 1-to-1 size .jpg with standard compression: original filesize of 8MB, 'shrunk' to 2MB. This is a high-res image from the .cdr file that you can play with for importing/exporting. * The results of a generic 'publish to the web' sort of wizard inside Corel Draw: one .html file and a directory of images. As I said, this is schema for 2.16; I know that it's rather late to be doing this, but it's where I started and it's what I understand. (I haven't been following the 2.17/2.18 progression much at all, so I don't grok the pattern of what's been added and how it inter-relates just yet. I figured that this would get me back in the game, and be a good starting point for me for 2.18... or if I end up having to ditch again, at least you're further ahead than you were. What I'd like before going on to 2.18 is some constructive criticism on the results. I know what I did isn't how you had it laid out; it more mirrors the schema diagrams done for 2.14 and before. That was intentional; your initial diagrams had a great deal of information on them, but it was a tad overwhelming and confusing. I thought that this was clear without being (too) cluttered, and was able to convey the relationships well. I'd like you to tell me what's important to you, though. If you really really REALLY want all those enum-listings, foreign keys, unique, multiple, etc. on the schema chart, let me know and I'll see what I can do to work it in. Basically, provide me with some feedback that I can use to start working with 2.18 (Should I have posted this to the appropriate log item too? I'm really not used to working with open source projects, so I tend to interact with one person better... but if there's a right and wrong way of doing stuff like this please let me know and I'll work on following procedure.) > For the immense size of the data on there, it may work best to rearrange > the tables into logical areas of functionality, and actually put each > functional area on a separate page... I'm quite pleased that I was able to get all of 2.16 on a single page, but I have no such illusions that I'll be able to do so with 2.18 without shrinking it to unreadability... so yeah, split across two pages would probably do it. Once I have some feedback on this (the image, the process, anything) I'll start working on 2.18. Since I've got a pretty hefty base to start from now (lots of learned/re-learned skills in doing the 2.16 one, and most of the tables haven't changed that much since 2.16) it should be a relatively painless process to update it. Sincerely; Shane Travis | Physics is like sex. Sure, it may give some travis at sedsystems.ca | practical results, but that's not why we Saskatoon, Saskatchewan | do it. -- Richard Feynman -------------- next part -------------- A non-text attachment was scrubbed... Name: bugzilla.zip Type: application/zip Size: 2291733 bytes Desc: URL: From justdave at bugzilla.org Fri Sep 24 20:50:15 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 24 Sep 2004 16:50:15 -0400 Subject: {Virus?} Re: Database Schema chart In-Reply-To: References: <4071F6C4.9060700@bugzilla.org> <4146197D.7080102@bugzilla.org> Message-ID: <41548887.2080802@bugzilla.org> Shane H. W. Travis wrote: > Warning: This message has had one or more attachments removed > Warning: (bugzilla.zip). > Warning: Please read the "Syndicomm-Attachment-Warning.txt" attachment(s) for more information. OK, I tried to release this to the list, but it stripped it individually off of each subscriber's copy on the outbound side. If you really want to see it, follow the instructions in the SECOND copy of it that came through for getting the attachment, otherwise Shane should just post it somewhere so we can download it :) (on a bug preferably) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From john.fisher at znyx.com Fri Sep 24 21:27:49 2004 From: john.fisher at znyx.com (John Fisher) Date: Fri, 24 Sep 2004 14:27:49 -0700 Subject: [cgiapp] SVN with integrated bug tracker Was: Status of upcoming In-Reply-To: <41542B2C.8020201@yale.edu> References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> <41542B2C.8020201@yale.edu> Message-ID: <41549155.7050309@znyx.com> as a configuration manager I think integration with a trouble ticket system is a very good idea. You'll need to know that tech support issues 3001-3016 all involve bug 2345, which had a workaround but is now fixed, but only for models D,G, and S. Christopher doesn't agree, but I think it would be wise to look at the integrated PHP-based environments that already have wikis, project management, and calendars - like xoops, phpgroupware, and phpslash. anybody have experience there? I'd like to hear... It would make customization issues easier if the integration covered pluggable apps underneath, in whatever language or languages. John Peter Masiar wrote: > > I would go for SVN first. CVS is past, and Arch has different philosophy > (is distributed). SVN server is central code repository, and natural > place for central bug tracking database and wiki with project docs. > >> - source code browser >> - integrated wiki > > > There was (a year ago) one project in East Asia (IIRC Taiwan), using RT > bug tracker framework and Kwiki wiki engine, but then they had all docs > in chinese - then :-( > > -- John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From travis at SEDSystems.ca Fri Sep 24 21:29:12 2004 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Fri, 24 Sep 2004 15:29:12 -0600 (CST) Subject: Bugzilla database schema Message-ID: Hello all; I have posted a lower-res version of my .jpg to the following relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=183216 I'm signed on to the list now, so comments can either be there or here. I'm looking for feedback on aesthetics, functionality, style, organization, etc. Please don't tell me I should use/should have used dia; I tried using it in conjunction with the work-in-progress that Dave posted, and found it to be primitive and ugly. I'm much more familiar with CorelDraw, and own a copy (five years old, but still completely functional) so that's what I went with. One thing I'd appreciate feedback on: the arrow-labels on the old 2.16 diagram (really the 2.14 diagram pasted into 2.16 documentation) were of the format 'parent-field = child-field'. That didn't look at all right to me, and I couldn't uncover any sort of standard, so I've reversed it (as well as adding the table name), and it 'feels' better. Pleased to meet you all, and glad to be of assistance. Thanks, Dave, for putting up with my silly questions, and hand-holding me through the early parts of my contribution. :) Shane Travis | Physics is like sex. Sure, it may give some travis at sedsystems.ca | practical results, but that's not why we Saskatoon, Saskatchewan | do it. -- Richard Feynman From myk at mozilla.org Fri Sep 24 21:42:45 2004 From: myk at mozilla.org (Myk Melez) Date: Fri, 24 Sep 2004 14:42:45 -0700 Subject: [cgiapp] Re: Status of upcoming release? In-Reply-To: References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> Message-ID: <415494D5.6030504@mozilla.org> Christopher Hicks wrote: > But there are still lots of features in Trac that I want, that look > very nice, that would make my life as a developer easier, and to the > best of my recollection that have been declared beyond the scope of > BZ. And I want those features without throwing out bugzilla. So as > far as I can tell to get something like this done we need a new > project to build a superset of BZ's functionality. That's not clear at all. First, some of the features on your list are not beyond Bugzilla's scope, they just haven't been implemented yet. You could implement those in Bugzilla without forking. Others may be beyond the scope of core Bugzilla but would work very well as an extension (ala Firefox extensions) using our new template hooks mechanism and a Perl code-equivalent that we plan to implement soon. The rest of the features on your list are indeed beyond Bugzilla's scope, but that's because they're sufficiently complex and different that it makes more sense for them to be separate applications with good integration between the top apps. I don't speak for all core developers, but here's where the features on your list fall within those three categories (core feature, extension, or separate app with integration points) in my book: > - SVN/CVS/Arch integration This should be core Bugzilla functionality, implemented in a way that allows us to add support for additional revision control tools in the future just as we currently support multiple authentication schemes. > - source code browser mozilla.org uses an old, forked version of LXR for this with various integration points (f.e. when you view a diff in Bugzilla you can browse to the LXR pages for the files being diffed). Newer and better versions of LXR and other source code browsers are available. This seems like very different and complex functionality and something better maintained as a separate application with good integration points between the two. > - integrated wiki Seems like there are so many good wikis out there that a separate application with good integration points is the better solution, but I also don't understand the problem a wiki is trying to solve here. What benefits would an integrated wiki provide to Bugzilla? > - links between source code browser, bug tracker, and wiki The links between Bugzilla and the other apps should be a part of core Bugzilla, as they are now for Bugzilla->source code browser links. > - tasks I probably don't understand this item, since for me tracking tasks is what Bugzilla does. Can you explain the difference between Bugzilla bug reports and tasks? > - project management We've resisted making Bugzilla a project management tool for a while, even as project management features have crept into the application (f.e. the time tracking code, but also longstanding features like the target milestone field). I think it's OK to have some lightweight project management functionality in Bugzilla, as there is today, for shops doing the kind of development that doesn't need a heavyweight tool like Microsoft Project (like mozilla.org incidentally), but complex needs are better served by a specialized application. Additional project management features in Bugzilla for lightweight project management would have to be tackled on a case-by-case basis. What is it you're looking for? > - Web, XUL, and SOAP interfaces I'd love to have a XUL interface to Bugzilla. I did some work on one a while ago (Bugxula ), and since I don't have time to work on it these days I'd be happy to turn over that code to someone who wanted to develop it further. Note that Bugxula is an independent desktop application, not a core component of Bugzilla, and this model would probably work best for a web-based XUL application as well--we just need to build out Bugzilla's programmatic interfaces, which brings me to SOAP... I'm sanguine about SOAP, preferring REST for its simplicity, adherence to web principles, and popularity (most requests to Amazon's web services API are to its REST version), but I'd be willing to see a high-quality and well-maintained SOAP implementation become part of Bugzilla proper. This might do better as an extension however, at least at first. > - server side written Perl (obviously) Sure. > - checkpoint new comments in progress without posting them > - ability to predate comments so that time entries can be added > asynchronously to when the work is done I don't understand these. Can you elucidate? -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From chicks at chicks.net Fri Sep 24 23:52:11 2004 From: chicks at chicks.net (Christopher Hicks) Date: Fri, 24 Sep 2004 19:52:11 -0400 (EDT) Subject: [cgiapp] SVN with integrated bug tracker Was: Status of upcoming In-Reply-To: <41549155.7050309@znyx.com> References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> <41542B2C.8020201@yale.edu> <41549155.7050309@znyx.com> Message-ID: On Fri, 24 Sep 2004, John Fisher wrote: > as a configuration manager I think integration with a trouble ticket > system is a very good idea. You'll need to know that tech support issues > 3001-3016 all involve bug 2345, which had a workaround but is now fixed, > but only for models D,G, and S. I'd like trouble tickets to be handled as basically bugs minus a few extraneous things. > Christopher doesn't agree, but I think it would be wise to look at the > integrated PHP-based environments that already have wikis, project > management, and calendars - like xoops, phpgroupware, and phpslash. > anybody have experience there? I'd like to hear... I'm not morally opposed to using PHP apps as part of an interim solution. > It would make customization issues easier if the integration covered > pluggable apps underneath, in whatever language or languages. Absolutely. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From gerv at mozilla.org Sat Sep 25 13:54:13 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 25 Sep 2004 14:54:13 +0100 Subject: Charting system - Editing series queries In-Reply-To: <4152D78B.6090108@asyn.com> References: <4152D78B.6090108@asyn.com> Message-ID: <41557885.4010001@mozilla.org> Stuart Donaldson wrote: > Is it possible yet to edit the series queries in the new charting system? No. > Or maybe to delete them if you no longer use them? No. There used to be a mechanism for deleting them once they were no longer used by anyone, but it got removed when "Subscriptions" was removed. > How about copying the series query to a new product? Nope. > I am upgrading my installation and want to start using the new charting > system (very cool by the way!) and I expect some time to tune the > queries to what i want. And then I need to be able to apply them to > multiple products. Sorry; the system's quite new and the management features aren't all that they could be yet. Gerv From justdave at bugzilla.org Sun Sep 26 06:27:35 2004 From: justdave at bugzilla.org (David Miller) Date: Sun, 26 Sep 2004 02:27:35 -0400 Subject: Volunteers needed for 2.18rc3 release In-Reply-To: <414A54E2.1010701@bugzilla.org> References: <4149D7EB.2060203@bugzilla.org> <4149DA3E.3020704@bugzilla.org> <1095374712.24695620@r31.dngr.org> <414A54E2.1010701@bugzilla.org> Message-ID: <41566157.2070306@bugzilla.org> David Miller wrote: > Zach Lipton wrote: > >> I'd be happy to do the status update (yes I really am alive...). >> What's the timeframe looking like for the release? > > As soon as the status update and the docs webpage are done. Those are > the only things holding it up. :) All the blocker bugs are resolved or > waiting for review. OK, I went and tackled the documentation page, since no one else has volunteered for it in the 10 days since I asked. :) You can see the results at http://www.bugzilla.org/docs/documentor.html It's still unfinished, but the basics are there. Still to be covered: how to turn your changes into a patchfile. If someone wants to write that up, feel free. :) That leaves the status update.............. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From jouni at heikniemi.net Sun Sep 26 06:34:33 2004 From: jouni at heikniemi.net (Jouni Heikniemi) Date: Sun, 26 Sep 2004 09:34:33 +0300 Subject: Patch version numbers Message-ID: <415662F9.2040106@heikniemi.net> A kind suggestion for people uploading patches and filling the "Attachment description" field: Please use some sort of patch versioning when uploading several patches to a bug. When your "initial shot" gets an r-, don't name the next one "aarggh" or "bugs fixed", but rather give it a name that clearly indicates it is the second try; "v2" is what I use, but anything with equal information is fine. The key benefit here is clarity. When you take several interdiffs between patches like "aarggh" and "nits fixed", you usually make a wrong interpretation at some point. Numbers are easier to read and reduce the risk for confusion. If you want it to be "v17: aaarggh", that's fine - as long as there's the numbering. Pretty please with sugar on the top? Jouni From chicks at chicks.net Sun Sep 26 22:52:39 2004 From: chicks at chicks.net (Christopher Hicks) Date: Sun, 26 Sep 2004 18:52:39 -0400 (EDT) Subject: [cgiapp] Re: Status of upcoming release? In-Reply-To: <415494D5.6030504@mozilla.org> References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> <415494D5.6030504@mozilla.org> Message-ID: On Fri, 24 Sep 2004, Myk Melez wrote: > Christopher Hicks wrote: > >> But there are still lots of features in Trac that I want, that look very >> nice, that would make my life as a developer easier, and to the best of my >> recollection that have been declared beyond the scope of BZ. And I want >> those features without throwing out bugzilla. So as far as I can tell to >> get something like this done we need a new project to build a superset of >> BZ's functionality. > > That's not clear at all. First, some of the features on your list are > not beyond Bugzilla's scope, they just haven't been implemented yet. > You could implement those in Bugzilla without forking. I have no objection to implementing features that make sense in the bugzilla context, but I'm not sure which things should be in which context. I'm not trying to compete with BZ at all. I like BZ. I want more people to use BZ. I'm lazy and I have no interest in reinventing the wheel which BZ had refined already far better than anything else I've ever seen. If anyone has any question about my motives don't be afraid to ask onlist or off. > Others may be beyond the scope of core Bugzilla but would work very well > as an extension (ala Firefox extensions) using our new template hooks > mechanism and a Perl code-equivalent that we plan to implement soon. I don't object to doing things that way that make sense to do that way. I'm looking forward to the CSS skinability work that folks are doing too. I'd really like to have everything in my development suite look like it was meant to go together instead of a farm house with 150 years of sheds stuck on the back. :) > The rest of the features on your list are indeed beyond Bugzilla's > scope, but that's because they're sufficiently complex and different > that it makes more sense for them to be separate applications with good > integration between the top apps. I don't speak for all core > developers, but here's where the features on your list fall within those > three categories (core feature, extension, or separate app with > integration points) in my book: I appreciate you putting the time into considering these. >> - SVN/CVS/Arch integration > > This should be core Bugzilla functionality, implemented in a way that > allows us to add support for additional revision control tools in the > future just as we currently support multiple authentication schemes. I have no objection to using whatever of this is implemented in bugzilla at any given time. My goal here is to not compete or overlap with bugzilla functionality at all. For something where there's a popular patch already available putting together a FullyLoadedBugzillaSuperset I'd like to include that patch. For very controversial (or very boring) things this could be an opportunity to get wider testing of features that are pending to go into the core bugzilla. If such a patch or something functionally equivalent got applied to bugzilla we'd stop patching our version. If such a patch was decided that it was not worthy of being in the OneTrueBugzilla then the value of maintaining the patch versus the value of the feature would have to be weighed with my tendancy being toward dropping it or reimplemnting the feature in a way that worked in parallel instead of in patch to bugzilla. Does this philosophy bother anyone? >> - source code browser > > mozilla.org uses an old, forked version of LXR for this with various > integration points (f.e. when you view a diff in Bugzilla you can browse > to the LXR pages for the files being diffed). Newer and better versions > of LXR and other source code browsers are available. This seems like > very different and complex functionality and something better maintained > as a separate application with good integration points between the two. I'm not trying to recreate the wheel. I'm trying to take the various pieces and provide an easy way for people to get it installed that doesn't require them setting up the integration points by hand. I haven't looked at lxr's guts, but I've enjoyed using it. cvsmonitor is another fine example of something that I seen no need to recreate in the forseeable future that would be beneficial to have integrated. >> - integrated wiki > > Seems like there are so many good wikis out there that a separate > application with good integration points is the better solution, but I > also don't understand the problem a wiki is trying to solve here. What > benefits would an integrated wiki provide to Bugzilla? A wiki may not provide any benefit to bugzilla, but it it can be very beneficial in a larger project sense. I'm not sure whether it was in private email or something on a mailing list, but one of the folk who responded with interest suggested having two wikis per project - one for user documentation and one for development documentation. This makes a lot of sense to me and closely mirrors what we've done emergently on our projects using one wiki. But if you have one fixed wiki that's going to be involved with a project, then you can do some interesting things. For one, the data dictionary for the project could be maintained through the wiki interface. Changes to the data design would need to be updated into subversion. Some script for migrating the data would need to be created, but could be autogenerated for the common case of adding a new column. This subversion event should be picked up and shown in the bug with a link that takes somebody into the wiki so that they could see the change in context or a link into lxr to see the underlying code and version history. Do you see where I want this to go? >> - links between source code browser, bug tracker, and wiki > > The links between Bugzilla and the other apps should be a part of core > Bugzilla, as they are now for Bugzilla->source code browser links. Absolutely. >> - tasks > > I probably don't understand this item, since for me tracking tasks is what > Bugzilla does. Can you explain the difference between Bugzilla bug reports > and tasks? There's been a lot of prior discussion on the list about this. I maintain that tasks are semantically different and should be treated in a somewhat different fashion. I find that I have a single bug that starts of with a couple of things that need to be done within it. That leads to a few other things needing to be done and so on. I could (as some have suggested) track this evolving task list by making bugs for the individual tasks. This seems like a painful amount of overhead for me and it violates the semantic difference between a bug and a thread for me personally. >> - project management > > We've resisted making Bugzilla a project management tool for a while, > even as project management features have crept into the application > (f.e. the time tracking code, but also longstanding features like the > target milestone field). I can respect the reasons for maintaining a pure focus for bugzilla at the same time as I really want something that isn't so pure. > I think it's OK to have some lightweight project management > functionality in Bugzilla, as there is today, for shops doing the kind > of development that doesn't need a heavyweight tool like Microsoft > Project (like mozilla.org incidentally), but complex needs are better > served by a specialized application. That's totally fine with me. > Additional project management features in Bugzilla for lightweight > project management would have to be tackled on a case-by-case basis. Billing is one piece that we've got hacked together now that I'd like to see done in a way that other people could use it an build on it. Time > What is it you're looking for? - Time forecasts (how many bugs will I kill this week if I work six hours a day?) - the ability to assign multiple people to a task and disproportionately allocate time to them and forecast completion times for each person based on that. - graphs showing time worked history - graphs for forecast which projects will be using time which days for the next two weeks. >> - Web, XUL, and SOAP interfaces > > I'd love to have a XUL interface to Bugzilla. I'm shooting a bit higher. I want a XUL interface to all the stuff I talked about above ultimately. :) > I did some work on one a while ago (Bugxula > ), Which I've actually used a few desktop boxes ago. > and since I don't have time to work on it these days I'd be happy to > turn over that code to someone who wanted to develop it further. I'd certainly like to use what you've done as a starting point. > Note that Bugxula is an independent desktop application, not a core > component of Bugzilla, and this model would probably work best for a > web-based XUL application as well--we just need to build out Bugzilla's > programmatic interfaces, which brings me to SOAP... Yay. > I'm sanguine about SOAP, preferring REST for its simplicity, adherence > to web principles, and popularity (most requests to Amazon's web > services API are to its REST version), but I'd be willing to see a > high-quality and well-maintained SOAP implementation become part of > Bugzilla proper. This might do better as an extension however, at least > at first. I'm pretty comfortable with the database layout of bugzilla for getting the various pieces of data out that need to be displayed. For manipulations I'm guessing I should use the new object-oriented Bug interface, but I haven't looked at that and I don't remember how far that is along. >> - checkpoint new comments in progress without posting them >> - ability to predate comments so that time entries can be added >> asynchronously to when the work is done > > I don't understand these. Can you elucidate? More than once I've been somewhere and I'll start working on a bug comment and I need to be more research before I finish it and I have to decide whether to sit down and do the research while I'm onsite or kill the comment I've started and redo the whole thing when I get home. If I could checkpoint the comment in progress without posting it to the bug, and reopen it at home it would eliminate a lot of "???________fill in____???" sorts of things that show up because I'm too lazy to redo the whole thing later and i just enter it half-done and then rewrite and repost the whole thing once I have time/brain/etc. to finish it. The other issue is that I may do work on one day and not put it in until the next day. I bill off of BZ, so if I'm a slacker and don't get my time in on the same day that the work is done the bills look funny and its harder to match up the BZ entries with the calendar when trying to figure out what happened when. Does that make more or less sense now? :) -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From bugzilla at sethdaniel.org Mon Sep 27 00:26:27 2004 From: bugzilla at sethdaniel.org (Seth Daniel) Date: Sun, 26 Sep 2004 17:26:27 -0700 Subject: LDAP TLS patch Message-ID: <20040927002627.GA26206@sethdaniel.org> Hello, I didn't receive any response to my last e-mail when I sent a patch that added START TLS support to Auth/Verify/LDAP.pm. I have attached a slightly revised patch to the bug itself at https://bugzilla.mozilla.org/show_bug.cgi?id=250916 We are currently using this patch where I work and we are eager to get this patch included into Bugzilla proper. Please let me know what I can do. Thank you. -- seth / @sethdaniel.org From john.fisher at znyx.com Mon Sep 27 17:59:42 2004 From: john.fisher at znyx.com (John Fisher) Date: Mon, 27 Sep 2004 10:59:42 -0700 Subject: [cgiapp] SVN with integrated bug tracker Was: Status of upcoming In-Reply-To: References: <20040921145531.GA8593@lyra.weierophinney.net> <4152D039.7050601@yale.edu> <41542B2C.8020201@yale.edu> <41549155.7050309@znyx.com> Message-ID: <4158550E.3010809@znyx.com> I struggled with this issue, and I don't agree. Here's my argument: The bug report has a different life cycle from the trouble ticket. There is Test dept work with bugs, and none with tickets. Bug reporting most likely will not want direct customer input and/or access. Tickets do require customer data and may require customer access. Bug reports may be viewed as part of a ticket system, but usually they are not given to customers. ( OK you could argue Microsoft does this, but I say they give out workarounds not bug reports, and anyway they aren't my model.) The tech support personnel aren't the same users as developers, and developers don't need the tech support data until it becomes a bug. So I opted for giving my trouble ticket system access to Bugzilla to read bugs, and the capability to note bug numbers within tickets. Christopher Hicks wrote: > I'd like trouble tickets to be handled as basically bugs minus a few > extraneous things. > >> -- John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From justdave at bugzilla.org Wed Sep 29 11:50:33 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 29 Sep 2004 07:50:33 -0400 Subject: Review statistics In-Reply-To: <40EAF78B.8030903@bugzilla.org> References: <40EAF78B.8030903@bugzilla.org> Message-ID: <415AA189.3080402@bugzilla.org> Updated stats: The following is a list of everyone who has either granted or denied a review in the Bugzilla product in the last 6 months, sorted by how many reviews they did. +-----------------------+---------------------+--------------+ | login_name | last_review | review_count | +-----------------------+---------------------+--------------+ | vladd at goobix.com | 2004-09-29 01:52:12 | 84 | | bugreport at peshkin.net | 2004-09-19 14:36:13 | 83 | | kiko at async.com.br | 2004-09-21 12:08:05 | 78 | | jouni at heikniemi.net | 2004-09-26 06:25:04 | 75 | | justdave at bugzilla.org | 2004-09-24 00:58:32 | 70 | | myk at mozilla.org | 2004-09-24 13:33:08 | 39 | | gerv at mozilla.org | 2004-09-21 02:01:24 | 26 | | timeless at bemail.org | 2004-07-15 13:14:22 | 13 | | erik at dasbistro.com | 2004-09-23 16:59:18 | 8 | | bugzilla at glob.com.au | 2004-09-02 06:22:52 | 6 | | zach at zachlipton.com | 2004-08-04 22:04:42 | 5 | | burnus at gmx.de | 2004-09-10 05:47:18 | 4 | | bbaetz at acm.org | 2004-04-06 06:23:48 | 2 | | john at johnkeiser.com | 2004-07-17 12:57:00 | 2 | | toms at myrealbox.com | 2004-04-17 05:40:03 | 1 | | preed at sigkill.com | 2004-05-13 08:34:05 | 1 | | tiago at async.com.br | 2004-09-13 16:25:14 | 1 | +-----------------------+---------------------+--------------+ -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bugzilla at glob.com.au Thu Sep 30 02:30:43 2004 From: bugzilla at glob.com.au (bugzilla at glob.com.au) Date: Thu, 30 Sep 2004 10:30:43 +0800 (WST) Subject: enforcing access is via urlbase Message-ID: <20040930023043.239834BC2AF@stutter.bur.st> what do people think about always redirecting to urlbase (once it's been set) if the current url doesn't match it? right now if a machine has multiple names that point to the same httpd, you can hit bugzilla on any of those names regardless of the configured urlbase this has an impact on cookies and on a bug 260682 (support redirecting to https for authenticated sessions only). this bug basically redirects from the current url to https://current url when a login is required. stephen lee raised a valid point on that bug.. what if the box has multiple names and the certificate is attached to a name that you're not accessing? this got me thinking.. one fix is to add another parameter to specify the sslbase but i think we have enough parameters as it is. (need to sort out that categorise parameters bug) another option is to ensure that when a user hits the bugzilla install, they use the offical urlbase, and redirect if they don't. begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From mkanat at kerio.com Thu Sep 30 11:59:51 2004 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Thu, 30 Sep 2004 04:59:51 -0700 Subject: enforcing access is via urlbase In-Reply-To: <20040930023043.239834BC2AF@stutter.bur.st> References: <20040930023043.239834BC2AF@stutter.bur.st> Message-ID: <1096545591.3212.28.camel@max.localdomain> On Wed, 2004-09-29 at 19:30, bugzilla at glob.com.au wrote: > another option is to ensure that when a user hits the bugzilla install, they > use the offical urlbase, and redirect if they don't. The only problem with this is if you have two listening IPs for your Bugzilla, with two different domains, one public and one private, and you've somehow hacked Bugzilla to do certain access restrictions based on that. I'm not sure how common a scenario that is or ever would be; I'm not doing it. Other than that, I think it's probably a fine idea. Of course, it really belongs in the .htaccess file as a RewriteRule, or something like that. It's a doc note, I think, as part of the installation guide, more than an option in Bugzilla. -Max From justdave at bugzilla.org Thu Sep 30 21:57:22 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 30 Sep 2004 17:57:22 -0400 Subject: enforcing access is via urlbase In-Reply-To: <1096545591.3212.28.camel@max.localdomain> References: <20040930023043.239834BC2AF@stutter.bur.st> <1096545591.3212.28.camel@max.localdomain> Message-ID: <415C8142.30407@bugzilla.org> Max Kanat-Alexander wrote: > Other than that, I think it's probably a fine idea. Of course, it > really belongs in the .htaccess file as a RewriteRule, or something like > that. It's a doc note, I think, as part of the installation guide, more > than an option in Bugzilla. Another point is that if the end-user is using HTTP/1.0 to access Bugzilla, then there is no way for Bugzilla to know which hostname they used. (although we can certainly tell if they're using SSL or not) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/