Re: [SLUG] bugzilla setup
I got bugzilla working OK.For the record I had to create a link, this was missing /usr/share/bugzilla3/web/ /var/www/bugzilla3 I then had to hack out security from the scripts to configure it then reinstate it. Not sure what I did wrong in the set up. I got this error attempt to invoke directory as script: /usr/lib/cgi-bin/bugzilla3/ I had scriptalias in my apache setup. This line had scriptalias and it stopped index.cgi being used. /etc/apache2/sites-available/default Alias /cgi-bin/ /usr/lib/cgi-bin/ Finally I got a couple of skins from https://wiki.mozilla.org/Bugzilla:Addons I went to /var/www/bugzilla3/skins and linked contrib/BrownCurvy/ to custom and it looks pretty nice now. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] bugzilla setup
On Wed, 2009-03-11 at 11:23 +1100, Daniel Pittman wrote: The biggest thing, though, is for you to identify what you actually want to achieve with this. Without knowing that there are some very different options available, and probably only some will help you. Multiple clients, different applications and projects per client. The different clients should not even know that the others exist. Right now it is about bug tracking but a full management process would be nice in the future. I was going to set up a wiki as well so if this was integrated it would be nice. Ability to store email for traceability would be good. Ability to totally remove projects from the online once closed. There are some potentially huge files in these projects. Ability to restore projects, to main server or a backup server, to locate information on a closed project. Ta Ken -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] bugzilla setup
Ken Foskey fos...@tpg.com.au writes: On Wed, 2009-03-11 at 11:23 +1100, Daniel Pittman wrote: The biggest thing, though, is for you to identify what you actually want to achieve with this. Without knowing that there are some very different options available, and probably only some will help you. Multiple clients, different applications and projects per client. The different clients should not even know that the others exist. Right now it is about bug tracking but a full management process would be nice in the future. Well, from my experience you have two options in the free space: 1. Set up a separate bug tracking system (eg trac, bugzilla) for each client and/or project. 2. Use RT, and configure it with appropriate security. You are not going to get project planning, etc, out of RT though, since it is just a ticket management system. Sadly, you won't get the multi-client security out of anything else, though, so you are kind of stuck. Um, unless you pay big $$$ to someone commercial, which I don't recommend; it usually doesn't pay for itself. I was going to set up a wiki as well so if this was integrated it would be nice. Ability to store email for traceability would be good. RT handles the later, but not the wiki integration as such. It does have stable, predictable URL support, the ability to extend the UI and a good scripting API, though, so it is possible to integrate it to whatever external tools you wish. Ability to totally remove projects from the online once closed. RT doesn't delete things, but you can mark them deleted and they never show up unless you specifically search them. This is a feature. :) For others ... I don't know. We wouldn't use such a feature. There are some potentially huge files in these projects. You would want to store those in your VCS, not the ticketing system, if at all possible. Which VCS is best is a whole different discussion. Ability to restore projects, to main server or a backup server, to locate information on a closed project. ...as noted, we wouldn't use such a feature, since we want to refer to historical projects if the issue comes up.[1] Regards, Daniel Footnotes: [1] I suppose that after seven or ten years of project completion, when it isn't going to be refered to ever again we might consider it, but why bother? Storage is stupidly inexpensive... -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] bugzilla setup
I am trying to get bugzilla3 working on my ubuntu server and it looks awful. Is there a CSS that needs to be installed to make it look nice? Is there a better very simple web based bug tracking that I should be using? Ta Ken -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] bugzilla setup
quote who=Ken Foskey I am trying to get bugzilla3 working on my ubuntu server and it looks awful. Is there a CSS that needs to be installed to make it look nice? GNOME has one of the prettiest and most useful Bugzilla setups around; you might want to check out what they've done to it. Pretty sure it's still on Bugzilla 2.x though. Is there a better very simple web based bug tracking that I should be using? Well, pretty much anything else is simpler and easier than Bugzilla. It was really designed for very big projects with well-understood processes (such as Mozilla, where it was born, and GNOME, where it continues to thrive). Despite its warts, I quite like trac, particularly if you effectively use all of its components (wiki, bug tracker, svn viewer, basic project mgmt, etc). - Jeff -- linux.conf.au 2010: Wellington, NZ http://www.penguinsvisiting.org.nz/ I haven't been this excited since the introduction of devfs. - Mark Rosenstand on upstart-devel list -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] bugzilla setup
2009/3/10 Ken Foskey fos...@tpg.com.au: Is there a better very simple web based bug tracking that I should be using? I can highly recommend Redmine[0]. It's written in Rails, and is very easy to set up. I've heard people complain about previous versions, but the current release s pretty great - I use it for all of my client projects. Lindsay -- http://holmwood.id.au/~lindsay/ (me) -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] bugzilla setup
2009/3/11 Lindsay Holmwood lind...@holmwood.id.au: I can highly recommend Redmine[0]. It's written in Rails, and is very easy to set up. Might be helpful if I link :-) [0] http://www.redmine.org/ -- http://holmwood.id.au/~lindsay/ (me) -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] bugzilla setup
Ken Foskey fos...@tpg.com.au writes: I am trying to get bugzilla3 working on my ubuntu server and it looks awful. Is there a CSS that needs to be installed to make it look nice? You can look forward to a lot of customization to make it work more nicely; at least, that is the solution that everyone using a nice BugZilla has taken. Is there a better very simple web based bug tracking that I should be using? Almost certainly. For a single-product or product-family software development project trac, and possibly redmine, are a substantial improvement in providing ticketing, project planning and documentation in a single site. For supporting multiple products to end users Request Tracker is one of the best options available; it makes it possible for end users to interact sanely with the same bug system that your internal staff use, and provides sufficient security to make that sensible. The biggest thing, though, is for you to identify what you actually want to achieve with this. Without knowing that there are some very different options available, and probably only some will help you. Regards, Daniel -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
