You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Pier Fumagalli <pi...@betaversion.org> on 2005/09/12 20:10:07 UTC
Shall we switch to Jira?
Just an idea... I'm used to work on it at work, and it's quite an
improvement on Bugzilla, and allows things like:
http://issues.apache.org/jira/secure/IssueNavigator.jspa?
view=rss&&query=cocoon&summary=true&description=true&body=true&tempMax=2
5&reset=true&decorator=none
Pier
Re: Creating a Bugzilla RSS feed using Cocoon
Posted by BURGHARD Éric <er...@systheo.com>.
Hi,
I tryed jira when i was looking for a bug-tracking system for my project,
and finally prefered bugzilla for its simplicity (well my project is not as
big as cocoon), even if i found it quite ugly compared to jira.
Then i found Trac[1], i think it could be valuable for cocoon if you look
for a bugzilla replacement candidat. You should definitively try a look at
it. It's extremly simple and usefull.
It can replace your wiki, your subversion browser and bugzilla. It provide
very clean bugs reports (fully customisable), milestones status with
charts[2]. Perhaps the most usefull feature is that you can link every
information from all the parts.
All texts can be writen with a wiki syntax[3]: commit message, wiki pages,
milestone descriptions, ticket description/comment. Syntax coloring is
available for your code snippets (js,sql,java,c,...).
The linking feature is perhaps the most usefull. I can wrote in every part
of Trac, something like
* 'see #314' to provide a link to bug 314 description
* 'see [312]' for link to repository revision 312
* 'see {4}' for a link to a custom bug report (n°4)
* 'milestone:brouzouf' for a link to the milestone description. Milestone
view provide a clean charts component by component to see on which part you
should concentrate.
* 'see CFormsBinding' for a link to a wiki page
* 'see source:cocoon/trunk/build.xml' for a link to a particular source in
the repository
After that, looking for every aspect of your developpement (roadmap,
tickets, sources, specs) is just a matter of clics.
One problem with bugzilla or other tracking systems is that you should
manually synchronise bugs and revisions. With Trac, some hook scripts are
provided for subversion which interpret commit messages like
"blabla. fixe #56, ref #314 ad #254"
and automaticly close ticket #56 and add the commit message to ticket #314
and #254 without the need to go into the bugtracking system.
Tickets[4] report are fully customisable. RSS feeds[5] are provided for
every aspect of Trac (tikets, reports, wiki changes, milestone changes),
separated or mixed. The subversion browser[6] is better that WebSVN.
Finally, it's ligth, really easy to install and setup, and easy to modify
(python). There is a bunch of wiki macros[7] that let you add TOC,
FootNotes, SideMenus, Tags, to your pages (plugins).
The migration from bugzilla is painless (at least for 2.16, but i submit a
patch for bugzilla 2.18), and you can import all your MoinMoinWiki pages.
My 0.2€
Regards
[1] http://projects.edgewall.com/trac/
[2] http://projects.edgewall.com/trac/milestone/0.9
[3] http://projects.edgewall.com/trac/wiki/TracWiki
[4] http://projects.edgewall.com/trac/report
[5] http://projects.edgewall.com/trac/wiki/TracRss
[6] http://projects.edgewall.com/trac/browser
[7] http://projects.edgewall.com/trac/wiki/MacroBazaar
Re: Creating a Bugzilla RSS feed using Cocoon
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 13 Sep 2005, at 11:19, Jean-Baptiste Quenot wrote:
> * Sylvain Wallez:
>
>> Bugzilla provides iCal todo lists, not as versatile as RSS though.
>
> Bugzilla and RSS? It is possible:
>
> <map:match pattern="bugzilla">
> <map:generate src="{request-param:url}&ctype=csv"
> type="csv"/>
> <map:transform src="xsl/bugzilla-csv2rss.xsl">
> <map:parameter name="bugzilla" value="{request-param:url}"/>
> </map:transform>
> <map:serialize type="xml"/>
> </map:match>
>
> See http://svn.caraldi.com/trunk/www/webapps/portal/portal/
> sitemap.xmap
> and http://svn.caraldi.com/trunk/www/webapps/portal/portal/xsl/
> bugzilla-csv2rss.xsl
Hihihihi! Who do you think wrote the CSV generator in the very first
place?
The thing with having Jira to do it is that each one of us (without
running a Cocoon instance) can subscribe to a very own and
personalized feed of the bugs we're interested in directly, without
interfering with each other's work.
What I particularly like about Jira is the degree of personal
customization that it allows. Each user "profile" can have different
reports / filters, and for each of them one can decide what to do,
save it, have the report emailed on a regular interval, expose it as
a RSS feed, ... or (as my boss likes it) as an Excel file (luz3r!)
Plus, the view I like the most for long-ish term project planning, is
the "Roadmap" view, which is quite cool to view at what stage a
release is...
Overall, in my personal experience, it's a lot better than BugZilla,
but, hey, that's me.
Pier
Re: Creating a Bugzilla RSS feed using Cocoon
Posted by Jean-Baptiste Quenot <jb...@anyware-tech.com>.
* Sylvain Wallez:
> Bugzilla provides iCal todo lists, not as versatile as RSS though.
Bugzilla and RSS? It is possible:
<map:match pattern="bugzilla">
<map:generate src="{request-param:url}&ctype=csv" type="csv"/>
<map:transform src="xsl/bugzilla-csv2rss.xsl">
<map:parameter name="bugzilla" value="{request-param:url}"/>
</map:transform>
<map:serialize type="xml"/>
</map:match>
See http://svn.caraldi.com/trunk/www/webapps/portal/portal/sitemap.xmap
and http://svn.caraldi.com/trunk/www/webapps/portal/portal/xsl/bugzilla-csv2rss.xsl
Enjoy,
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/
Re: Shall we switch to Jira?
Posted by Antonio Gallardo <ag...@agssa.net>.
Sylvain Wallez wrote:
> Pier Fumagalli wrote:
>
>> Just an idea... I'm used to work on it at work, and it's quite an
>> improvement on Bugzilla, and allows things like:
>>
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?
>> view=rss&&query=cocoon&summary=true&description=true&body=true&tempMax=2
>> 5&reset=true&decorator=none
>
>
>
> Bugzilla provides iCal todo lists, not as versatile as RSS though.
Not now, but in the next version yes:
http://www.bugzilla.org/releases/2.20/new-features.html#rss
Best Regards,
Antonio Gallardo.
Re: Shall we switch to Jira?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jorg Heymans wrote:
> Vadim Gritsenko wrote:
>
>>We don't need that crap. It is problem enough that half of the time you
>>can't do much in Jira while working with other projects, no need to
>
> what do you mean? You can't have multiple instances running in one browser?
I rather meant that most of the time you can't do much of what you can with
bugzilla. May be it was due to too restrictive setup (and i mean this, asf
setup), may be due to my extreme stupidity so I can't figure out how to close or
reopen or do something else in jira.
Vadim
Re: Shall we switch to Jira?
Posted by Jorg Heymans <jh...@domek.be>.
Vadim Gritsenko wrote:
>
> We don't need that crap. It is problem enough that half of the time you
> can't do much in Jira while working with other projects, no need to
>
what do you mean? You can't have multiple instances running in one browser?
Jorg
Re: Shall we switch to Jira?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Pier Fumagalli wrote:
> On 13 Sep 2005, at 16:40, Vadim Gritsenko wrote:
>
>> IMNSHO, it's a deal breaker if our own users can't mess with our own
>> bug database. (*)
>
> I would be against to have anyone who logged in to completely whack the
> status of any bug in the DB, but if that is desirable for Cocoon, it
You'd be against it for Cocoon or in the enterprise environment? In the
enterprise, they have all kind of kinks: RUP, CMM, etc. In the world out there,
I've not seen Cocoon users abusing bug tracking system - on the contrary, only
helping.
> can be done with a simple configuration of the policies associated with
> the Cocoon project.
Good!
Vadim
Re: Shall we switch to Jira?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 13 Sep 2005, at 16:40, Vadim Gritsenko wrote:
> Pier Fumagalli wrote:
>> On 13 Sep 2005, at 15:25, Vadim Gritsenko wrote:
>>
>> There are normally big buttons on the left of the UI that
>> depending on the current status of an issue, allow you to move to
>> the next ones: for example if a bug is "open" you have links to
>> "close" and "resolve and close" on the left, it will ask for an
>> activity comment and change the status.
>>
>
> Examples
> http://issues.apache.org/jira/browse/JCR-169
> http://issues.apache.org/jira/browse/JCR-188
>
> No 'Close', no 'Reopen', only 'Clone' and some such. And it's not
> limited to JCR. And I'm currently logged in - not an anonymous
> browsing.
Nonono... That's a problem with permissions. Are you a committer to
Jackrabbit? Have the Jackrabbit group given permissions to any logged
in users to fiddle about with their bugs? Or are people not in the
Jackrabbit group only allowed to further comment on issues, but not
(for example) to modify their status?
That's all up to the configuration for each individual project.
> IMNSHO, it's a deal breaker if our own users can't mess with our
> own bug database. (*)
I would be against to have anyone who logged in to completely whack
the status of any bug in the DB, but if that is desirable for Cocoon,
it can be done with a simple configuration of the policies associated
with the Cocoon project.
>>> Constructive comment would be;
>>>
>>> * What it does better?
>>>
>> Per-user customization is (IMVHO) one of the coolest things in
>> there, and the reports integrated in Jira are killer. I
>> personally use it also to track and link automagically bugs from
>> Subversion commits with the Jira subversion plugin and ViewSVN,
>> so, no more fix a bug in SVN, copy and paste the commit message,
>> modify the bug tracking database. Jira picks it up automatically
>> (I don't know if Bugzilla does the same nowadays).
>
> So is this stuff configured at issues.apache.org too?
I don't know... It simply would entail a simple copy of a file in the
JIRA WEB-INF/lib directory and a quick restart. Nothing major in
terms of setup (Took me no more than 2 minutes on our local Jira
installation).
>> Every single friggin label (also) is customizable, statuses,
>> component, fields, EVERYTHING can be added or removed, so for
>> every project/component/issue-type one can have different
>> fields / requirements depending on the real needs of the project.
>
> That's on one side - on the other each project's jira can be made
> so different that you'll momentarily get lost :) Sounds like FS to
> me :)
Not really... Cocoon, for example, has quite a different setup from
all the other projects and I can see aspects for which certain fields
might be introduced only for us. For example, something that defines
if the bug is encountered in the "XCONF" "SAMPLES" "JAVA" or "MOCKS"
part of a "BLOCK" (kinda like subcomponent).
>> Customizable issues linking. Not only "mark as duplicate of this
>> bug", but also, this task / bug / xxx requires the resolution of,
>> is related to, is a duplicate of, blablabla (customizable).
>
> Bugzilla (as I see) has only Depends, Blocks, Duplicate. Not
> customizable but covers many usecases.
It's restrictive for when someone wants to track status on complex
bugs... Especially for blocks (and even more when we'll have real
blocks) I can see a situation in which the dependancy tree might have
to be extended to cover other variations of relationship... But
that's me.
>> Version management: not only one can specify in what version one
>> found a bug, but also in what version it will be fixed, so that
>> we can have clear roadmaps of what has been found in what
>> versions, and what was (needs to be) fixed in what version.
>
> It seems bugzilla has 'Target Milestone' for this. Not used in
> Cocoon's bugzilla.
I bet it's unused... Why would you want to enter a version twice?
Both in the "Versions" and in the "Milestones"? And as far as I can
see, I don't see any reports over them: no, clicking at the bottom to
go to the "search", then clicking at the top to go to "advanced
search" filling in a page with proably 50 input boxes, and with ALL
milestones / versions displayed for ALL project until I don't select
"Cocoon 2" is not what I call a usable report :-) (Read, usability at
the end, as you said). I prefer my two-clicks on Jira to get to the
point! :-P
>>> * Is it faster?
>>>
>> Yes in my particular experience. The search provided by Lucene/
>> Jira is faster than the one provided by SQL/BugZilla. It depends
>> (though) on how it's installed, how much ram the VM has, and so
>> on and so forth.
>> As far as I can see, looking for the word "cocoon" in Jira gives
>> me a first page of results in roughly one second, on and Bugzilla
>> it takes roughly 2.5 (but that might be my internet connection,
>> the specific query, blablabla). In other words, my experience.
>
> Well direct access to the bug usually takes 5-10 secs in jira
> (unless cached?), and 1-5 secs in bugzilla. Advanced search might
> be faster in jira - dunno.
Never experienced that delay (not even on the ASF installation), but
I might have hit bugs that were always cached. Or maybe just because
from the office we have quite a large pipe going down directly to
Holland (VNU is a NL company, and our hosting facility over there is
the same as AJAX, the one running issues.apache.org).
>>> I tried using it, and (IMVHO) it fails on last two points and
>>> has hard-to-read-at-a-glance UI.
>>>
>> Agreed, the user interface is far from perfect (and Apache's
>> choice of colors makes it even uglier), but IMVO Bugzilla's worse.
>
> Summarizing above, I don't mind giving it a try as long as (*)
> above is resolved somehow (either throw my education or jira
> configuration, that's it :-p).
As I said, (*) above is probably just because you're not part of a
particular group, and that particular group doesn't want other people
to fiddle too much with their issues.
Pier
Re: Shall we switch to Jira?
Posted by Jorg Heymans <jh...@domek.be>.
Vadim Gritsenko wrote:
> Summarizing above, I don't mind giving it a try as long as (*) above is
Same here.
If it's as good as Pier says then we could really benefit from these
features once the new monthly (or was it bi-monthly) release policy
starts - which will require much tighter issue administration IMO.
Jorg
Re: Shall we switch to Jira?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jeroen Reijn wrote:
> Vadmin,
Name is Vadim :-)
> looks to me that this is a configuration option somewhere. I've been
> using JIRA for a while now and really like it.
Seems like wrong permissions, as Pier noticed.
> You can do a lot more with JIRA then you've seen so far.
Can I do it faster? :)
I get noticeably slower jira access over here vs bugzilla.
Vadim
> Take a look at this screenshot:
>
> http://www.xs4all.nl/~reijnj/images/jirascreenshot.gif
>
> Or just sign-up for a test account at http://jira.atlassian.com/
>
> Greetz,
>
> Jeroen
Re: Shall we switch to Jira?
Posted by Jeroen Reijn <j....@hippo.nl>.
Vadmin,
looks to me that this is a configuration option somewhere. I've been using JIRA
for a while now and really like it.
You can do a lot more with JIRA then you've seen so far.
Take a look at this screenshot:
http://www.xs4all.nl/~reijnj/images/jirascreenshot.gif
Or just sign-up for a test account at http://jira.atlassian.com/
Greetz,
Jeroen
Vadim Gritsenko wrote:
> Pier Fumagalli wrote:
>
>> On 13 Sep 2005, at 15:25, Vadim Gritsenko wrote:
>>
>>> It's really frustrating when you can't change bug status or do some
>>> other tasks. That's what I meant; I presume that's part of
>>> 'customized workflows' feature.
>>
>>
>> You can't change the bug status? That's really freaky. The status as
>> in "open", "resolved", "closed" ... ?
>
>
> Yes.
>
>> There are normally big buttons on the left of the UI that depending
>> on the current status of an issue, allow you to move to the next
>> ones: for example if a bug is "open" you have links to "close" and
>> "resolve and close" on the left, it will ask for an activity comment
>> and change the status.
>
>
> Examples
> http://issues.apache.org/jira/browse/JCR-169
> http://issues.apache.org/jira/browse/JCR-188
>
> No 'Close', no 'Reopen', only 'Clone' and some such. And it's not
> limited to JCR. And I'm currently logged in - not an anonymous browsing.
>
> IMNSHO, it's a deal breaker if our own users can't mess with our own bug
> database. (*)
>
>
>>> Constructive comment would be;
>>>
>>> * What it does better?
>>
>>
>>
>> Per-user customization is (IMVHO) one of the coolest things in there,
>> and the reports integrated in Jira are killer. I personally use it
>> also to track and link automagically bugs from Subversion commits
>> with the Jira subversion plugin and ViewSVN, so, no more fix a bug in
>> SVN, copy and paste the commit message, modify the bug tracking
>> database. Jira picks it up automatically (I don't know if Bugzilla
>> does the same nowadays).
>
>
> So is this stuff configured at issues.apache.org too?
>
>
>> Every single friggin label (also) is customizable, statuses,
>> component, fields, EVERYTHING can be added or removed, so for every
>> project/component/issue-type one can have different fields /
>> requirements depending on the real needs of the project.
>
>
> That's on one side - on the other each project's jira can be made so
> different that you'll momentarily get lost :) Sounds like FS to me :)
>
>
>> Multiple components per bug. If for example a bug affects more than
>> one part of the system (validation block , samples , sitemap
>> configuration ) they can all be assigned to the same issue.
>
>
> That's good.
>
>
>> Customizable issues linking. Not only "mark as duplicate of this
>> bug", but also, this task / bug / xxx requires the resolution of, is
>> related to, is a duplicate of, blablabla (customizable).
>
>
> Bugzilla (as I see) has only Depends, Blocks, Duplicate. Not
> customizable but covers many usecases.
>
>
>> Version management: not only one can specify in what version one
>> found a bug, but also in what version it will be fixed, so that we
>> can have clear roadmaps of what has been found in what versions, and
>> what was (needs to be) fixed in what version.
>
>
> It seems bugzilla has 'Target Milestone' for this. Not used in Cocoon's
> bugzilla.
>
>
>>> * Is it faster?
>>
>>
>> Yes in my particular experience. The search provided by Lucene/Jira
>> is faster than the one provided by SQL/BugZilla. It depends (though)
>> on how it's installed, how much ram the VM has, and so on and so forth.
>>
>> As far as I can see, looking for the word "cocoon" in Jira gives me a
>> first page of results in roughly one second, on and Bugzilla it takes
>> roughly 2.5 (but that might be my internet connection, the specific
>> query, blablabla). In other words, my experience.
>
>
> Well direct access to the bug usually takes 5-10 secs in jira (unless
> cached?), and 1-5 secs in bugzilla. Advanced search might be faster in
> jira - dunno.
>
>
>>> * Is it more stable?
>>
>>
>> In two years of production use of Jira, I never saw it crash once. I
>> believe that the issues related to the stability of Jira on the ASF
>> were tied to the use of Tomcat rather than Jetty (what I personally
>> use in production). And I believe that those were solved when
>> issues.apache.org was moved to AJAX from Nagoya.
>>
>>> I tried using it, and (IMVHO) it fails on last two points and has
>>> hard-to-read-at-a-glance UI.
>>
>>
>>
>> Agreed, the user interface is far from perfect (and Apache's choice
>> of colors makes it even uglier), but IMVO Bugzilla's worse.
>
>
> Summarizing above, I don't mind giving it a try as long as (*) above is
> resolved somehow (either throw my education or jira configuration,
> that's it :-p).
>
> Vadim
Jira pros and cons (Re: Shall we switch to Jira?)
Posted by Jeff Turner <je...@apache.org>.
Hi,
On Tue, Sep 13, 2005 at 11:40:00AM -0400, Vadim Gritsenko wrote:
> Pier Fumagalli wrote:
> > On 13 Sep 2005, at 15:25, Vadim Gritsenko wrote:
> >
> >> It's really frustrating when you can't change bug status or do some
> >> other tasks. That's what I meant; I presume that's part of
> >> 'customized workflows' feature.
...
> Examples
> http://issues.apache.org/jira/browse/JCR-169
> http://issues.apache.org/jira/browse/JCR-188
>
> No 'Close', no 'Reopen', only 'Clone' and some such. And it's not limited to
> JCR. And I'm currently logged in - not an anonymous browsing.
>
> IMNSHO, it's a deal breaker if our own users can't mess with our own bug
> database. (*)
It's a permission set in the JCR project (only developers can
resolve/close). IMHO it's disempowering, kills the do-ocracy spirit and
generally sucks. Probably this was not a deliberate choice of the
project. Someone just copied the permissions when setting up JCR. I'll
start a discussion on infra@ about standardizing on a suitably open
permission scheme.
To address some points made (disclaimer: I work for Atlassian):
1) Speed & search useability
Clicking through JIRA does feel slow compared to Bugzilla, but JIRA has a
search mini-language that means you rarely have to. In JIRA you can type
'VELOCITY open NullPointerException' in the quick search bar on every
page, and you'll get back a list of open Velocity bugs mentioning
NullPointerException in the summary/body. Adding 'v:1.5' limits the
Affects version, adding 'ff:1.6' limits the fix-for version. 'my' limits
to issues assigned to you. 'c:' limits to component.
This can be made even faster. In Firefox, try bookmarking the following
URL, and give it the keyword 'asf':
http://issues.apache.org/jira/secure/QuickSearch.jspa?searchString=%s
Now you can type 'asf VELOCITY open' in the browser, and go directly to
the search results. You can also jump to an individual bug with 'asf
VELOCITY-374'. With this, you rarely need to use the web search UI or
visit the front page.
2) Subversion integration.
Examples at:
http://issues.apache.org/jira/browse/HIVEMIND-103?page=all
http://issues.apache.org/jira/browse/JAMES-253?page=all
http://issues.apache.org/jira/browse/FOR-528?page=all
The actual links are broken at the moment - see
http://issues.apache.org/jira/browse/INFRA-354
(and while you're there, notice the trackback link automatically
established from the Atlassian JIRA:)
3) Decent email support
Given that what most people see from the bug tracker is the emails, I
think this is worth particular attention.
- In JIRA, email notifications 'thread' in mail clients, so
comments/updates on an issue can be grouped with the original issue
creation notification. When reading a comment you can quickly see the
previous comment, or the original issue in the thread.
- The 'From' header includes the name of the changer (not just
'bugzilla@apache.org'). This lets you search/sort for bugs by
reporter/commenter in your mail client.
- IMHO the email format is a bit more readable - no 'DO NOT REPLY'
everywhere.
- Once infra@ people get to it, it WILL be possible to reply to email,
and have the reply added as a comment (see
http://issues.apache.org/jira/browse/INFRA-412).
4) Linking with other OSS projects
JIRA will increase intertwinglyness with related projects, but allowing
internal links to other projects in the ASF JIRA (Lenya, Forrest, Xalan,
Avalon) and trackback links to external JIRA installations (Daisy,
Hibernate, Codehaus projects).
As for downsides:
5) Stability
The ASF JIRA installation does run out of memory occasionally, and about
once every 2 weeks recently. I suspect it's a leak in the SVN parsing,
which the ASF JIRA does an awful lot of. We're working on addressing this
(see infrastructure@ traffic for details).
6) Limited search options
The Bugzilla search form is complicated because you can do lots of cool
stuff in it. JIRA's search capabilities are primitive by comparison.
There's no regexp support, and you can't do arbitrary AND/OR/NOT queries.
This will be addressed eventually - see
http://jira.atlassian.com/browse/JRA-1560
7) Not OSS
JIRA is written by ruthless hippie-bashing capitalists.
-o0o-
Anyway, I suggest importing the Bugzilla issues into Cocoon to let people
play (I think Pier's an admin). The importer can be re-run occasionally,
and the permission scheme configured to let only developers create issues
(for testing). To be honest though, there is no one knock-down
improvement (unless SVN integration counts) - just lots of little ones
that become apparent over time.
--Jeff
> >> Constructive comment would be;
> >>
> >> * What it does better?
> >
> >
> > Per-user customization is (IMVHO) one of the coolest things in there,
> > and the reports integrated in Jira are killer. I personally use it also
> > to track and link automagically bugs from Subversion commits with the
> > Jira subversion plugin and ViewSVN, so, no more fix a bug in SVN, copy
> > and paste the commit message, modify the bug tracking database. Jira
> > picks it up automatically (I don't know if Bugzilla does the same
> > nowadays).
>
> So is this stuff configured at issues.apache.org too?
>
>
> > Every single friggin label (also) is customizable, statuses, component,
> > fields, EVERYTHING can be added or removed, so for every
> > project/component/issue-type one can have different fields /
> > requirements depending on the real needs of the project.
>
> That's on one side - on the other each project's jira can be made so different
> that you'll momentarily get lost :) Sounds like FS to me :)
>
>
> > Multiple components per bug. If for example a bug affects more than one
> > part of the system (validation block , samples , sitemap configuration
> > ) they can all be assigned to the same issue.
>
> That's good.
>
>
> > Customizable issues linking. Not only "mark as duplicate of this bug",
> > but also, this task / bug / xxx requires the resolution of, is related
> > to, is a duplicate of, blablabla (customizable).
>
> Bugzilla (as I see) has only Depends, Blocks, Duplicate. Not customizable but
> covers many usecases.
>
>
> > Version management: not only one can specify in what version one found
> > a bug, but also in what version it will be fixed, so that we can have
> > clear roadmaps of what has been found in what versions, and what was
> > (needs to be) fixed in what version.
>
> It seems bugzilla has 'Target Milestone' for this. Not used in Cocoon's bugzilla.
>
>
> >> * Is it faster?
> >
> > Yes in my particular experience. The search provided by Lucene/Jira is
> > faster than the one provided by SQL/BugZilla. It depends (though) on
> > how it's installed, how much ram the VM has, and so on and so forth.
> >
> > As far as I can see, looking for the word "cocoon" in Jira gives me a
> > first page of results in roughly one second, on and Bugzilla it takes
> > roughly 2.5 (but that might be my internet connection, the specific
> > query, blablabla). In other words, my experience.
>
> Well direct access to the bug usually takes 5-10 secs in jira (unless cached?),
> and 1-5 secs in bugzilla. Advanced search might be faster in jira - dunno.
>
>
> >> * Is it more stable?
> >
> > In two years of production use of Jira, I never saw it crash once. I
> > believe that the issues related to the stability of Jira on the ASF
> > were tied to the use of Tomcat rather than Jetty (what I personally use
> > in production). And I believe that those were solved when
> > issues.apache.org was moved to AJAX from Nagoya.
> >
> >> I tried using it, and (IMVHO) it fails on last two points and has
> >> hard-to-read-at-a-glance UI.
> >
> >
> > Agreed, the user interface is far from perfect (and Apache's choice of
> > colors makes it even uglier), but IMVO Bugzilla's worse.
>
> Summarizing above, I don't mind giving it a try as long as (*) above is resolved
> somehow (either throw my education or jira configuration, that's it :-p).
>
> Vadim
Re: Shall we switch to Jira?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Pier Fumagalli wrote:
> On 13 Sep 2005, at 15:25, Vadim Gritsenko wrote:
>
>> It's really frustrating when you can't change bug status or do some
>> other tasks. That's what I meant; I presume that's part of
>> 'customized workflows' feature.
>
> You can't change the bug status? That's really freaky. The status as in
> "open", "resolved", "closed" ... ?
Yes.
> There are normally big buttons on the left of the UI that depending on
> the current status of an issue, allow you to move to the next ones: for
> example if a bug is "open" you have links to "close" and "resolve and
> close" on the left, it will ask for an activity comment and change the
> status.
Examples
http://issues.apache.org/jira/browse/JCR-169
http://issues.apache.org/jira/browse/JCR-188
No 'Close', no 'Reopen', only 'Clone' and some such. And it's not limited to
JCR. And I'm currently logged in - not an anonymous browsing.
IMNSHO, it's a deal breaker if our own users can't mess with our own bug
database. (*)
>> Constructive comment would be;
>>
>> * What it does better?
>
>
> Per-user customization is (IMVHO) one of the coolest things in there,
> and the reports integrated in Jira are killer. I personally use it also
> to track and link automagically bugs from Subversion commits with the
> Jira subversion plugin and ViewSVN, so, no more fix a bug in SVN, copy
> and paste the commit message, modify the bug tracking database. Jira
> picks it up automatically (I don't know if Bugzilla does the same
> nowadays).
So is this stuff configured at issues.apache.org too?
> Every single friggin label (also) is customizable, statuses, component,
> fields, EVERYTHING can be added or removed, so for every
> project/component/issue-type one can have different fields /
> requirements depending on the real needs of the project.
That's on one side - on the other each project's jira can be made so different
that you'll momentarily get lost :) Sounds like FS to me :)
> Multiple components per bug. If for example a bug affects more than one
> part of the system (validation block , samples , sitemap configuration
> ) they can all be assigned to the same issue.
That's good.
> Customizable issues linking. Not only "mark as duplicate of this bug",
> but also, this task / bug / xxx requires the resolution of, is related
> to, is a duplicate of, blablabla (customizable).
Bugzilla (as I see) has only Depends, Blocks, Duplicate. Not customizable but
covers many usecases.
> Version management: not only one can specify in what version one found
> a bug, but also in what version it will be fixed, so that we can have
> clear roadmaps of what has been found in what versions, and what was
> (needs to be) fixed in what version.
It seems bugzilla has 'Target Milestone' for this. Not used in Cocoon's bugzilla.
>> * Is it faster?
>
> Yes in my particular experience. The search provided by Lucene/Jira is
> faster than the one provided by SQL/BugZilla. It depends (though) on
> how it's installed, how much ram the VM has, and so on and so forth.
>
> As far as I can see, looking for the word "cocoon" in Jira gives me a
> first page of results in roughly one second, on and Bugzilla it takes
> roughly 2.5 (but that might be my internet connection, the specific
> query, blablabla). In other words, my experience.
Well direct access to the bug usually takes 5-10 secs in jira (unless cached?),
and 1-5 secs in bugzilla. Advanced search might be faster in jira - dunno.
>> * Is it more stable?
>
> In two years of production use of Jira, I never saw it crash once. I
> believe that the issues related to the stability of Jira on the ASF
> were tied to the use of Tomcat rather than Jetty (what I personally use
> in production). And I believe that those were solved when
> issues.apache.org was moved to AJAX from Nagoya.
>
>> I tried using it, and (IMVHO) it fails on last two points and has
>> hard-to-read-at-a-glance UI.
>
>
> Agreed, the user interface is far from perfect (and Apache's choice of
> colors makes it even uglier), but IMVO Bugzilla's worse.
Summarizing above, I don't mind giving it a try as long as (*) above is resolved
somehow (either throw my education or jira configuration, that's it :-p).
Vadim
Re: Shall we switch to Jira?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 13 Sep 2005, at 15:25, Vadim Gritsenko wrote:
>>>> and send status of them to a particular individual / list /
>>>> email, or to have customized workflows / fields / schemes and
>>>> so on...
>>>
>>> We don't need that crap. It is problem enough that half of the
>>> time you can't do much in Jira while working with other
>>> projects, no need to screw up Cocoon's bug tracking system.
>>>
>> In my opinion those are quite nice features... Having to work (by
>> choice) with Jira at work, I feel personally that some of that
>> "crap" (once you get used to it, and start _really_ working with
>> Jira) is _extremely_ useful.
>
> It's really frustrating when you can't change bug status or do some
> other tasks. That's what I meant; I presume that's part of
> 'customized workflows' feature. Yep, I had bunch of experience with
> ClearQuest, did not liked it either.
You can't change the bug status? That's really freaky. The status as
in "open", "resolved", "closed" ... ?
There are normally big buttons on the left of the UI that depending
on the current status of an issue, allow you to move to the next
ones: for example if a bug is "open" you have links to "close" and
"resolve and close" on the left, it will ask for an activity comment
and change the status.
This _can_ be configured with custom workflows but the default one
works pretty much all right.
>> And since I spend 20% of my time tracking projects at work using
>> Jira, I think that it might be a good solution also for this
>> project. That said, this is my humble opinion, and as the subject
>> of this mail states "Shall we switch to Jira", I'm asking for
>> comments from other members of this list, _constructive_ comments.
>
> Constructive comment would be;
>
> * What it does better?
Per-user customization is (IMVHO) one of the coolest things in there,
and the reports integrated in Jira are killer. I personally use it
also to track and link automagically bugs from Subversion commits
with the Jira subversion plugin and ViewSVN, so, no more fix a bug in
SVN, copy and paste the commit message, modify the bug tracking
database. Jira picks it up automatically (I don't know if Bugzilla
does the same nowadays).
Every single friggin label (also) is customizable, statuses,
component, fields, EVERYTHING can be added or removed, so for every
project/component/issue-type one can have different fields /
requirements depending on the real needs of the project.
Multiple components per bug. If for example a bug affects more than
one part of the system (validation block , samples , sitemap
configuration ) they can all be assigned to the same issue.
Customizable issues linking. Not only "mark as duplicate of this
bug", but also, this task / bug / xxx requires the resolution of, is
related to, is a duplicate of, blablabla (customizable).
Version management: not only one can specify in what version one
found a bug, but also in what version it will be fixed, so that we
can have clear roadmaps of what has been found in what versions, and
what was (needs to be) fixed in what version.
> * Is it faster?
Yes in my particular experience. The search provided by Lucene/Jira
is faster than the one provided by SQL/BugZilla. It depends (though)
on how it's installed, how much ram the VM has, and so on and so forth.
As far as I can see, looking for the word "cocoon" in Jira gives me a
first page of results in roughly one second, on and Bugzilla it takes
roughly 2.5 (but that might be my internet connection, the specific
query, blablabla). In other words, my experience.
> * Is it more stable?
In two years of production use of Jira, I never saw it crash once. I
believe that the issues related to the stability of Jira on the ASF
were tied to the use of Tomcat rather than Jetty (what I personally
use in production). And I believe that those were solved when
issues.apache.org was moved to AJAX from Nagoya.
> I tried using it, and (IMVHO) it fails on last two points and has
> hard-to-read-at-a-glance UI.
Agreed, the user interface is far from perfect (and Apache's choice
of colors makes it even uglier), but IMVO Bugzilla's worse.
Pier
Re: Shall we switch to Jira?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Pier Fumagalli wrote:
> On 13 Sep 2005, at 13:58, Vadim Gritsenko wrote:
>
>> Pier Fumagalli wrote:
>>
>>> But at the same time, Bugzilla doesn't allow one to create own
>>> filters (searches)
>>
>> Wrong. How come I have several. See 'Remember Search' button, and
>> 'Saved Searchs' in the footer.
>
> You broke up the phrase: "save the filter AND send status of them"
My bad - misunderstood your statement.
>>> and send status of them to a particular individual / list / email,
>>> or to have customized workflows / fields / schemes and so on...
>>
>> We don't need that crap. It is problem enough that half of the time
>> you can't do much in Jira while working with other projects, no need
>> to screw up Cocoon's bug tracking system.
>
> In my opinion those are quite nice features... Having to work (by
> choice) with Jira at work, I feel personally that some of that "crap"
> (once you get used to it, and start _really_ working with Jira) is
> _extremely_ useful.
It's really frustrating when you can't change bug status or do some other tasks.
That's what I meant; I presume that's part of 'customized workflows' feature.
Yep, I had bunch of experience with ClearQuest, did not liked it either.
> And since I spend 20% of my time tracking projects at work using Jira,
> I think that it might be a good solution also for this project. That
> said, this is my humble opinion, and as the subject of this mail states
> "Shall we switch to Jira", I'm asking for comments from other members
> of this list, _constructive_ comments.
Constructive comment would be;
* What it does better?
* Is it faster?
* Is it more stable?
I tried using it, and (IMVHO) it fails on last two points and has
hard-to-read-at-a-glance UI.
> ---
>
> Now, I'm not saying "you're crap if you don't swich", as much as I
> don't go around saying things like "Can you please make up your mind,
> is it DEBUG or WARN???".
Sorry if humor of the situation has not reached you; even with smiles present. I
had not had personal issues with you - so far, and IMHO - and I don't know if
you have any.
PS Not anger but frustration with jira.
Vadim
Re: Shall we switch to Jira?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 13 Sep 2005, at 13:58, Vadim Gritsenko wrote:
> Pier Fumagalli wrote:
>
>> But at the same time, Bugzilla doesn't allow one to create own
>> filters (searches)
>
> Wrong. How come I have several. See 'Remember Search' button, and
> 'Saved Searchs' in the footer.
You broke up the phrase: "save the filter AND send status of them"
>> and send status of them to a particular individual / list /
>> email, or to have customized workflows / fields / schemes and so
>> on...
>
> We don't need that crap. It is problem enough that half of the time
> you can't do much in Jira while working with other projects, no
> need to screw up Cocoon's bug tracking system.
In my opinion those are quite nice features... Having to work (by
choice) with Jira at work, I feel personally that some of that
"crap" (once you get used to it, and start _really_ working with
Jira) is _extremely_ useful.
But this is my personal opinion.
>> I think that anything at this point is better than BugZilla! :-)
>
> How so?
Because after having used (and administered) Bugzilla for several
years, and having switched to Jira, I can see that from my point of
view, the former doesn't offer some of the features and facilities
than the latter happens to have.
And since I spend 20% of my time tracking projects at work using
Jira, I think that it might be a good solution also for this project.
That said, this is my humble opinion, and as the subject of this mail
states "Shall we switch to Jira", I'm asking for comments from other
members of this list, _constructive_ comments.
---
Now, personally, I'm getting pretty annoyed at the tone of your
emails. I'm just suggesting things that IN MY VERY HUMBLE OPINION,
would work better, all of them based on my personal experience...
Now, I'm not saying "you're crap if you don't swich", as much as I
don't go around saying things like "Can you please make up your mind,
is it DEBUG or WARN???".
Is it so hard to say "in my opinion", "this is my idea" or "I
reviewed you commit, and I found a little bug in when you do logging".
So, if you have, if you have a problem with me personally, this is
not the place to vent your anger... And if you don't, just consider
that the tone of your emails might upset other people.
Pier
Re: Shall we switch to Jira?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Pier Fumagalli wrote:
> But at the same time, Bugzilla doesn't allow one to create own filters
> (searches)
Wrong. How come I have several. See 'Remember Search' button, and 'Saved
Searchs' in the footer.
> and send status of them to a particular individual / list /
> email, or to have customized workflows / fields / schemes and so on...
We don't need that crap. It is problem enough that half of the time you can't do
much in Jira while working with other projects, no need to screw up Cocoon's bug
tracking system.
>>> I think that anything at this point is better than BugZilla! :-)
How so?
Vadim
Re: Shall we switch to Jira?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 13 Sep 2005, at 12:52, Jorg Heymans wrote:
> (note i've never used jira)
I do, on a daily basis! :-)
> Pier Fumagalli wrote:
>
>> That said, the ASF has already a perfectly maintained installation of
>> Jira up and running:
>>
>> http://issues.apache.org/jira/
>>
> Can it do this
> http://issues.apache.org/bugzilla/attachment.cgi?id=16165&action=diff
Nope, or at least, I don't think it has an automated diff parser /
formatter for attachments (it does thumbnails for images, though! :-P)
But at the same time, Bugzilla doesn't allow one to create own
filters (searches) and send status of them to a particular
individual / list / email, or to have customized workflows / fields /
schemes and so on...
That's AFAIK, of course.
>> I think that anything at this point is better than BugZilla! :-)
>
> Is there a clear bug migration procedure from bugzilla to jira?
Yep, the guys on infrastructure@ do it quite often
Pier
Re: Shall we switch to Jira?
Posted by Jorg Heymans <jh...@domek.be>.
(note i've never used jira)
Pier Fumagalli wrote:
>
> That said, the ASF has already a perfectly maintained installation of
> Jira up and running:
>
> http://issues.apache.org/jira/
>
Can it do this
http://issues.apache.org/bugzilla/attachment.cgi?id=16165&action=diff
> I think that anything at this point is better than BugZilla! :-)
Is there a clear bug migration procedure from bugzilla to jira?
Jorg
Re: Shall we switch to Jira?
Posted by Antonio Gallardo <ag...@agssa.net>.
Pier Fumagalli wrote:
> On 13 Sep 2005, at 16:56, Mark Lundquist wrote:
>
>> On Sep 13, 2005, at 4:33 AM, Pier Fumagalli wrote:
>>
>>> I think that anything at this point is better than BugZilla! :-)
>>
>>
>> Somebody a while back posted a link to Trac (http://
>> www.edgewall.com/trac/). I can't speak from experience with it, and
>> I don't know whether it has all the industrial-strength features
>> that people are looking for. But... I thought of mentioning it
>> because the integration with Subversion is interesting and looks
>> pretty impressive. (One limitation is that currently Trac must be
>> installed on the same host as the SVN repo).
>>
>> But I guess if there were people on this list who were qualified to
>> compare it w/ BZ & Jira, they'd have sounded off by now...
>
>
> Unless we "fork" from the normal Apache infrastructure, I don't think
> our sysadmins would be happy to install a third bug tracking system,
> unfortunately (The ASF manages BugZilla and JIRA already)...
Correction it will be a 4th tracking system: Scarab is still there:
http://issues.apache.org/scarab/issues ;-)
Best Regards,
Antonio Gallardo.
Re: Shall we switch to Jira?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 13 Sep 2005, at 16:56, Mark Lundquist wrote:
> On Sep 13, 2005, at 4:33 AM, Pier Fumagalli wrote:
>
>> I think that anything at this point is better than BugZilla! :-)
>
> Somebody a while back posted a link to Trac (http://
> www.edgewall.com/trac/). I can't speak from experience with it,
> and I don't know whether it has all the industrial-strength
> features that people are looking for. But... I thought of
> mentioning it because the integration with Subversion is
> interesting and looks pretty impressive. (One limitation is that
> currently Trac must be installed on the same host as the SVN repo).
>
> But I guess if there were people on this list who were qualified to
> compare it w/ BZ & Jira, they'd have sounded off by now...
Unless we "fork" from the normal Apache infrastructure, I don't think
our sysadmins would be happy to install a third bug tracking system,
unfortunately (The ASF manages BugZilla and JIRA already)...
But if people are passionate enough I can ask...
Pier
Re: Shall we switch to Jira?
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Sep 13, 2005, at 4:33 AM, Pier Fumagalli wrote:
> I think that anything at this point is better than BugZilla! :-)
Somebody a while back posted a link to Trac
(http://www.edgewall.com/trac/). I can't speak from experience with
it, and I don't know whether it has all the industrial-strength
features that people are looking for. But... I thought of mentioning
it because the integration with Subversion is interesting and looks
pretty impressive. (One limitation is that currently Trac must be
installed on the same host as the SVN repo).
But I guess if there were people on this list who were qualified to
compare it w/ BZ & Jira, they'd have sounded off by now...
—ml—
Re: Shall we switch to Jira?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 13 Sep 2005, at 10:37, Sylvain Wallez wrote:
> Pier Fumagalli wrote:
>
>> Just an idea... I'm used to work on it at work, and it's quite an
>> improvement on Bugzilla, and allows things like:
>>
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?
>> view=rss&&query=cocoon&summary=true&description=true&body=true&tempMa
>> x=2 5&reset=true&decorator=none
>
> Bugzilla provides iCal todo lists, not as versatile as RSS though.
>
> A good opensource bugzilla replacement seems to be Trac: http://
> projects.edgewall.com/trac/
That said, the ASF has already a perfectly maintained installation of
Jira up and running:
http://issues.apache.org/jira/
I think that anything at this point is better than BugZilla! :-)
Pier
Re: Shall we switch to Jira?
Posted by Sylvain Wallez <sy...@apache.org>.
Pier Fumagalli wrote:
> Just an idea... I'm used to work on it at work, and it's quite an
> improvement on Bugzilla, and allows things like:
>
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?
> view=rss&&query=cocoon&summary=true&description=true&body=true&tempMax=2
> 5&reset=true&decorator=none
Bugzilla provides iCal todo lists, not as versatile as RSS though.
A good opensource bugzilla replacement seems to be Trac:
http://projects.edgewall.com/trac/
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Shall we switch to Jira?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 14 September 2005 10:32, Antonio Gallardo wrote:
> Being reading all the thread, I think there is also one important
> aspect: A lot of the projects used in cocoon as xalan, xerces et al. all
> of them already migrated to jira.
Agree. Infrastructure would also be *really* happy if all projects converged
on a single system, as it would reduce the load on them a bit.
As for down-times vs "we have used Jira for years and it is great";
The ASF Jira has more hits than any other "known" Jira installation, and the
Atlassian developers (some are Apache committers) are taking this seriously
and doing whatever they can to have it sorted out.
Perhaps a check with other Jira using projects would be in order, especially
the ones who have migrated.
Cheers
Niclas
Re: Shall we switch to Jira?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 14.09.2005 04:32, Antonio Gallardo wrote:
> On the other side, I am also a happy bugzilla user too. ;-)
Me too :)
> I met Jira, while trying to watch a lot of other ASF projects for
> cocoon.
Me too. And there I got frustrated with Jira. Most probably because of
the "hard-to-read-at-a-glance UI" and ...
> 1-Slower than bugzilla (from my place. Dunno why, perhaps bigger pages).
... the performance. (I don't think it's because of the bigger pages,
but the server-side. The difference is too obvious.)
> 2-frequent downtimes (Pier explained this is due tomcat. Anyway the
> cruel reality is: frequent downtimes).
> 3-Not Open Source:
> https://www.atlassian.com/about/licensing/faq.jsp#open_source
Both not that important in my point of view.
Jörg
Re: Shall we switch to Jira?
Posted by Antonio Gallardo <ag...@agssa.net>.
Pier Fumagalli wrote:
> Just an idea... I'm used to work on it at work, and it's quite an
> improvement on Bugzilla, and allows things like:
>
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?
> view=rss&&query=cocoon&summary=true&description=true&body=true&tempMax=2
> 5&reset=true&decorator=none
>
> Pier
>
Being reading all the thread, I think there is also one important
aspect: A lot of the projects used in cocoon as xalan, xerces et al. all
of them already migrated to jira. I believe using the same bug tracking
system can help us a lot. Exactly the same as when this projects used
bugzilla few years ago. Bugzilla reported us the change of the bug in
the other project. Actually, we need to check manually in jira if the
status of them changed. Currently, we have some links to jira bugs:
http://issues.apache.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Cocoon+2&content=jira
On the other side, I am also a happy bugzilla user too. ;-)
I met Jira, while trying to watch a lot of other ASF projects for
cocoon. I agree Jira is quite different than bugzilla, but when you use
Jira more often you note Jira offer a lot of cool features. The things I
don't like in our Jira installation are:
1-Slower than bugzilla (from my place. Dunno why, perhaps bigger pages).
2-frequent downtimes (Pier explained this is due tomcat. Anyway the
cruel reality is: frequent downtimes).
3-Not Open Source:
https://www.atlassian.com/about/licensing/faq.jsp#open_source
Best Regards,
Antonio Gallardo.
Re: Shall we switch to Jira?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 12 sept. 05, à 20:10, Pier Fumagalli a écrit :
> Just an idea... I'm used to work on it at work, and it's quite an
> improvement on Bugzilla...
The thing is, IMHO we don't even use bugzilla very seriously, so I
don't know if switching to a better tool would help.
If people think the impoved features that Jira brings would help us
make better use of our issue tracking, AND if Jira at the ASF is stable
(seems like there are regular reports of it being down, but it's just
an impression as I'm not using it much), I'd be ok to switch.
An important thing for code contributions via the issue tracker is that
jira has this "check here to indicate your acceptance of the ASF
license for your contribution" box. Helps sort out the legal aspects of
contributions.
-Bertrand