You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bruno Dumon <br...@outerthought.org> on 2003/10/09 11:42:59 UTC
Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug
10203] - Docs referenced by XSLT's document() are not included in cache
validity)
On Wed, 2003-10-08 at 19:28, bugzilla@apache.org wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10203>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10203
>
> Docs referenced by XSLT's document() are not included in cache validity
>
>
>
>
>
> ------- Additional Comments From cziegeler@apache.org 2003-10-08 17:28 -------
> Ah, ok you're right. Although I guess that it's technical possible it will get
> even more messy than the whole caching code is already.
> In my opinion, it's sufficient to document this behaviour. Users can take care
> of it - if they know.
>
> On the other hand, I think this is more a feature request than a bug. So I
> suggest to add this to our feature request page at the wiki and close this bug.
> Or you can start a vote if this is more a bug or more a feature request first.
I agree it's a feature request and added it to the wiki page. However,
can't we use bugzilla also to track (serious) feature requests? There
are a couple of other "enhancement" requests in there, should we also
close them and add them to the wiki page?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug
10203] - Docs referenced by XSLT's document() are not included in cache
validity)
Posted by Andrew Savory <an...@luminas.co.uk>.
On Thu, 9 Oct 2003, Carsten Ziegeler wrote:
> I thought about this topic/problem as well. My first idea was to say a
> feature requests is not entered into bugzilla but on the wiki page.
> This would free us from many open bugzilla entries.
I'm with Bertrand on this - let's use bugzilla. We shouldn't think of
"many open bugzilla entries" as bad - bugzilla entries can be good as well
as bad, so lots of entries could indicate we know where we are going!
(Some form of crude roadmap?)
> I'm not sure if this is a good procedure or not. What do you think?
I think a "lazier" procedure of just dumping bugs/features/enhancements in
bugzilla and using the existing bugzilla query tools would work better.
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
Orixo alliance: http://www.orixo.com/ Web: www.luminas.co.uk
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug
10203] - Docs referenced by XSLT's document() are not included in cache
validity)
Posted by Joerg Heinicke <jh...@virbus.de>.
Bertrand Delacretaz wrote:
> Le Jeudi, 9 oct 2003, à 12:13 Europe/Zurich, Carsten Ziegeler a écrit :
>
>> ...And we also create a process in the following way:
>> - the wiki feature request page is scanned from time to time (the mails
>> help there)
>> - A new entry is evaluated (perhaps the feature doesn't make sense or
>> is a bug or is a really cool thing etc.) and if accepted added
>> to our planning document.
>> So the planning document in our docs contains the approved list of
>> feature
>> requests....
>
> See what you mean, but this could also be a list of pointers to bugzilla.
>
> IMHO if we start to use bugzilla more seriously, we will need a slightly
> more precise categorization of issues:
> -actual bugs with different severity levels (can do)
> -patches ([PATCH] header is a hack but more or less workable)
> -feature requests
> -release-related stuff (if we want to use bugzilla dependencies to
> prepare releases)
> -more?
+1
> Meaning that we shouldn't count just "open issues" anymore, rather "open
> bugs", "open feature requests", "open patches" etc.
> On Monday we were focused on "total open issues" which is wrong IMHO.
>
> I think this is easier to do in bugzilla where everything is dynamic.
IMO it's important to collect "everything" related to "open issues" in
bugzilla and not to move the feature requests or anything else out of it to
wiki or whereever. If bugzilla is one of the most important tools (desert
island tools ;-) ) almost everything should be found there. I really
wondered about the step towards wiki for feature requests.
> This might need adding more possible values to the "severity" field,
> dunno off the top of my head how easy it is to do. Otherwise we can use
> title headers like [RELEASE] [REQUEST] etc.
There is a "keyword" field in bugzilla. They can be defined by admins I
think and also be queried. This is the one we use in the company too. The
summary prefixes [XYZ] are only for better usability. You see it in a list
to which group the issue belongs to.
> For feature requests, my suggestion would be to do so:
> -Let them come in bugzilla
> -Evaluate them often, and close the ones which seem too far away with
> resolution=LATER
> -Explain all this on a wiki page, with links to bugzilla queries to show
> what's current
+1
> This would help give more importance to bugzilla for planning/progress
> monitoring stuff, which I think is good.
> And in this way we avoid the need to synchronize lists or move stuff
> between bugzilla and the wiki.
+1000
I hate to maintain duplicate resources and to make duplicate effort.
>> ...I'm planning to "reactivate" our planning documentation in the docs
>> section
>> so that it show more information anyway...
>
>
> Could be good if we're able to keep promises made there. I don't know if
> it is realistic.
+1
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Jeudi, 9 oct 2003, à 12:38 Europe/Zurich, Carsten Ziegeler a écrit :
> ...Ok, I tend to agree with you that using bugzilla is better (and
> easier).
> But the differentiation using [PATCH], [XYZ] is a little bit ugly. If
> it's possible to use a different (better) approach there I'm fine with
> it...
I agree that differentiation should be better than [CODES] in titles.
The "severity" field is not fantastic though. In some of my projects we
use the "component" field in a twisted way for differentiation, which
is kind of hacky but at least it's a database field, and we can easily
define our own values.
Any ideas out there?
-Bertrand
RE: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote:
>
> Le Jeudi, 9 oct 2003, à 12:13 Europe/Zurich, Carsten Ziegeler a écrit :
> > ...And we also create a process in the following way:
> > - the wiki feature request page is scanned from time to time (the mails
> > help there)
> > - A new entry is evaluated (perhaps the feature doesn't make sense or
> > is a bug or is a really cool thing etc.) and if accepted added
> > to our planning document.
> > So the planning document in our docs contains the approved list of
> > feature
> > requests....
>
> See what you mean, but this could also be a list of pointers to
> bugzilla.
Ok. Perhaps automatically generated somehow?
>
> IMHO if we start to use bugzilla more seriously, we will need a
> slightly more precise categorization of issues:
> -actual bugs with different severity levels (can do)
> -patches ([PATCH] header is a hack but more or less workable)
> -feature requests
> -release-related stuff (if we want to use bugzilla dependencies to
> prepare releases)
> -more?
>
> Meaning that we shouldn't count just "open issues" anymore, rather
> "open bugs", "open feature requests", "open patches" etc.
Yes, that's true!
> On Monday we were focused on "total open issues" which is wrong IMHO.
Right, bugs are more important imho.
>
> I think this is easier to do in bugzilla where everything is dynamic.
Agreed.
>
> This might need adding more possible values to the "severity" field,
> dunno off the top of my head how easy it is to do. Otherwise we can use
> title headers like [RELEASE] [REQUEST] etc.
>
> For feature requests, my suggestion would be to do so:
> -Let them come in bugzilla
> -Evaluate them often, and close the ones which seem too far away with
> resolution=LATER
> -Explain all this on a wiki page, with links to bugzilla queries to
> show what's current
>
Ok, we can give it a try.
> This would help give more importance to bugzilla for planning/progress
> monitoring stuff, which I think is good.
> And in this way we avoid the need to synchronize lists or move stuff
> between bugzilla and the wiki.
Yes, that's right.
Ok, I tend to agree with you that using bugzilla is better (and easier).
But the differentiation using [PATCH], [XYZ] is a little bit ugly. If
it's possible to use a different (better) approach there I'm fine with
it.
Carsten
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Jeudi, 9 oct 2003, à 12:13 Europe/Zurich, Carsten Ziegeler a écrit :
> ...And we also create a process in the following way:
> - the wiki feature request page is scanned from time to time (the mails
> help there)
> - A new entry is evaluated (perhaps the feature doesn't make sense or
> is a bug or is a really cool thing etc.) and if accepted added
> to our planning document.
> So the planning document in our docs contains the approved list of
> feature
> requests....
See what you mean, but this could also be a list of pointers to
bugzilla.
IMHO if we start to use bugzilla more seriously, we will need a
slightly more precise categorization of issues:
-actual bugs with different severity levels (can do)
-patches ([PATCH] header is a hack but more or less workable)
-feature requests
-release-related stuff (if we want to use bugzilla dependencies to
prepare releases)
-more?
Meaning that we shouldn't count just "open issues" anymore, rather
"open bugs", "open feature requests", "open patches" etc.
On Monday we were focused on "total open issues" which is wrong IMHO.
I think this is easier to do in bugzilla where everything is dynamic.
This might need adding more possible values to the "severity" field,
dunno off the top of my head how easy it is to do. Otherwise we can use
title headers like [RELEASE] [REQUEST] etc.
For feature requests, my suggestion would be to do so:
-Let them come in bugzilla
-Evaluate them often, and close the ones which seem too far away with
resolution=LATER
-Explain all this on a wiki page, with links to bugzilla queries to
show what's current
This would help give more importance to bugzilla for planning/progress
monitoring stuff, which I think is good.
And in this way we avoid the need to synchronize lists or move stuff
between bugzilla and the wiki.
> ...I'm planning to "reactivate" our planning documentation in the docs
> section
> so that it show more information anyway...
Could be good if we're able to keep promises made there. I don't know
if it is realistic.
-Bertrand
RE: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote:
>
> Le Jeudi, 9 oct 2003, à 11:42 Europe/Zurich, Bruno Dumon a écrit :
> > ...I agree it's a feature request and added it to the wiki page.
> > However,
> > can't we use bugzilla also to track (serious) feature requests? There
> > are a couple of other "enhancement" requests in there, should we also
> > close them and add them to the wiki page?
>
> We created
> http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatureRequests Monday in
> the frenzy of the Hackathon, but IMHO (and in retrospect) having them
> in Bugzilla makes more sense.
>
> The Wiki page can then explain how we handle them and include a
> bugzilla link to the list of currently open feature requests.
>
> We have to be clear on how we separate them from bugs though, I think
> feature requests should all have priority=Enhancment, is that ok? And
> what about [PATCH]es?
>
I thought about this topic/problem as well. My first idea was to say a
feature requests is not entered into bugzilla but on the wiki page.
This would free us from many open bugzilla entries.
And we also create a process in the following way:
- the wiki feature request page is scanned from time to time (the mails
help there)
- A new entry is evaluated (perhaps the feature doesn't make sense or
is a bug or is a really cool thing etc.) and if accepted added
to our planning document.
So the planning document in our docs contains the approved list of feature
requests.
I'm planning to "reactivate" our planning documentation in the docs section
so that it show more information anyway.
I'm not sure if this is a good procedure or not. What do you think?
Carsten
Re: Track feature requests in bugzilla? (was Re: [Bug 10203] -
Docs referenced by XSLT's document() are not included in cache validity)
Posted by Andrew Savory <an...@luminas.co.uk>.
On Sat, 11 Oct 2003, Jeff Turner wrote:
> On Fri, Oct 10, 2003 at 11:06:33AM +0100, Andrew Savory wrote:
>
> > Don't suppose I can convince you to open the source? Wouldn't you love
> > all the cocoon developers submitting patches and helping you push your
> > product forward?
>
> If it were open source, people wouldn't buy it, I wouldn't get paid and I
> wouldn't be able to hack on Forrest ;) OSS + commercial software _can_
> be nicely symbiotic.
Who says you can't charge for open source software?
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
Orixo alliance: http://www.orixo.com/ Web: www.luminas.co.uk
Re: Track feature requests in bugzilla? (was Re: [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Posted by Jeff Turner <je...@apache.org>.
On Fri, Oct 10, 2003 at 11:06:33AM +0100, Andrew Savory wrote:
> On Thu, 9 Oct 2003, Jeff Turner wrote:
>
> > JIRA open source licenses do not expire (nor do the commercial ones).
>
> (Just to be clear, that's a "JIRA license for open source projects" not
> a JIRA open source license ;-)
Yes, thanks.
> No, but the only way I know I'll be able to use the software in
> perpetuity is if I have the source code for it on my computer.
> Companies come and go. If I have the code I can continue working with
> the software.
Yep. Hence commercial (but not OSS) users get the source code too.
> Don't suppose I can convince you to open the source? Wouldn't you love
> all the cocoon developers submitting patches and helping you push your
> product forward?
If it were open source, people wouldn't buy it, I wouldn't get paid and I
wouldn't be able to hack on Forrest ;) OSS + commercial software _can_
be nicely symbiotic.
--Jeff
> Andrew.
>
> --
> Andrew Savory Email: andrew@luminas.co.uk
> Managing Director Tel: +44 (0)870 741 6658
> Luminas Internet Applications Fax: +44 (0)700 598 1135
> Orixo alliance: http://www.orixo.com/ Web: www.luminas.co.uk
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug
10203] - Docs referenced by XSLT's document() are not included in cache
validity)
Posted by Andrew Savory <an...@luminas.co.uk>.
On Thu, 9 Oct 2003, Jeff Turner wrote:
> JIRA open source licenses do not expire (nor do the commercial ones).
(Just to be clear, that's a "JIRA license for open source projects" not a
JIRA open source license ;-)
No, but the only way I know I'll be able to use the software in perpetuity
is if I have the source code for it on my computer. Companies come and go.
If I have the code I can continue working with the software.
Don't suppose I can convince you to open the source? Wouldn't you love all
the cocoon developers submitting patches and helping you push your
product forward?
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
Orixo alliance: http://www.orixo.com/ Web: www.luminas.co.uk
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Oct 09, 2003 at 03:05:41PM +0100, Andrew Savory wrote:
>
> Hi,
>
> On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:
>
> > Forrest uses Jira. Jira is much better than bugzilla. Jeff works for
> > the company that produces it. There is also a migration tool between
> > bugzilla and Jira. It's commercial, but free for open source use.
> >
> > I would be +1 to migrate to Jira.
>
> -1 for Jira.
>
> Sorry Stefano, but I don't believe we should be using proprietary software
> for critical infrastructure.
>
> - We would have no access to the source code
True, though it's just a fancy GUI over a database.
> - We would have to rely on a single organisation for development and support
True. There's also a pretty active jira-user list for support, with some
very savvy users.
> - We have no guarantee that the license would be in perpetuity (I can't
> find a copy of the license on their site).
JIRA open source licenses do not expire (nor do the commercial ones).
> For open source bts, Atlassian recommend bugzilla.
> http://www.atlassian.com/software/jira/docs/latest/faq.html#is_jira_open_source
>
> I know bugzilla's interface can be tiresome, but it _does_ do the job,
> it's tested and deployed worldwide, and it is free/libre.
Personally I don't mind bugzilla. It does the job despite UI crudeness.
Getting on my soapbox.. IMO all current bugtrackers suck when it comes to
email support. Email should be a *primary* interface. JIRA is better
than most in that it supports issue creation and commenting through
email, but its outgoing emails could be significantly improved:
http://jira.atlassian.com/secure/ViewIssue.jspa?key=JRA-2326
It's my pet JIRA bug ;) That and the sucky URI space (JRA-2058).
--Jeff
> Andrew.
>
> --
> Andrew Savory Email: andrew@luminas.co.uk
> Managing Director Tel: +44 (0)870 741 6658
> Luminas Internet Applications Fax: +44 (0)700 598 1135
> Orixo alliance: http://www.orixo.com/ Web: www.luminas.co.uk
RE: JIRA (was Re: Track feature requests in bugzilla?)
Posted by Reinhard Poetz <re...@apache.org>.
> From: Ugo Cei
>
>
> Stefano Mazzocchi wrote:
> > but I agree on your third point: locking could be applied (even if a
> > very bad move for them).
>
> But remember that you can always export your entire JIRA
> database in XML
> with a single command. So maybe your code can be locked, but
> your data not.
Yep, I thought the same too. Some month ago I compared Bugzilla, Scarab
and JIRA and I think JIRA is currently the bug tracking tool for OS
software development available.
Reinhard
JIRA (was Re: Track feature requests in bugzilla? (was Re: DO NOT
REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included
in cache validity))
Posted by Ugo Cei <u....@cbim.it>.
Stefano Mazzocchi wrote:
> but I agree on your third point: locking could be applied (even if a
> very bad move for them).
But remember that you can always export your entire JIRA database in XML
with a single command. So maybe your code can be locked, but your data not.
> Stefano.
Ugo
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug
10203] - Docs referenced by XSLT's document() are not included in cache
validity)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew Savory wrote:
> On Thu, 9 Oct 2003, Nicola Ken Barozzi wrote:
>
>>The question is, what problem are we trying to solve?
>
> AIUI, tracking serious feature requests.
And what's the problem, currently? AFAIK it's more about having people
to do stuff rather than seeing what to do ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug
10203] - Docs referenced by XSLT's document() are not included in cache
validity)
Posted by Andrew Savory <an...@luminas.co.uk>.
On Thu, 9 Oct 2003, Nicola Ken Barozzi wrote:
> The question is, what problem are we trying to solve?
AIUI, tracking serious feature requests.
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
Orixo alliance: http://www.orixo.com/ Web: www.luminas.co.uk
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug
10203] - Docs referenced by XSLT's document() are not included in cache
validity)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew Savory wrote:
> On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:
>
...
>>but don't impose bugzilla as the center of our work organization, it's
>>just too bad. :-(
>
> It depends how we use it. I agree that conversations don't belong in
> bugzilla, but I think conversation summaries added to bugzilla with
> "Enhancement" tags could be effective organisation.
>
> Of course, I guess summary emails of feature conversations are effective,
> too.
The question is, what problem are we trying to solve?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug
10203] - Docs referenced by XSLT's document() are not included in cache
validity)
Posted by Andrew Savory <an...@luminas.co.uk>.
On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:
> hey, you sound like RMS, scary ;-)
I have my beard and sandles on back-order!
> but don't impose bugzilla as the center of our work organization, it's
> just too bad. :-(
It depends how we use it. I agree that conversations don't belong in
bugzilla, but I think conversation summaries added to bugzilla with
"Enhancement" tags could be effective organisation.
Of course, I guess summary emails of feature conversations are effective,
too.
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
Orixo alliance: http://www.orixo.com/ Web: www.luminas.co.uk
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Oct 9, 2003, at 16:05 Europe/Rome, Andrew Savory wrote:
>
> Hi,
>
> On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:
>
>> Forrest uses Jira. Jira is much better than bugzilla. Jeff works for
>> the company that produces it. There is also a migration tool between
>> bugzilla and Jira. It's commercial, but free for open source use.
>>
>> I would be +1 to migrate to Jira.
>
> -1 for Jira.
>
> Sorry Stefano, but I don't believe we should be using proprietary
> software
> for critical infrastructure.
>
> - We would have no access to the source code
> - We would have to rely on a single organisation for development and
> support
> - We have no guarantee that the license would be in perpetuity (I can't
> find a copy of the license on their site).
>
> For open source bts, Atlassian recommend bugzilla.
> http://www.atlassian.com/software/jira/docs/latest/
> faq.html#is_jira_open_source
>
> I know bugzilla's interface can be tiresome, but it _does_ do the job,
> it's tested and deployed worldwide, and it is free/libre.
hey, you sound like RMS, scary ;-)
all right, all right. don't want to fight but just remember that
Forrest uses Jira (which is also installed already on cocoondev.org)
and that i believe Jeff would patch a bug report much faster than you
could do with the bugzilla source code in hand (having perl sourcecode
or java binary code, IMO, it's the same thing)
but I agree on your third point: locking could be applied (even if a
very bad move for them).
but don't impose bugzilla as the center of our work organization, it's
just too bad. :-(
--
Stefano.
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug
10203] - Docs referenced by XSLT's document() are not included in cache
validity)
Posted by Andrew Savory <an...@luminas.co.uk>.
Hi,
On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:
> Forrest uses Jira. Jira is much better than bugzilla. Jeff works for
> the company that produces it. There is also a migration tool between
> bugzilla and Jira. It's commercial, but free for open source use.
>
> I would be +1 to migrate to Jira.
-1 for Jira.
Sorry Stefano, but I don't believe we should be using proprietary software
for critical infrastructure.
- We would have no access to the source code
- We would have to rely on a single organisation for development and support
- We have no guarantee that the license would be in perpetuity (I can't
find a copy of the license on their site).
For open source bts, Atlassian recommend bugzilla.
http://www.atlassian.com/software/jira/docs/latest/faq.html#is_jira_open_source
I know bugzilla's interface can be tiresome, but it _does_ do the job,
it's tested and deployed worldwide, and it is free/libre.
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
Orixo alliance: http://www.orixo.com/ Web: www.luminas.co.uk
Re: Track feature requests in bugzilla?
Posted by Tony Collen <co...@umn.edu>.
Tony Collen wrote:
> The PHP bug report page is located at http://bugs.php.net/. It looks
> like they are using something they wrote themselves.
I'd also like to note that the PHP.net bugs page is FAST. Way faster than Bugzilla. Run a query to
find all open bugs, and browse page by page ("Next 10 results", etc). It feels very snappy, which I
like.
Tony
Re: Track feature requests in bugzilla?
Posted by Tony Collen <co...@umn.edu>.
Torsten Curdt wrote:
&snip;
> any project that has already been going down that road?
> maybe we could borrow scripts etc...
>
> what are the php guys using anyway?
> IIRC I liked that interface more than bugzilla
The PHP bug report page is located at http://bugs.php.net/. It looks like they are using something
they wrote themselves.
> Torsten
>
Regards,
Tony
Re: Track feature requests in bugzilla?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Vendredi, 10 oct 2003, à 10:41 Europe/Zurich, David Crossley a écrit
:
> ...You must be missing it. I use that feature all the time. I have
> a few queries stored in my Bugzilla user space: cocoon2-outstanding
> and cocoon2-major
>
> Look for the "Remember this query, and name it" feature on the query
> page....
<crawling-under-the-table>
err..blush...I was not logged in to bugzilla ;-)
It's this age thing again I guess, sorry for the noise.
</crawling-under-the-table>
> I am quite happy with using Bugzilla and see no need to change.
so am I, except for a non-urgent upgrade to a newer version.
-Bertrand
Re: Track feature requests in bugzilla?
Posted by David Crossley <cr...@indexgeo.com.au>.
Bertrand Delacretaz wrote:
> Joerg Heinicke a écrit:
> > Bertrand Delacretaz wrote:
> >
> >> ...Finally, saved queries help a lot, you can create the 4-5 queries
> >> that you need regularly and then mostly forget about the query page.
> >> I don't know if they exist in the 2.14.2 version that we're using,
> >> but if they are they seem to be disabled (Pier?).
> >
> > No, I'm using them heavily. One for Cocoon, one for XSLTC, ... And
> > they are simple to use with an URL like
> > http://nagoya.apache.org/bugzilla/
> > buglist.cgi?&cmdtype=runnamed&namedcmd=Cocoon. Why do you think they
> > are disabled?
>
> You mean "saving bookmarks to queries", right?
> In 2.16 you can actually save a query, give it a name and it can appear
> as a link at the bottom of the bugzilla page when you're logged in,
> it's much more convenient and stays on the server.
>
> According to http://nagoya.apache.org/bugzilla/queryhelp.cgi#therest
> this seems to exist in our version, but I don't see the corresponding
> fields on the query form. Am I overlooking something?
You must be missing it. I use that feature all the time. I have
a few queries stored in my Bugzilla user space: cocoon2-outstanding
and cocoon2-major
Look for the "Remember this query, and name it" feature on the query
page.
I am quite happy with using Bugzilla and see no need to change.
--David
Re: Track feature requests in bugzilla?
Posted by Joerg Heinicke <jh...@virbus.de>.
Bertrand Delacretaz wrote:
>>> ...Finally, saved queries help a lot, you can create the 4-5 queries
>>> that you need regularly and then mostly forget about the query page.
>>> I don't know if they exist in the 2.14.2 version that we're using,
>>> but if they are they seem to be disabled (Pier?).
>>
>> No, I'm using them heavily. One for Cocoon, one for XSLTC, ... And
>> they are simple to use with an URL like
>> http://nagoya.apache.org/bugzilla/
>> buglist.cgi?&cmdtype=runnamed&namedcmd=Cocoon. Why do you think they
>> are disabled?
>
> You mean "saving bookmarks to queries", right?
> In 2.16 you can actually save a query, give it a name and it can appear
> as a link at the bottom of the bugzilla page when you're logged in,
> it's much more convenient and stays on the server.
No, I have different queries in my footer. I have to login to use them.
Nothing about bookmarks.
> According to http://nagoya.apache.org/bugzilla/queryhelp.cgi#therest
> this seems to exist in our version, but I don't see the corresponding
> fields on the query form. Am I overlooking something?
If I go to http://nagoya.apache.org/bugzilla/query.cgi I have this part
of the form at the end of the page above the footer.
Joerg
Re: Track feature requests in bugzilla?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Vendredi, 10 oct 2003, à 10:11 Europe/Zurich, Joerg Heinicke a écrit
:
> Bertrand Delacretaz wrote:
>
>> ...Finally, saved queries help a lot, you can create the 4-5 queries
>> that you need regularly and then mostly forget about the query page.
>> I don't know if they exist in the 2.14.2 version that we're using,
>> but if they are they seem to be disabled (Pier?).
>
> No, I'm using them heavily. One for Cocoon, one for XSLTC, ... And
> they are simple to use with an URL like
> http://nagoya.apache.org/bugzilla/
> buglist.cgi?&cmdtype=runnamed&namedcmd=Cocoon. Why do you think they
> are disabled?
You mean "saving bookmarks to queries", right?
In 2.16 you can actually save a query, give it a name and it can appear
as a link at the bottom of the bugzilla page when you're logged in,
it's much more convenient and stays on the server.
According to http://nagoya.apache.org/bugzilla/queryhelp.cgi#therest
this seems to exist in our version, but I don't see the corresponding
fields on the query form. Am I overlooking something?
-Bertrand
Re: Track feature requests in bugzilla?
Posted by Joerg Heinicke <jh...@virbus.de>.
Bertrand Delacretaz wrote:
>>>>
>>>> Another issue is the configuration of bugzilla itself. Isn't it
>>>> customizable? Furthermore more recent versions offer more options.
>>
>>
>> I bet ...but doesn't Bertrand know? :)
>
>
> Newer versions of bugzilla use HTML templates which can make it look
> much nicer if that's the problem. I think it is part of the problem if
> we're going to make more serious use of bugzilla, there's no excuse for
> looking bad on the web today.
>
> Also, the query form in 2.16 has a better layout which helps a lot when
> you start using it.
Good to hear.
> Finally, saved queries help a lot, you can create the 4-5 queries that
> you need regularly and then mostly forget about the query page.
> I don't know if they exist in the 2.14.2 version that we're using, but
> if they are they seem to be disabled (Pier?).
No, I'm using them heavily. One for Cocoon, one for XSLTC, ... And they
are simple to use with an URL like
http://nagoya.apache.org/bugzilla/buglist.cgi?&cmdtype=runnamed&namedcmd=Cocoon.
Why do you think they are disabled?
> An easy workaround if saved queries cannot be enabled for some reason is
> to create more links like the "patch queue" and "open bugs" links that
> we have on the web and wiki. "What happened in the last X days" and
> "what's unassigned" come to mind and are easy to do.
>
> But I agree with Andrew and Jeff that the current bugzilla works - it
> might not be pretty (it is ugly actually), and is lacking in ways of
> classifying issue types, but it does the job if one is willing to use it.
>
> I'm not sure about switching to another tracking system. The "new toy"
> syndrom could help people make more use of it, OTOH if people are not
> willing to use it they will not and we will only have wasted time. A
> bugzilla upgrade might be good though.
>
> My suggestion would be to stay with bugzilla until the next 1-2
> FirstFridays at least and see how we do. Until then, have a vote on
> where we want to track feature requests, bugzilla or wiki will both work
> for these IMHO, this is not such a big deal.
+1
Joerg
Re: Track feature requests in bugzilla?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Vendredi, 10 oct 2003, à 00:26 Europe/Zurich, Torsten Curdt a écrit :
> <snip/>
>
>>> Thanks for the information.
>>>
>>> If there is no real alternative to bugzilla, we should use it.
>> Ah, BTW, Scarab *is* better than bugzilla and stable enough for
>> use... I just heard it's a pain to migrate stuff from bugzilla.
>
> any project that has already been going down that road?
> maybe we could borrow scripts etc...
On the scarab front page they say that it supports XML importing.
Exporting our current bugzilla stuff to XML is not hard (with Cocoon
for example ;-)
>>> ...
>>> Another issue is the configuration of bugzilla itself. Isn't it
>>> customizable? Furthermore more recent versions offer more options.
>
> I bet ...but doesn't Bertrand know? :)
Newer versions of bugzilla use HTML templates which can make it look
much nicer if that's the problem. I think it is part of the problem if
we're going to make more serious use of bugzilla, there's no excuse for
looking bad on the web today.
Also, the query form in 2.16 has a better layout which helps a lot when
you start using it.
Finally, saved queries help a lot, you can create the 4-5 queries that
you need regularly and then mostly forget about the query page.
I don't know if they exist in the 2.14.2 version that we're using, but
if they are they seem to be disabled (Pier?).
An easy workaround if saved queries cannot be enabled for some reason
is to create more links like the "patch queue" and "open bugs" links
that we have on the web and wiki. "What happened in the last X days"
and "what's unassigned" come to mind and are easy to do.
But I agree with Andrew and Jeff that the current bugzilla works - it
might not be pretty (it is ugly actually), and is lacking in ways of
classifying issue types, but it does the job if one is willing to use
it.
I'm not sure about switching to another tracking system. The "new toy"
syndrom could help people make more use of it, OTOH if people are not
willing to use it they will not and we will only have wasted time. A
bugzilla upgrade might be good though.
My suggestion would be to stay with bugzilla until the next 1-2
FirstFridays at least and see how we do. Until then, have a vote on
where we want to track feature requests, bugzilla or wiki will both
work for these IMHO, this is not such a big deal.
Ciao,
Bertrand
Re: Track feature requests in bugzilla?
Posted by Torsten Curdt <tc...@vafer.org>.
<snip/>
>> Thanks for the information.
>>
>> If there is no real alternative to bugzilla, we should use it.
>
>
> Ah, BTW, Scarab *is* better than bugzilla and stable enough for use... I
> just heard it's a pain to migrate stuff from bugzilla.
any project that has already been going down that road?
maybe we could borrow scripts etc...
what are the php guys using anyway?
IIRC I liked that interface more than bugzilla
>> Another issue is the configuration of bugzilla itself. Isn't it
>> customizable? Furthermore more recent versions offer more options.
I bet ...but doesn't Bertrand know? :)
Bertrand?
--
Torsten
Re: Track feature requests in bugzilla?
Posted by Joerg Heinicke <jh...@virbus.de>.
Stefano Mazzocchi wrote:
>>> nono, you missed my point: bugzilla forces discussion to happen over
>>> the issue comments. wiki, since it's hard to do communication
>>> overthere (as you suggest), forces you to write comments on email,
>>> like it should be.
>>
>> And what's so bad about communication on bugzilla? Every mail is sent
>> to the lists. The issues can also be discussed on the list by simply
>> replying to an email. The only missing point is the "real" sender of a
>> mail for bugzilla comments, isn't it?
>
> yes, and the ability to sort messages in threads since every bugzilla
> email is detached.
Ah, ok. Mozilla does this for me by comparing the subject - but if the
bug is reported, so the mail has an additional "new" in the subject, or
if the bug summary changes, Mozilla fails of course.
Joerg
Re: Track feature requests in bugzilla?
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Oct 9, 2003, at 21:18 Europe/Rome, Joerg Heinicke wrote:
> Stefano Mazzocchi wrote:
>
>>>> also, i don't want to do conversations over bugzilla, it's painful
>>>> and removes the ability to estimate people relationships (think >>
>>>> agora)
>>>
>>> Hmm, stupid answer, but is it better to communicate over the wiki? I
>>> don't think so.
>> nono, you missed my point: bugzilla forces discussion to happen over
>> the issue comments. wiki, since it's hard to do communication
>> overthere (as you suggest), forces you to write comments on email,
>> like it should be.
>
> And what's so bad about communication on bugzilla? Every mail is sent
> to the lists. The issues can also be discussed on the list by simply
> replying to an email. The only missing point is the "real" sender of a
> mail for bugzilla comments, isn't it?
yes, and the ability to sort messages in threads since every bugzilla
email is detached.
>> Scarab is cool, but like every tigris project seems to be in
>> continous alpha mode and has been so for years. This is unlikely to
>> change fast.
>
> Thanks for the information.
>
> If there is no real alternative to bugzilla, we should use it.
Ah, BTW, Scarab *is* better than bugzilla and stable enough for use...
I just heard it's a pain to migrate stuff from bugzilla.
> Nowhere else information about specific issues are collected so
> compactly.
true
> Mailing lists must be searched for an issue like a haystack for the
> needle (it's overstated but I think you know what I mean).
true
I'm not against it, I just suggest we don't use it for communication.
> Another issue is the configuration of bugzilla itself. Isn't it
> customizable? Furthermore more recent versions offer more options.
I'll gladly let you guys take care of this ;-)
--
Stefano.
Re: Track feature requests in bugzilla?
Posted by Joerg Heinicke <jh...@virbus.de>.
Stefano Mazzocchi wrote:
>>> also, i don't want to do conversations over bugzilla, it's painful
>>> and removes the ability to estimate people relationships (think >>
>>> agora)
>>
>> Hmm, stupid answer, but is it better to communicate over the wiki? I
>> don't think so.
>
> nono, you missed my point: bugzilla forces discussion to happen over the
> issue comments. wiki, since it's hard to do communication overthere (as
> you suggest), forces you to write comments on email, like it should be.
And what's so bad about communication on bugzilla? Every mail is sent to
the lists. The issues can also be discussed on the list by simply
replying to an email. The only missing point is the "real" sender of a
mail for bugzilla comments, isn't it?
> Scarab is cool, but like every tigris project seems to be in continous
> alpha mode and has been so for years. This is unlikely to change fast.
Thanks for the information.
If there is no real alternative to bugzilla, we should use it. Nowhere
else information about specific issues are collected so compactly.
Mailing lists must be searched for an issue like a haystack for the
needle (it's overstated but I think you know what I mean).
Another issue is the configuration of bugzilla itself. Isn't it
customizable? Furthermore more recent versions offer more options.
Joerg
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Oct 9, 2003, at 14:51 Europe/Rome, Joerg Heinicke wrote:
>> also, i don't want to do conversations over bugzilla, it's painful
>> and removes the ability to estimate people relationships (think >> agora)
>
> Hmm, stupid answer, but is it better to communicate over the wiki? I
> don't think so.
nono, you missed my point: bugzilla forces discussion to happen over
the issue comments. wiki, since it's hard to do communication overthere
(as you suggest), forces you to write comments on email, like it should
be.
> Does anybody know the status of the move to Scarab? Is it project
> dependent? Does Scarab improve the usability/issue category handling?
Forrest uses Jira. Jira is much better than bugzilla. Jeff works for
the company that produces it. There is also a migration tool between
bugzilla and Jira. It's commercial, but free for open source use.
Scarab is cool, but like every tigris project seems to be in continous
alpha mode and has been so for years. This is unlikely to change fast.
I would be +1 to migrate to Jira.
--
Stefano.
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug
10203] - Docs referenced by XSLT's document() are not included in cache
validity)
Posted by Joerg Heinicke <jh...@virbus.de>.
Stefano Mazzocchi wrote:
>
>>> However,
>>> can't we use bugzilla also to track (serious) feature requests? There
>>> are a couple of other "enhancement" requests in there, should we also
>>> close them and add them to the wiki page?
>>
>> We created
>> http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatureRequests Monday
>> in the frenzy of the Hackathon, but IMHO (and in retrospect) having
>> them in Bugzilla makes more sense.
>>
>> The Wiki page can then explain how we handle them and include a
>> bugzilla link to the list of currently open feature requests.
>>
>> We have to be clear on how we separate them from bugs though, I think
>> feature requests should all have priority=Enhancment, is that ok? And
>> what about [PATCH]es?
>
> I'm sorry, but I hate bugzilla enough, we should try to reduce its use
> rather than increase it. it's usability is terrible, it's a punch in the
> face everytime you try to do something.
But as long as it is in use we should it use as much as possible. Dividing
issues on many resource locations does not help.
> the wiki is much friendlier and feature requests are not something that
> requires lots of structure (rather the opposite).
It's only the thing of having similar thing on different locations.
> also, i don't want to do conversations over bugzilla, it's painful and
> removes the ability to estimate people relationships (think agora)
Hmm, stupid answer, but is it better to communicate over the wiki? I don't
think so.
Does anybody know the status of the move to Scarab? Is it project dependent?
Does Scarab improve the usability/issue category handling?
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: Track feature requests in bugzilla?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Jeudi, 9 oct 2003, à 14:33 Europe/Zurich, Stefano Mazzocchi a écrit :
> ...I'm sorry, but I hate bugzilla enough, we should try to reduce its
> use rather than increase it. it's usability is terrible, it's a punch
> in the face everytime you try to do something.
>
> the wiki is much friendlier and feature requests are not something
> that requires lots of structure (rather the opposite)...
In my view, bugzilla (or any better tool if there is one) could/should
be used for the following issues:
-bugs
-patches
-release coordination: have a script enter issues in bugzilla before
doing the release, a "master issue" which is the release and depends on
other issues representing the tests that must be performed
-feature requests
Which ones do you like today, and which ones would you like with a
better tracking tool?
I don't terribly mind using the wiki for feature requests/wishlists,
just trying to understand your point of view.
> ...also, i don't want to do conversations over bugzilla, it's painful
> and removes the ability to estimate people relationships (think agora)
Although I'm a fan of tracking tools, I agree that in our case
dispersing conversations would not be optimal.
-Bertrand
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Oct 9, 2003, at 12:01 Europe/Rome, Bertrand Delacretaz
wrote:
> Le Jeudi, 9 oct 2003, à 11:42 Europe/Zurich, Bruno Dumon a écrit :
>> ...I agree it's a feature request and added it to the wiki page.
>> However,
>> can't we use bugzilla also to track (serious) feature requests? There
>> are a couple of other "enhancement" requests in there, should we also
>> close them and add them to the wiki page?
>
> We created
> http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatureRequests Monday
> in the frenzy of the Hackathon, but IMHO (and in retrospect) having
> them in Bugzilla makes more sense.
>
> The Wiki page can then explain how we handle them and include a
> bugzilla link to the list of currently open feature requests.
>
> We have to be clear on how we separate them from bugs though, I think
> feature requests should all have priority=Enhancment, is that ok? And
> what about [PATCH]es?
I'm sorry, but I hate bugzilla enough, we should try to reduce its use
rather than increase it. it's usability is terrible, it's a punch in
the face everytime you try to do something.
the wiki is much friendlier and feature requests are not something that
requires lots of structure (rather the opposite).
also, i don't want to do conversations over bugzilla, it's painful and
removes the ability to estimate people relationships (think agora)
--
Stefano.
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Jeudi, 9 oct 2003, à 11:42 Europe/Zurich, Bruno Dumon a écrit :
> ...I agree it's a feature request and added it to the wiki page.
> However,
> can't we use bugzilla also to track (serious) feature requests? There
> are a couple of other "enhancement" requests in there, should we also
> close them and add them to the wiki page?
We created
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatureRequests Monday in
the frenzy of the Hackathon, but IMHO (and in retrospect) having them
in Bugzilla makes more sense.
The Wiki page can then explain how we handle them and include a
bugzilla link to the list of currently open feature requests.
We have to be clear on how we separate them from bugs though, I think
feature requests should all have priority=Enhancment, is that ok? And
what about [PATCH]es?
-Bertrand
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Oct 9, 2003, at 11:42 Europe/Rome, Bruno Dumon wrote:
>> ------- Additional Comments From cziegeler@apache.org 2003-10-08
>> 17:28 -------
>> Ah, ok you're right. Although I guess that it's technical possible it
>> will get
>> even more messy than the whole caching code is already.
>> In my opinion, it's sufficient to document this behaviour. Users can
>> take care
>> of it - if they know.
>>
>> On the other hand, I think this is more a feature request than a bug.
>> So I
>> suggest to add this to our feature request page at the wiki and close
>> this bug.
>> Or you can start a vote if this is more a bug or more a feature
>> request first.
>
> I agree it's a feature request and added it to the wiki page. However,
> can't we use bugzilla also to track (serious) feature requests? There
> are a couple of other "enhancement" requests in there, should we also
> close them and add them to the wiki page?
+1
--
Stefano.