After 9 Years, Bugzilla Moves Up to 3.0 99
BuggyUser writes "Bugzilla, the popular application to track and manage software development bug reports, has moved up to version 3.0. The 2.x series has been in service for the last nine years. From the article: 'According to the Bugzilla 3.0 release announcement, some of the new features in this version include custom fields, support for the Apache mod_perl module, per-product permissions, an XML-RPC interface, and the ability to create and edit bugs via email. A demo site has been set up where users can test the new version before downloading.'" Linux.com and Slashdot.org are both owned by OSTG.
features... (Score:5, Funny)
Love it.
Re: (Score:3, Funny)
Maybe Duke Nukem Forever is next (Score:1)
Re: (Score:1)
What, why? (Score:2)
Re:What, why? (Score:5, Informative)
It's the bugtracker that is used by most major FOSS projects.
Re: (Score:2, Interesting)
used by most major FOSS projects.
This is kind of worrying. See, unlike Firefox and Thunderbird, Bugzilla is only licensed under the MPL. Debian considers the MPL non-free [debian.org], at least because it requires that source code be available at least six months after you stop distributing a binary, if you distribute the binary over a network. This is considered too onerous a restriction, as unavoidable circumstances (e.g. a Slashdotting) might prevent the availability of the source code. [Note that the GPL does not require this: if you distribute s
Re: (Score:3, Informative)
Re: (Score:2, Interesting)
I'm not involved in Debian, but that's a pretty resounding set of rejections. If you read the whole thread (here [debian.org], find "MPL") you can see one or two dissenting opinions, but the "reject" option does seem to be the consensus view. And
Re: (Score:3, Informative)
Actions speak louder than words, and the continued presense of Bugzilla, Firebird and other MPL-licensed packages in main indicate that the project does not consider the MPL to be non-free.
Re: (Score:1)
Re: (Score:1, Flamebait)
Are they supposed to break the law to get in your goody-goody list? Fuck you.
Re: (Score:2)
AFAICT, the MPL is not a bad license, other than its GPL incompatibility.
I'll even it out for you (Score:2)
Re: (Score:1)
-Max
I found a major bug in bugzilla (Score:4, Funny)
Re: (Score:1)
Compared to test director.. (Score:4, Interesting)
I find bugzilla lacking in polish..Been using the test director for quite a long time at work and it seems very slick. I have used bugzilla only a few times [have raised some of the early ubuntu-vmware issues ]. Interestingly, feature by feature, it holds ground against the more [very] expensive counterpart. Bugzilla works well with firefox and safari - which I guess Test director may not due to few activex dependencies.
The reason why I felt this was I suggested bugzilla to a colleague in a different organisation and they were far from satisfied. A more intuitive gui and some pleasing css works would have saved the day for bugzilla.
Come to think of it, I could say that against many of the projects(FOSS in particular)... A bit more effort on UX could make a world of difference. Been testing office 2007 last few weeks and I'm very impressed. Just one of the apps in recent times whose UI made me feel why didn't I think of it. Just a pity that the guys who made Office 2007 were not more involved with Vista.
Now off to some much needed sleep....
[/rant:end]
PS - Most of the comments above are subjective and anecdotal - Your experience and opinions might differ and I can live with it.
Re: (Score:1)
I would say that if you want to use the other parts of TD (Test Plan, Test Lab et cetera), then it is just about the best thing since sliced bread (even given that it *can* be fucking annoying to use, and reporting is a bit shit). BUT - if you just want bug tracking then I do think Bugzilla is the way to go, even if only due to the price
Re: (Score:2)
It's not a matter of effort, it's a matter of vision. The nature of how OSS works (many eyeballs) is counter to how good GUI's are designed (central visionary designer). To make matters worse, in most OSS projects th
Re:Compared to test director.. (Score:5, Insightful)
Re: (Score:3, Insightful)
Who is it discovers bugs and submits reports in the first place? Magic leprechauns?
Re: (Score:2)
Sorry, but something that is obvious to you (and that you asked rethorically) isn't to me.
Re: (Score:2)
If you install Bugzilla on your product's web site, and users think the Bugzilla user interface sucks, then they'll most likely associate that suckiness not with Mozilla but rather with you. That's why it is in your own interest to use a bug-reporting system which has an interface targeted at your end users rather than at yourself.
And it's nothing to do with users being "evolved" or having the mere capability to read instructions - their ability to complete the task i
Re: (Score:2)
Don't get me wrong, there are many things to be improved in Bugzilla's interface. Still, the normal public of bugzilla is either motivated enough (as I am) to work with it, or is not, in which case they tend to use IRC channels, email or other tools to submit their reports (as I sometimes do: I don't always want to register on a bug tracker database
Re: (Score:2)
Re: (Score:2)
Don't get me wrong, there are many things to be improved in Bugzilla's interface. Still, the normal public of bugzilla is either motivated enough (as I am) to work with it, or is not, in which case they tend to use IRC channels, email or other tools to submit their reports (as I sometimes do: I don't always want to register on a bug tracker database just to report one single bug.
But that's the problem with large OSS projects - there's often no contact information for submitting bugs other than the link to the bug-tracking software.
And the problem with Bugzilla is that (a) you can't submit anonymous bugs, and (b) the search engine to check if anyone's submitted the same bug before you is particularly sucky. Which means that a lot of bugs don't get submitted because users can't be bothered, and the ones that do get submitted often turn out to be dupes.
Sourceforge.net has a much bet
Re: (Score:2)
Sorry, that hasn't been my experience at all. Most big projects I know of have at least a mailing list and an IRC channel, in addition to the bug tracker. Maybe we're thinking of different areas of OSS?
Re: (Score:2)
Now, however they're unintelligently designed so as not to be able to do so.
Re: (Score:2)
However I also think the bugzilla pages are pretty ugly and sparse. Can't they get rid of about 3/4 of those fields so you don't have to scroll to see the text of the bug?
Re: (Score:2)
Re: (Score:2, Informative)
Test Director also has a very bad reputation for security problems. Almost all security for it is done on the untrusted ActiveX client and not on server! Do not use test director if users are not 100% trusted.
Re: (Score:3, Interesting)
Now I've heard about the graphical client SvnTortoise or something, but my point is: I'd rather stab my eyes out that going back to that slow piece of shit Perforce.
So I ask you: please, UI is important, but it's only one of many features.
Re: (Score:2)
At my last company we used StarTeam, and although it sucked badly as a version control system, it had a nice tie-
Re: lacking (Score:1)
Specifically in this case it seems that of the 17 available localizations only Japanese in an initial release form is currently available for the 3.0 version. The most recent available Polish versions are for 2.20 and 2.18 which is as fresh as any other localized package apart from Japanese. This is another example of localization trailing development instead of being integrated with it. (Reference: bugzilla download localizations [bugzilla.org])
Re: (Score:2)
Was the guy to provide developer time or money to Bugzilla? Probably not.
As you already said Buzguilla can stand feature-to-feature against solutions more expensive and (probably) with their own sets of problems (like being privative, for instance). So in the end, your colleague dismissed bugzilla not on a technical backgr
Re: (Score:2)
Yeah, but that's the problem to whom? It seems obvious it's not a significative problem to those developing bugzilla at least or else, they probably would have expent some time/effort on that issue as they have done on whatever they've been devoloping all this time. If if it's not *their* problem, maybe it is *your* problem, isn't it? But then, what have *you* done about it? Maybe, hummm... nothing?
"There are no ex
Re: (Score:1)
One problem is that UX engineers are kind of hard to come by. Most of them get paid a lot of money and work all day, and I know few of them who work on open source projects in their spare time.
We have some good programmers on the team, but we're not all UI designers. I have some UI design experience myself, but I'm usually caught up in doing architecture and backend. We do consider improving B
Bugs and their Creation (Score:1, Redundant)
Is that *really* such a good idea, I wonder?
Re: (Score:1)
it's wonderful if they let it actually work (Score:2)
I don't have any sort of account with Debian, yet I can file bugs and comment on bugs. It's easy, so they get lots of good bug reports from me. Likewise for the kernel, because they take bugs on an unrestricted mailing list.
With Bugzilla and restricted mailing lists, usually I just don't bother. Screw them. If they wanted bug reports, they wouldn't have made filing bug reports a pain in the ass.
So... will it be easy like De
Re: (Score:2)
I know that on more than one occasion, this kind of thing has scared me off from filing a bug report. Enough accounts aside, I just don't feel it's worth my time or effort to sign up for something else just to tell them about a glitch.
Don't rewrite from scratch (Score:3, Insightful)
Re: (Score:3, Insightful)
So, if you had a bug tracker written in assembly you'd keep iteratively improving the assembly instead of rewriting it i
Re: (Score:1)
If resources are tight and you have commitments to your customers, you definitely should not try to rewrite from scratch.
Rewriting from scratch while maintaining a production branch takes a lot of effort - some times too much. You don't have to look far to find a perfect example: an earlier effort to rewrite Bugzilla from scratch failed - the rewrite never ca
Re: (Score:2)
See http://tinyurl.com/2l2vdn [tinyurl.com] [ isixsigma.com, not goatse
It's not 'rewrite fast, release often, fix the bugs, restart'.
More, you define where you want to be in 10 years time, then focus on delivering something that takes you nearer to that goal every - say - 3 to 9 months.
Think NASA and going to the moon...
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
I love FF, but felt the last release was rushed to prevent IE from getting all the headlines. I seem to recall some high profile bugs and gripes about the release feeling more like an incremental... none of which helped FF's profile in the non-OSS world.
As for proprietary examples... um... where would I start?
'Rel
Re: (Score:2)
All too often releases are made for reasons other than having a release ready product. While I notice this mostly in the proprietary world, the last release of FF jumps to mind as an OSS example.
But "release early, release often" refers to bleeding-edge development builds, not to stable products! The whole point of the concept is to get as many users as possible providing constructive feedback and testing, so that when a stable release does happen it's as complete as possible.
(Of course, in these happy days of SVN, it's pretty much been made irrelevant, since everyone has easy access to the development version of OSS projects.)
Re: (Score:2)
Proprietary vendors using the same release philosophy is akin to selling a car that needs a shitload of work, but selling it at a new car price anyhow, knowing you will make money off bringing that car up to standards because the customer has
Re: (Score:2)
Mind you, the masses were so used to IE bugs that they don't seem to have cared overly much, so I guess it all evens out in the wash.
Re: (Score:2)
This is actually explai
Where are the perlheads? (Score:5, Interesting)
Where has all the perl love gone?
Re: (Score:1, Insightful)
There's no reason to think that a rewrite of any large perl program wouldn't retain some perl bits or that most programs of this nature wouldn't benefit from some perl here and there. The point is that perl need not and should not be the core of a large project like this.
It's nothing against perl.
It's like building a stereo system: there's a few key components you want to go balls to the wall on (eg, speak
Re: (Score:2)
Re:Where are the perlheads? (Score:4, Insightful)
When I was taught Perl, I thought 'cool a better, more powerful, portable shell' and then I had to maintain Perl's code, some written by beginners and some by 'experts'.. And I discovered what a mess Perl is..
Sure it's portable but the language don't give you the correct defaults so beginners code is usually awful AND experienced Perl coders let them sucked by TWTDI which makes their code hard to maintain by anybody else..
It takes *a lot* of self-discipline to write maintainable/readable Perl, so not surprisingly lots of Perl code is junk.
Hating Perl, I looked for another language and found Ruby which unfortunately I don't use that much as my boss won't let me do it (not widespread enough for him), *sigh* such a beautiful language and having to use shell or Perl instead..
self-discipline and languages (Score:2, Insightful)
It takes a lot of self-discipline -- a lot -- to write readable, well-structured English -- even more so than Perl, because it doesn't even have to pass a syntax check -- so not surprisingly, lots of English is junk. Perl purports to be accessible to beginners and experts, and to make easy things easy and difficult things possible, and as a result, it's more feasible to turn a poor des
Re: (Score:2)
Have you tried Python? It seems to live in the same problem space as Ruby, but has the boss-wowing factor of being a paid project of Google.
Re: (Score:2)
The thing: with the number of tools written in shell&Perl, you cannot avoid having those two installed, and advocating a *third* interpreter is a hard sell (plus he didn't like the space indentation of Python).
Re: (Score:2)
Perl is more sublime (Score:2)
Unlike Python or Ruby on Rails, one is not required to swear a blood oath to evangelize Perl at every opportunity to be a Perl hacker. So, the Perl lovers are probably off writing code instead of doing songs and dances here on Slashdot. Its evangelized in a more sublime way - working code. Yeah, that's probably not as effective marketing in today's "ooh, shiny" society.
I'm not sure what the release manager is thinking. Perl 5 hasn't changed drastically in quite a while s
Re: (Score:2)
The python stuff is pretty bogus. You don't need a special editor to recognize indent blocks. (Hint: Look for things 4 spaces further away from the margin than the line before). That said, python is slower than perl for many things. I've written internal webpages in python but I've not seen many comercial websites done in Python. There is probably a reason for that.
Ruby. Don't know. Joel on Software says it's slow. Otherwise,
Re: (Score:2)
Check out reddit.com
Re: (Score:2)
Speaking as someone who writes pretty much all of his non-C/sh in python nowadays, I call BS ... Python has a lot of things going for it, but making invisible characters part of the syntax isn't one of them.
Maybe you don't think you need real begin/end markers to read code, but I find it very painful to not have them ... and
Re: (Score:1)
-Max
Trac is da bomb (Score:5, Interesting)
Re: (Score:3, Informative)
At work, I use 4 different bug databases, 3 of them are bugzilla and one a home grown one. Moving bug
Re: (Score:1, Informative)
Re:Trac is da bomb (Score:4, Interesting)
The main reason why Trac is so successful is indeed the flat learning curve / simple interface. Two sentences along the lines of "If you add a new ticket here, I'll get right on it" are enough. Clients happy because they can easily bug me and have an overview of past tickets, I'm happy because of the decrease of postit's on my monitor.
Oh, Bugzilla you ask? I've had to deal with it in the past for a few OSS projects. I'm still scared of it, and wouldn't let my clients near it even if they begged me. It might be more useful when you have hundreds of technical users working on a single project with needs like reporting and time tracking, but for anything less a more flexible alternative is preferable, IMHO.
Re: (Score:3, Interesting)
This is so interesting.... something must have changed at say 2.2 or 2.3 cause back at 2.16 of Bugzilla I as a designer with about 6 months or perl exposure (but plenty of html + css + javascript) went in to the Bugzill
Re: (Score:2)
Bugzilla is too hard-coded as a software issue tracker, but Trac is even more so. Both begin to break down when used for tracking hardware problems, customer inquiries, etc. We're still searching...
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
After all, a defect should be findable by a test case (else you should create new one), and calculating defect count for a feature/requirement is a good thing to have.
Integration to SVN is a very good feature (which QC lacks).
Perl community to Bugzilla community... (Score:3, Insightful)