Hans de Graaff <graaff(a)gentoo.org> writes:
On Sun, 2007-08-26 at 22:56 +0200, Adrian Aichner wrote:
> Selecting the right product for the job.
This seems to depend on the steps below. I don't think enough wil have
changed to seriously undermine the earlier preference for Roundup.
> Finding a reliable host for the bug tracking services.
I would assume that this would be the same host that currently hosts the
XEmacs website and/or CVS, but I don't know how any of this is organized
and consequently whether that is possible.
We have three master websites equally up-to-date, hosted by
Tux.org,
SourceForge, and
dotsrc.org.
Our CVS sources live at
dotsrc.org.
DNS, mailing lists, archives, and mail list aliases are hosted by
Tux.org.
We had permanent mailing list setup data-loss on
tux.org a little less
than a year ago and it's hard to get admin attention from them since
then.
> Starting with requirements, at least some of us have a strong desire
> for a bug tracking system that can be operated via email as well as
> via web interface.
Ok people, if there are other requirements throw them out on the list
and I'll collect it into something coherent.
Great, thanks!
> External interfaces would be important too, so that we can seed the
> database from the existing bug information, which currently basically
> exists in bug reports to xemacs-beta.
Personally I'm not sure it's worth it to do this. Might be better to
just start over with a clean slate.
Hans, the export/import requirement is just a general requirement
against vendor lockin that we should keep in mind.
Importing legacy data is a thing I could imagine doing myself.
It might be a good idea to start importing recent data and work our
way back.
But hey, the nice thing about import/export interfaces is that once
you tested your im/exporters on a dataset diverse enough you have your
problem solved and don't have to worry whether to import 100 or 1000
defects.
> If I recall right then Stephen was favoring roundup[1].
Ok. I have personal experience with Trac. We use this in-house and it is
Ah, I came across Trac also roughly a week ago.
fine for that. Not sure I'm happy to use it for an open-source
project.
Why would you not necessarily recommend it for an open-source project?
What do you see as Trac's pros and cons?
With Gentoo we're using Bugzilla, but that may be overkill for
XEmacs?
Are you suggesting that Bugzilla is the most powerful?
Stephen made some comment about Bugzilla being written in perl and the
code not seeming easy to maintain.
Are you familiar with some of the internals of Bugzilla?
Especially any use model shortcomings would be interesting to know.
From submitting and tracking some firefox defects and hanging out on
#firefox a bit in the past, I found that integration quie likable.
> Would you personally be interested in getting XEmacs a bug tracker?
I guess I'm volunteering to put some time into this, yes.
Hey, that's great news!
I'll try to help you work out some sysadmin issues, like finding a
place to install the thing.
Best regards!
Adrian
Kind regards,
Hans
--
Adrian Aichner
mailto:adrianï¼ xemacs.org
http://www.xemacs.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta