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?
[% 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:
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 ? '(+)' : '(-)'
%]
> 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:
>
>
>
> 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:
>
>
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.
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
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?
>
>
[% 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/