Discuss: Introducing JIRA – the new bug tracker

[Acyd Burn]

I found it mind boggling that this was "the best solution" you could come up with.

Mainly it had to do with the abilities JIRA gives us (workflow adjustements for example) which were all rudimentary on different products (bugzilla is horrid) - but the main factor was basically the tight integration with other development tools provided by Atlassian (continuous integration, source code view, source code review, etc.) - with our old bug tracker we would've spend days, weeks, months for programming this - which is just not acceptable.

The old tracker was far superior to the new one in terms of performance, usability and plain old useful functionality.

Of course it is - it is always the case with a product you code for your own internal use, you only have one market you serve.

It would have made sense had you migrated to Redmine's Issue tracker to maintain consistency with the project management side and maintain the ability to link tracker tickets to repository revisions. Now all of that is lost.

There still needs to be real commit messages sent and the redmine view updated to git - but without the correct commit messages there is of course no linking. It does not matter where it is displayed, if the commit messages are not noting the bug number (PHPBB3-XXXX) then no linking can happen.

If you mean adding revisions by hand to the ticket - this is possible if the dev team leader adds this to the issue field views.

[Highway of Life]

The features of JIRA are great, and the integrations and tools that it has are unmatched, but I am a bit concerned here... if JIRA being so slow and heavy is going to keep more people from submitting tickets, browsing and commenting on tickets, does all those awesome features come at too high of a cost?
All this was easy with the previous bug tracker, and certainly it is easy with many many other products out there (Assembla comes to mind), but shouldn’t the focus first be on usability because you want more people to participate in the bug/issue/feature process? And then features and integration of that product being second?

I’m concerned that JIRA will scare more people away from using it. But is there a way to track it’s usage? - Can you determine if more people or fewer people are working with the bug tracker before or after the switch to JIRA? I know that using the in-house tracker isn’t really an option moving forward, but there are many other trackers out there that could be used that are much easier to use and much better for performance. Although they may not have the same level of integration with existing tools that JIRA has, but I would view community contributions and activity within the tracker as a much higher priority than features.

[MichaelC]

I believe that one of the reasons for using the JIRA Tracker as it goes well with the other JIRA products which I believe Miek is experimenting and adapting for use at the moment.

But I see where your coming from David (Can I call you that?)

[Highway of Life]

Yes, David is fine.

I believe that one of the reasons for using the JIRA Tracker as it goes well with the other JIRA products which I believe Miek is experimenting and adapting for use at the moment.

The integrations for JIRA make it very attractive, yes... that’s the benefit. But my question is: “is it worth the cost?” if the tracker actually reduces community participation? - I don’t know if it will affect community participation or not, but it might be something that should be tracked to find out.

[Techie-Micheal]

Yes, David is fine.

I believe that one of the reasons for using the JIRA Tracker as it goes well with the other JIRA products which I believe Miek is experimenting and adapting for use at the moment.

The integrations for JIRA make it very attractive, yes... that’s the benefit. But my question is: “is it worth the cost?” if the tracker actually reduces community participation? - I don’t know if it will affect community participation or not, but it might be something that should be tracked to find out.

I think I've made it clear that I don't like Java-based server applications. I was considering Cruisecontrol, but am intentionally avoiding it unless I can't find a replacement for my own projects. My build server is using/will be using a Python application instead of Buildr or similar, simply because of the Java. My question becomes, how else can the devs achieve the interoperability that they are looking for, and for so little cost? I do understand and agree that JIRA may push users away and usage needs to be measured, do you know of any alternatives, given the constraints?

[Phil]

For whatever it's worth, it does not look like this move is impacting ticket creation at all -- the old tracker generally average around 75 or so tickets a month as well.

[3Di]

Comparison chart of issue tracking systems .. a good start where to look at, IMO.

[Acyd Burn]

IMO jira is not as slow as some state here. For example my experience with Zend's jira installation is that Zend's is twice as slow as ours for example. Atlassians installation though is a bit faster - but IMO this is due to their database connection and they are obviously running tomcat on port 80.

The next steps for increasing performance (this is always a step-by-step thing which never really ends) is to update to the newest release, serve static content with apache (which we use for area51, etc.). Then, the next step would be to measure performance with varnish in front of it for the static content. Then i will try to switch to postgresql running locally (JIRA is known to not work well with MySQL).

Given the bug tracker activity at the moment (you are able to subscribe to projects now) i see no downgrade in usage, but the quality of the submitted tickets increased (far less support requests, more useful descriptions).

Also, one additional benefit for developers is the tight integration into Eclipse and Visual Studio for example.

[Oleg]

Let's try this. http://jp.etal.bsdpower.com/

It's a small proxy for jira, addressing the most egregious violations:

1. no-store and no-cache are nuked from orbit
2. expiration dates in the past are killed too
3. cacheable files (cache-control: public & expires or max-age set) are cached on the proxy for the declared duration
4. keep-alives!

It's still slow, but now (more) bearable.

[ToonArmy]

Feel free to share the configuration changes you've made here or privately with Meik, it'll be appreciated.

[Desdenova]

I have to say, I'm with the previous posters regarding the speed of JIRA; having to sit there and wait for the system to pull up the data and show it is very frustrating.

It may integrate better with your workflow, it may have all the fancy switches and buttons that you want, but in the end makes us the users take more of our time to report problems to the developers.
If this gets any slower, I just won't waste my time trying to report a possible bug; I have better things to do than sit in front of some ridiculous loading bar spinning around on my screen for an eternity and a half, and I suspect there are many others that feel the same way as well.

I certainly hope that this is not indicative of the general direction of phpBB in the future.

[A_Jelly_Doughnut]

I certainly hope that this is not indicative of the general direction of phpBB in the future.

No, most certainly not

[Oleg]

Feel free to share the configuration changes you've made here or privately with Meik, it'll be appreciated.

You guys missed the "proxy" part of "proxy for jira". I don't have any local jira installations.

For the record, I skimmed through jira docs before going the proxy route, especially the performance section, and have not found any meaningful knobs.

I also visited atlassian's own jira install just now. It's actually quite fast, both for scripts and static files. It still sends no-cache and no-store headers however, so that if I go to browse issues page and change search filter, after navigating to an issue and pressing back button firefox prompts me to resubmit the search form.

[ToonArmy]

Feel free to share the configuration changes you've made here or privately with Meik, it'll be appreciated.

You guys missed the "proxy" part of "proxy for jira". I don't have any local jira installations.

Yeah I know, I assume you made configuration changes to Apache/Varnish/some other HTTP reverse proxy.

[Acyd Burn]

-nn, the configuration settings for adjusting the headers would be indeed quite helpful. It seems like there is something wrong on our end, because the initial connection time is what makes our installation so slow. The time between the request and the sending of the page is quite high.