11:24 a.m.
I'm finding that I'm increasingly less motivated to report issues, bug
fixes, and patches that are coming out of maintenance of XEmacs for
Gentoo. I think that this is mainly caused by the lack of a bug tracker,
so I'll present the case for one and end by asking why there isn't one
currently, whether one is wanted, and what steps are needed to make this
happen.
For me providing patches to XEmacs is really a fire-and-forget thing. I
send out the message, maybe something happens, maybe not, depending on
interestingness and availability, and if nothing happens in a short
period of time the work is essentially lost. Other people won't be able
to easily search for it, comment on it, or amend it. It also makes
tracking fixes much harder than it would need to be. Having a single
reference to a bug report or patch makes it a lot easier to keep an eye
on progress and help things along if needed.
I also feel that the lack of a bug tracker is holding back growth of
XEmacs development. Helping out with filling bugs, commenting on bugs,
testing patches, providing fixes for easy problems and progressing to
more complex work is a natural way to attract new people to the
development team, but without a place to work on it this is much less
likely to happen. A set of mailing lists is really a very poor
substitute for such a workflow.
Looking at http://www.xemacs.org/Debug/index.html it seems that there is
latent interest in having a bug tracker in place, given the comment at
the bottom. So, my questions:
Is a bug tracker still wanted?
Has any work been done on this already?
What would be the next steps for making this happen?
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:39 p.m.
Hi Hans
You wrote:
Hans> Is a bug tracker still wanted?
I think so. The questions pops up once in a while.
I agree with your analysis. I think a tracker will make it easier to
get involved. As it is now it is hard to understand what issues there
are.
Hans> Has any work been done on this already?
I think that there was a go at it for some years ago with some bad
results, which might explain why there isn't a bug tracker now, but I
might be wrong here.
The issue tracker "roundup" has been suggested.
Hans> What would be the next steps for making this happen?
That one, or even better a few, volunteers to maintain the issues in
the tracker in order to unsure the quality.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:07 p.m.
Mats> The issue tracker "roundup" has been suggested.
The Python folks just switched from SF to Roundup after a long gestation
period a few days ago. If you're interested in the (still fresh) experience
from that group, I suggest you send a message to
tracker-discuss(a)python.org.
There are actually two trackers, one for Python proper and a "meta" tracker
for the changes the Python people made to Roundup. I believe the meta
tracker uses Roundup out-of-the-box. There was quite a bit of customization
to Roundup to provide the extra features desired. Everything is available
from Subversion. If it was okay with the people involved I don't see any
reason why you couldn't create a branch to add XEmacs-specific
customizations (most likely skin/theme stuff).
I had a peripheral hand in things, writing some plugin code for SpamBayes to
handle anti-spam duties.
--
Skip Montanaro - skip(a)pobox.com - http://www.webfast.com/~skip/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:17 a.m.
On Sun, 2007-08-26 at 16:07 -0500, skip(a)pobox.com wrote:
There are actually two trackers, one for Python proper and a
"meta" tracker
for the changes the Python people made to Roundup. I believe the meta
tracker uses Roundup out-of-the-box. There was quite a bit of customization
to Roundup to provide the extra features desired. Everything is available
from Subversion. If it was okay with the people involved I don't see any
reason why you couldn't create a branch to add XEmacs-specific
customizations (most likely skin/theme stuff).
Customization always makes me nervous because it will increase
maintenance cost and may even lock you down to a particular version.
I would also assume that skin/theme stuff would be supported out of the
box and be part of the normal installation.
In any case thanks for the pointer, it may be useful to talk to these
guys and learn from them.
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
12:21 p.m.
Hans> Customization always makes me nervous because it will increase
Hans> maintenance cost and may even lock you down to a particular
Hans> version.
Users are typically expected to customize their Roundup installation to
their needs. It was designed with that in mind. It has a very flexible
architecture that supports user-provided plugins. I believe that's where
the bulk of the customization lies. Also, the Roundup maintainer is closely
involved with this particular instance (it is written in Python). I'm sure
any general fixes to the Roundup core were fed back for future releases.
Hans> I would also assume that skin/theme stuff would be supported out
Hans> of the box and be part of the normal installation.
That's quite possible. I wasn't involved at that level.
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:59 p.m.
skip(a)pobox.com writes:
Mats> The issue tracker "roundup" has been
suggested.
The Python folks just switched from SF to Roundup after a long gestation
period a few days ago. If you're interested in the (still fresh) experience
from that group, I suggest you send a message to
tracker-discuss(a)python.org.
There are actually two trackers, one for Python proper and a "meta" tracker
for the changes the Python people made to Roundup. I believe the meta
tracker uses Roundup out-of-the-box. There was quite a bit of customization
to Roundup to provide the extra features desired. Everything is available
from Subversion. If it was okay with the people involved I don't see any
reason why you couldn't create a branch to add XEmacs-specific
customizations (most likely skin/theme stuff).
I had a peripheral hand in things, writing some plugin code for SpamBayes to
handle anti-spam duties.
Thanks skip, that should be useful if we select roundup.
--
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
9:28 a.m.
Mats Lidell writes:
Hans> Has any work been done on this already?
I think that there was a go at it for some years ago with some bad
results, which might explain why there isn't a bug tracker now, but I
might be wrong here.
We've had two full-blown trackers, first gnats and then jitterbug.
Both were simply black holes for problem reports.
The issue tracker "roundup" has been suggested.
Roundup is the only one I'm interested in working with, either in
terms of maintaining it or in terms of using it to focus a release, if
people really want me to do the next release. It's very easy to
customize, and I really hate the default organization in all trackers
I've ever used. It also would be easy to prime the database with past
reports, and inject them in batches.
Bugzilla -- fails both the email and XEmacs client tests. We were
offered an email-capable Bugzilla with the code being supported by
SuSE, but my understanding is that Novell has deep-sixed that code.
gnats -- too 16th century.
jitterbug -- maybe it's ok now, but it was a jinx at the time.
Trac -- nobody who has used the MacPorts Trac would be willing to use
Trac. That includes me.
RT -- looks OK in principle, but I will not maintain a big ball of
Perl; we'll need a reliable volunteer for that. I also seem to recall
it doesn't do email very well.
Hans> What would be the next steps for making this happen?
That one, or even better a few, volunteers to maintain the issues in
the tracker in order to unsure the quality.
We need one, no more and no less, really. Having others to help is
fine, but there needs to be one somebody who does the work at a least
a couple times a week and stays on top of the thing. The Python
tracker reports are nice, and something similar probably would do the
trick. It looks mostly automated.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:21 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Trac -- nobody who has used the MacPorts Trac would be willing to
use
Trac. That includes me.
I also dislike Trac after having used it for R6RS. I also seemed buggy
as hell to me.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:07 a.m.
On Tue, 2007-08-28 at 17:28 +0900, Stephen J. Turnbull wrote:
We've had two full-blown trackers, first gnats and then
jitterbug.
Both were simply black holes for problem reports.
I've also found http://sourceforge.net/tracker/?group_id=11 (project 11
on sourceforge? Nice). Obviously this has not actually been used, but it
could be without any additional work. I think the lack of email handling
will be the greatest issue here.
Roundup is the only one I'm interested in working with, either
in
terms of maintaining it or in terms of using it to focus a release, if
people really want me to do the next release. It's very easy to
customize, and I really hate the default organization in all trackers
I've ever used. It also would be easy to prime the database with past
reports, and inject them in batches.
It would be helpful to know what it is that you hate about the default
organization of all trackers.
Bugzilla -- fails both the email and XEmacs client tests. We were
offered an email-capable Bugzilla with the code being supported by
SuSE, but my understanding is that Novell has deep-sixed that code.
No longer true for Bugzilla 3.0 as it has email support built-in, and
bugzilla now seems to be actively developed again with a recent 3.0.1
and a 3.1 development version. No more waiting 8 years on the next
release, it seems.
The XEmacs client test will fail on all trackers, including roundup.
RT -- looks OK in principle, but I will not maintain a big ball of
Perl; we'll need a reliable volunteer for that. I also seem to recall
it doesn't do email very well.
According to the docs it does have an incoming email interface. The docs
don't say whether it works well. :-)
We need one, no more and no less, really. Having others to help is
fine, but there needs to be one somebody who does the work at a least
a couple times a week and stays on top of the thing. The Python
tracker reports are nice, and something similar probably would do the
trick. It looks mostly automated.
Agreed that someone should be responsible for it with a backup in case
of absense. Having all bug reports be vetted by a single person helps a
lot in dealing with duplicates and proper reporting.
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:55 a.m.
Hans de Graaff writes:
I've also found http://sourceforge.net/tracker/?group_id=11
(project 11
on sourceforge? Nice). Obviously this has not actually been used, but it
could be without any additional work.
SF Tracker is what Python decided was so unbearable that they decided
*anything* would be better. Having decided that, they went to work on
beating Roundup into shape, that being what they got the most serious
volunteers to work on.
It would be helpful to know what it is that you hate about the
default
organization of all trackers.
In no particular order:
- No provision for generating/maintaining relationships among products
(aka modules), files, identifiers, and keywords.
- Severity is not an ordered variable; it should be set valued,
including such properties as "crash", "data loss", "workaround
available", and suchlike.
- Urgency is not a user or developer variable, and should be
suppressed unless there's a manager with authority to decide such
things.
- The available keywords never make any sense, and there's no
provision for creating a thesaurus of synonym keywords. There's
rarely a facility for browsing or searching keywords.
- Every bug report should be treated as a query-by-example, and the
reporter immediately presented with a short list of bugs (maybe as
many as 10 at most) with the highest similarity.
No longer true for Bugzilla 3.0 as it has email support built-in,
I forget to mention I've hated bugzilla for years, I'm not sure why.
Several of the above have something to do with it, I'm sure. :-) Plus
it's a big ball of Perl, so I'll have to depend on others to implement
any changes I want. And it seems to be the tracker of choice for big
institutional devel organizations like Red Hat.
The XEmacs client test will fail on all trackers, including roundup.
If you define it the way Steve Baur does, yes. However, I happen to
have libcurl and libneon bindings in my XEmacs, so as long as the web
interface is sane, I can use HTTP + HTML to make an XEmacs
interface.:-)
The other thing about roundup is that its architecture makes it
eminently hackable.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:37 p.m.
Stephen> Hans de Graaff writes:
> I've also found http://sourceforge.net/tracker/?group_id=11
(project
> 11 on sourceforge? Nice). Obviously this has not actually been used,
> but it could be without any additional work.
Stephen> SF Tracker is what Python decided was so unbearable that they
Stephen> decided *anything* would be better. Having decided that, they
Stephen> went to work on beating Roundup into shape, that being what
Stephen> they got the most serious volunteers to work on.
True, but for better or for worse SF served the Python community's needs for
several years. You could have a reasonable (not perfect, not horrible)
tracker in use today if you wanted. Martin v. Loewis indicated that
Python's Roundup schema was heavily influenced by the SF schema:
... the schema was heavily influenced by the SF schema - so if you
migrate from SF, using the bugs.python.org schema might be a good
idea. Otherwise, I cannot see it as better or worse than the classic
schema.
Stephen> - Urgency is not a user or developer variable, and should be
Stephen> suppressed unless there's a manager with authority to decide such
Stephen> things.
SF suffers from this as well. No matter how many times we asked people to
not diddle the priority field someone would invariably submit a bug report
for something pretty trivial right before a Python release was due to go out
the door and mark it high priority. That would cause the release train to
briefly grind to a halt as a number of people stopped what they were doing
to check it out. The submitter should generally not be able to set the
urgency of a bug report. That's for whoever is performing triage at the
time.
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:25 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Hans de Graaff writes:
> I've also found http://sourceforge.net/tracker/?group_id=11 (project 11
> on sourceforge? Nice). Obviously this has not actually been used, but it
> could be without any additional work.
SF Tracker is what Python decided was so unbearable that they decided
*anything* would be better. Having decided that, they went to work on
beating Roundup into shape, that being what they got the most serious
volunteers to work on.
> It would be helpful to know what it is that you hate about the default
> organization of all trackers.
In no particular order:
- No provision for generating/maintaining relationships among products
(aka modules), files, identifiers, and keywords.
- Severity is not an ordered variable; it should be set valued,
including such properties as "crash", "data loss",
"workaround
available", and suchlike.
I like you list, Stephen.
Another thing I find important is a state machine to allowed status
transitions.
I just convinced myself that roundup supports this:
http://roundup.sourceforge.net/doc-1.0/customizing.html#adding-in-state-t...
A distinction between Resolved and Verified (or whatever we may call
it) is also important to me.
http://roundup.sourceforge.net/doc-1.0/customizing.html
has this relevant piece of information:
creator_resolution.py
Catch attempts to set the status to "resolved" - if the assignedto
user isn't the creator, then set the status to
"confirm-done". Note that "classic" Roundup doesn't have that
status, so you'll have to add it. If you don't want to though,
it'll just use "in-progress" instead.
I like roundup more and more from reading the docs.
Adrian
- Urgency is not a user or developer variable, and should be
suppressed unless there's a manager with authority to decide such
things.
- The available keywords never make any sense, and there's no
provision for creating a thesaurus of synonym keywords. There's
rarely a facility for browsing or searching keywords.
- Every bug report should be treated as a query-by-example, and the
reporter immediately presented with a short list of bugs (maybe as
many as 10 at most) with the highest similarity.
> No longer true for Bugzilla 3.0 as it has email support built-in,
I forget to mention I've hated bugzilla for years, I'm not sure why.
Several of the above have something to do with it, I'm sure. :-) Plus
it's a big ball of Perl, so I'll have to depend on others to implement
any changes I want. And it seems to be the tracker of choice for big
institutional devel organizations like Red Hat.
> The XEmacs client test will fail on all trackers, including roundup.
If you define it the way Steve Baur does, yes. However, I happen to
have libcurl and libneon bindings in my XEmacs, so as long as the web
interface is sane, I can use HTTP + HTML to make an XEmacs
interface.:-)
The other thing about roundup is that its architecture makes it
eminently hackable.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
--
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
8:15 p.m.
> SF Tracker is what Python decided was so unbearable that they
decided
> *anything* would be better. Having decided that, they went to work
> on beating Roundup into shape, that being what they got the most
> serious volunteers to work on.
Let me elaborate on this a bit. The SF tracker's feature set was only part
of the problem, and often not the main problem. Sure, there were things
we'd wished their tracker did differently, but the performance of the SF
systems and poor response to RFEs to the system were probably more important
than the available feature set. Again, related to release schedules, there
were times nearing releases when SF was unavailable. As people were more
actively working on identifying and fixing bugs during the time just before
a release it was completely unacceptable for the bug tracker to simply go
away. It doesn't matter how perfectly its features suit your development
style if it's not reliable.
This was also the main reason Python stopped hosting its source code on SF.
We switched to a self-hosted Subversion repository, again, with a lot of
work by Martin v. Loewis on conversion tools (cvs2svn in this case). If you
were to ask Martin, I'm fairly certain he will tell you he would rather to
have not had to do it. Switching from CVS to Subversion and remaining at SF
would have been a lot easier.
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:24 p.m.
> RT -- looks OK in principle, but I will not maintain a big ball
of
> Perl; we'll need a reliable volunteer for that. I also seem to
> recall it doesn't do email very well.
Hans> According to the docs it does have an incoming email
Hans> interface. The docs don't say whether it works well. :-)
We use RT 3.4.1 (circa 2004) at work. It supports email just fine.
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:46 p.m.
skip(a)pobox.com writes:
>> RT -- looks OK in principle, but I will not maintain a
big ball of
>> Perl; we'll need a reliable volunteer for that. I also seem to
>> recall it doesn't do email very well.
Hans> According to the docs it does have an incoming email
Hans> interface. The docs don't say whether it works well. :-)
We use RT 3.4.1 (circa 2004) at work. It supports email just fine.
But isn't RT just a ticketing system for helpdesk type tracking?
I've been a user of it at work for years.
It made issues visible and accountable.
But I wouldn't view it as a serious bug tracking system.
We're using ClearQuest at work for bug/feature tracking and it sure is
powerful.
The challenge with any bug tracking system we put into place will be
to keep the data fresh and accurate.
Adrian
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
--
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
7:22 p.m.
> We use RT 3.4.1 (circa 2004) at work. It supports email just
fine.
Adrian> But isn't RT just a ticketing system for helpdesk type tracking?
I guess so. Our development group (of which I am a part) also use it for
bug tracking. It's not perfect, but it works. From my perspective the
single most important thing about a tracker is that requests not get lost.
RT's search mechanism is clunky. Sometimes I misplace an item, but I can
easily see everything that's assigned to me and use their arcane search form
to find anything else.
Many developers use the RT ticket number to create a named branch for an
application or library when working on a bug. Once the bug is squashed,
that branch gets merged back to CVS head.
I'm no expert on these tools, but helpdesk tracking and bug tracking do have
a lot in common. In our environment an application user may no know much
other than "it's broken". Our admins perform first-level triage. They can
fix some things, especially stuff dealing with networking issues. Other
things they move into the appropriate queue and assign to a developer.
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:56 p.m.
>>>> Adrian Aichner <adrian(a)xemacs.org> writes:
APA> The challenge with any bug tracking system we put into place will
APA> be to keep the data fresh and accurate.
Although this is of course true I must insist on that tracking bugs is
first of all just a tool for getting the bugs out of the code. The
collection of bugs doesn't need to be more complete, fresh and
accurate than to support the bug fixing process.
Likewise for the tracker itself. The bug should stay as short time as
possible in the tracker so why try to make it such a nice place. Then
the bug will want to stay longer. ;-) If the administration of the bug
starts to get a pain, fix the bug and get rid of it!
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:38 a.m.
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>> Adrian Aichner <adrian(a)xemacs.org> writes:
APA> The challenge with any bug tracking system we put into place will
APA> be to keep the data fresh and accurate.
Although this is of course true I must insist on that tracking bugs is
first of all just a tool for getting the bugs out of the code. The
collection of bugs doesn't need to be more complete, fresh and
accurate than to support the bug fixing process.
Likewise for the tracker itself. The bug should stay as short time as
possible in the tracker so why try to make it such a nice place. Then
the bug will want to stay longer. ;-) If the administration of the bug
starts to get a pain, fix the bug and get rid of it!
I don't think so, Mats.
Bugs will stay in the system forever.
Hopefully they will make it to the fixed and even verified state
quickly.
Ideally a test will be written against each defect, so that deja vu
bugs will stay a lesser chance to silently sneak in.
If they do, the bug can just be re-opened again.
Bug history is another great feature of a good defect tracking system.
Adrian
Yours
--
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
7:57 a.m.
Adrian Aichner writes:
Bugs will stay in the system forever.
I know. I just want to move the focus a bit. It is so easy to get stuck
in a fight for your favorite feature so you forget why we need the
tracker in the first place.
Hopefully they will make it to the fixed and even verified state
quickly.
Ideally a test will be written against each defect, so that deja vu
bugs will stay a lesser chance to silently sneak in.
If they do, the bug can just be re-opened again.
Bug history is another great feature of a good defect tracking system.
These are all good things but I think we should adopt a more iterative
approach. Take the need to reopen a bug. This needs only to be
implemented the day we find that we have had to reopen so many bugs that
we are getting bored in filing them again.
Anyway. If the feature debate can converge it is all good and well. I'm
not against having features. We should just don't forget that it is a tool.
My vote goes for roundup. Seems possible to use without to much work and
can be adjusted if needed in the future. (And I happen to like python!)
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:29 p.m.
Hans de Graaff <graaff(a)gentoo.org> writes:
On Tue, 2007-08-28 at 17:28 +0900, Stephen J. Turnbull wrote:
> We've had two full-blown trackers, first gnats and then jitterbug.
> Both were simply black holes for problem reports.
I've also found http://sourceforge.net/tracker/?group_id=11 (project 11
on sourceforge? Nice). Obviously this has not actually been used, but it
could be without any additional work. I think the lack of email handling
will be the greatest issue here.
Yeah,
http://sourceforge.net/search/index.php?group_id=1&words=submitted_by...
reminds me what a pain it was using that tracker (for project sourceforge.net).
I'm strictly opposed to a web-interface-only bug tracking system from
a user point of view even, let alone as an admin.
> Roundup is the only one I'm interested in working with, either in
> terms of maintaining it or in terms of using it to focus a release, if
> people really want me to do the next release. It's very easy to
> customize, and I really hate the default organization in all trackers
> I've ever used. It also would be easy to prime the database with past
> reports, and inject them in batches.
It would be helpful to know what it is that you hate about the default
organization of all trackers.
> Bugzilla -- fails both the email and XEmacs client tests. We were
> offered an email-capable Bugzilla with the code being supported by
> SuSE, but my understanding is that Novell has deep-sixed that code.
No longer true for Bugzilla 3.0 as it has email support built-in, and
bugzilla now seems to be actively developed again with a recent 3.0.1
and a 3.1 development version. No more waiting 8 years on the next
release, it seems.
The XEmacs client test will fail on all trackers, including roundup.
> RT -- looks OK in principle, but I will not maintain a big ball of
> Perl; we'll need a reliable volunteer for that. I also seem to recall
> it doesn't do email very well.
According to the docs it does have an incoming email interface. The docs
don't say whether it works well. :-)
> We need one, no more and no less, really. Having others to help is
> fine, but there needs to be one somebody who does the work at a least
> a couple times a week and stays on top of the thing. The Python
> tracker reports are nice, and something similar probably would do the
> trick. It looks mostly automated.
Agreed that someone should be responsible for it with a backup in case
of absense. Having all bug reports be vetted by a single person helps a
lot in dealing with duplicates and proper reporting.
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
--
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
9:56 p.m.
Hans de Graaff <graaff(a)gentoo.org> writes:
I'm finding that I'm increasingly less motivated to report
issues, bug
fixes, and patches that are coming out of maintenance of XEmacs for
Gentoo. I think that this is mainly caused by the lack of a bug tracker,
so I'll present the case for one and end by asking why there isn't one
currently, whether one is wanted, and what steps are needed to make this
happen.
Hello Hans, I'm with you.
For me providing patches to XEmacs is really a fire-and-forget thing. I
send out the message, maybe something happens, maybe not, depending on
interestingness and availability, and if nothing happens in a short
period of time the work is essentially lost. Other people won't be able
to easily search for it, comment on it, or amend it. It also makes
tracking fixes much harder than it would need to be. Having a single
reference to a bug report or patch makes it a lot easier to keep an eye
on progress and help things along if needed.
I agree completely.
I also feel that the lack of a bug tracker is holding back growth of
XEmacs development. Helping out with filling bugs, commenting on bugs,
testing patches, providing fixes for easy problems and progressing to
more complex work is a natural way to attract new people to the
development team, but without a place to work on it this is much less
likely to happen. A set of mailing lists is really a very poor
substitute for such a workflow.
Looking at http://www.xemacs.org/Debug/index.html it seems that there is
latent interest in having a bug tracker in place, given the comment at
the bottom. So, my questions:
Yep, I wrote the above in that web page.
Is a bug tracker still wanted?
Yes.
Has any work been done on this already?
Stephen has looked into this most.
How currently out of touch, but I guess we will comment when he gets a
chance to read the lists.
What would be the next steps for making this happen?
Selecting the right product for the job.
Finding a reliable host for the bug tracking services.
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.
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.
If I recall right then Stephen was favoring roundup[1].
Would you personally be interested in getting XEmacs a bug tracker?
Best regards!
Adrian
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Footnotes:
[1] http://roundup.sourceforge.net/
--
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
7:13 a.m.
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.
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.
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.
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
fine for that. Not sure I'm happy to use it for an open-source project.
With Gentoo we're using Bugzilla, but that may be overkill for XEmacs?
Would you personally be interested in getting XEmacs a bug tracker?
I guess I'm volunteering to put some time into this, yes.
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:31 a.m.
Hans de Graaff writes:
Personally I'm not sure it's worth it to do this. Might be
better to
just start over with a clean slate.
Yes. Feeding the tracker with all old issues has been a wish, I think,
but IMHO we don't need to do that. Old issues can be kept in the mail
archives and selectively be inserted in the tracker if needed. For
instance when an old bug pops up again or when someone is attempting to
fix it.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:57 p.m.
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
3:03 a.m.
Adrian> Hans, the export/import requirement is just a general
Adrian> requirement against vendor lockin that we should keep in mind.
I'm fairly sure Roundup supports this. The Python gang wrote a
SF-to-Roundup tool to take an XML dump of the SF data and import it into our
tracker. As I recall that was an interesting exercise in part because SF
changed their dump format once or twice during the test period.
Adrian> It might be a good idea to start importing recent data and work
Adrian> our way back.
That will be manual, yes? I thought the only source of XEmacs bug reports
was on the mailing list.
Adrian> But hey, the nice thing about import/export interfaces is that
Adrian> once you tested your im/exporters on a dataset diverse enough
Adrian> you have your problem solved and don't have to worry whether to
Adrian> import 100 or 1000 defects.
True enough. Python had been with SF for several years. That has all been
imported into the new tracker.
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:59 a.m.
On Mon, 2007-08-27 at 23:57 +0200, Adrian Aichner wrote:
Hans, the export/import requirement is just a general requirement
against vendor lockin that we should keep in mind.
That's a good point.
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.
I think that this should be a manual process anyway, given that there is
no bug history to speak of that is structured.
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.
Sure, but there isn't anything to import *from* in this case. Well,
there is the mailing list, and I'm sure different people have different
stashes of bug reports squirreled away for a rainy day, but I'm not sure
that dumping all of these into a bug tracker without actually looking at
them will be a good idea.
> 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?
I guess I really should have said 'public project'.
What do you see as Trac's pros and cons?
It's pro is that it has a wiki, source browser, and bug tracker all
rolled in one, so to support our in-house development it is nice. In the
wiki you can refer directly to bugs and code revisions which is helpful.
But the bug tracker doesn't really have features that help if you have a
lot of bugs and duplicates. Things like a user account and reporting are
not very well developed, I have the feeling that it doesn't support the
workflow for this. A good example of a large installation would be the
ruby on rails trac: http://dev.rubyonrails.org/wiki Somehow I always
feel lost in it, though. Looking back at what I wrote I don't really see
a good argument, just a feeling. :-)
> With Gentoo we're using Bugzilla, but that may be overkill
for XEmacs?
Are you suggesting that Bugzilla is the most powerful?
At least as a user (both submitting and managing/resolving bugs) I'm
most happy with Bugzilla. I use Gentoo's bugzilla a lot, and also
Gnome's bugzilla to some extend.
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?
Nope, not familiar with the internals. As far as I understand it the new
version 3.0 should have a much restructured codebase. New in version
3.0: custom fields, XML-RPC interface (aka XEmacs lisp client ;-),
create and modify bugs by email. Guessing that Steven looked at some 2.x
version, it may actually be worth it to check out 3.0.
Especially any use model shortcomings would be interesting to know.
Anything specific you have in mind here?
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:07 p.m.
On 8/26/07, Hans de Graaff <graaff(a)gentoo.org> wrote:
...
Personally I'm not sure it's worth it to do this. Might be
better to
just start over with a clean slate.
...
I guess I'm volunteering to put some time into this, yes.
Jolly good.
Start with some requirements. Off the top of my head:
How do you want the bug reports to be stored? In file system,
a relational database? Personally I'm biased towards databases,
so long as they truly open source.
You must have an XEmacs lisp client. You must be able to
submit bug reports with this client. And personally, I could care
less about any other kind of client, I wouldn't use it.
Submitting bug reports must be dead simple. No registering, no
logins required, etc.
Bug report submission must strip out coredumps from bug reports.
This used to be a huge problem, I don't know how it is today.
From our side of the fence, we want reports immediately sorted
by formal distribution. We received literally thousands of bug
reports most of them dups from the horrible, horrible Sun CD of
XEmacs 20.0 beta. We continued to receive them years later
when most or all of those bugs were already fixed.
There should be good email support. I'm not sure how I would
describe that.
Add to that as you will.
If there's an open source tool that does the job, use it. And considering
what Linus did with git in a short time, I too wouldn't rule out starting
over from scratch, just so long as you know where you want to go.
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:04 a.m.
On Mon, 2007-08-27 at 15:07 -0700, SL Baur wrote:
Start with some requirements. Off the top of my head:
Thanks for the list!
How do you want the bug reports to be stored? In file system,
a relational database? Personally I'm biased towards databases,
so long as they truly open source.
SQL Database would be my preference.
You must have an XEmacs lisp client. You must be able to
submit bug reports with this client. And personally, I could care
less about any other kind of client, I wouldn't use it.
So we are back to GNATS. :-) I'm translating this to: must have a
well-defined API for custom clients so that an XEmacs lisp client can be
written. ;-)
Given that email interaction seems a must as well, the current report
bugs mechanism should be re-usable. In fact, it should work with the
current version given the large installed base of clients.
If there's an open source tool that does the job, use it. And
considering
what Linus did with git in a short time, I too wouldn't rule out starting
over from scratch, just so long as you know where you want to go.
Writing something new always sounds good until you realize the amount of
work involved. I'm not up for this given that I already have a day job
hacking code and writing a bug tracker doesn't fit our business
plan.:-)
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:09 a.m.
On 8/27/07, Hans de Graaff <graaff(a)gentoo.org> wrote:
On Mon, 2007-08-27 at 15:07 -0700, SL Baur wrote:
> Start with some requirements. Off the top of my head:
Thanks for the list!
> How do you want the bug reports to be stored? In file system,
> a relational database? Personally I'm biased towards databases,
> so long as they truly open source.
SQL Database would be my preference.
> You must have an XEmacs lisp client. You must be able to
> submit bug reports with this client. And personally, I could care
> less about any other kind of client, I wouldn't use it.
So we are back to GNATS. :-) I'm translating this to: must have a
well-defined API for custom clients so that an XEmacs lisp client can be
written. ;-)
No we're not back to GNATS. And to be specific, my day job right now *is*
writing an XEmacs lisp client front end for a bug tracking system
(proprietary, not useful to our purposes anyway, but whoa, does it scale
up).
And to be even more specific, I'd prefer if the lisp client behaved more
like my PostgreSQL bindings than an inferior SQL mode.
Given that email interaction seems a must as well, the current
report
bugs mechanism should be re-usable. In fact, it should work with the
current version given the large installed base of clients.
Report bugs is a good start, but ...
So many times we have been accused of following the Microsofts, etc.
and reimplementing things. Well, that was how we started. The Unix
architecture designed by hall-of-famers Thompson, Ritchie and Kernighan
has withstood the test of time. Big deal. The one major piece of software
that we all need is a bug tracking system that just plain works and works
well. We haven't done it.
I worked with Bugzilla some when I was Turbolinux and didn't like it.
What gives me a unique perspective right now is that my (internal) target
audience are people who despise the current bug tracking system within
the company and it's my job to make the interface better. (The code won't
be useful and that's another story, but there are no GPL violations involved,
it's just that some of my requirements are less than useless outside of the
specific environment).
> If there's an open source tool that does the job, use it.
And considering
> what Linus did with git in a short time, I too wouldn't rule out starting
> over from scratch, just so long as you know where you want to go.
Writing something new always sounds good until you realize the amount of
work involved. I'm not up for this given that I already have a day job
hacking code and writing a bug tracker doesn't fit our business
plan. :-)
Well, Linus did it, but git maybe was his day job. Before you pull another
stupid Steve (who chose CVS way back when it was the lesser of all evils,
and GNATS because he was just plain stupid) please refine the
requirements I've already posted. Absolutely one of the ingredients of git
was the fact that Linus already knew what he wanted before he started.
So go ahead, make requirements and excite me. Writing front end code
for a bug tracking system *is* my day job and while my wife is awaiting
her visa, I have time and I'm looking for something exciting to me to hack
on. And if there is anything we (the open source community) needs is a
great bug tracking system.
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:01 p.m.
SL Baur writes:
So go ahead, make requirements and excite me. Writing front end
code
for a bug tracking system *is* my day job and while my wife is awaiting
her visa, I have time and I'm looking for something exciting to me to hack
on. And if there is anything we (the open source community) needs is a
great bug tracking system.
Look at Roundup for a start. It's not great yet, at least not out of
the box, but it will talk to SQL databases as te backend (at least
MySQL, sqlite3 (a Python thingie), and PostgresQL).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:43 p.m.
Stephen> ... it will talk to SQL databases as te backend (at least
Stephen> MySQL, sqlite3 (a Python thingie), and PostgresQL).
Actually, sqlite3 is not a Python thingie:
http://www.sqlite.org/
Like MySQL, PostgreSQL and a number of other relational databases it does
have a Python wrapper though. The sqlite source is distributed with Python
though. This gives Python a guaranteed SQL presence out-of-the-box.
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:57 a.m.
On Wed, 2007-08-29 at 07:01 +0900, Stephen J. Turnbull wrote:
Look at Roundup for a start. It's not great yet, at least not
out of
the box, but it will talk to SQL databases as te backend (at least
MySQL, sqlite3 (a Python thingie), and PostgresQL).
I didn't get the version in Gentoo (1.3.0, so not the very latest)
working at all apart from the demo, as it kept insisting on writing its
log files in /
"not great out of the box" is also something I worry about. Doing some
customization on look-and-feel and configuration is obviously always
needed. Anything beyond that is the beginning of the maintenance
nightmare that will result in many tears and cursing later on.
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:31 a.m.
Hans de Graaff writes:
"not great out of the box" is also something I worry about.
Doing some
customization on look-and-feel and configuration is obviously always
needed.
It's look-and-feel issues. Roundup seems to be quite robust to
reconfiguration of its backend database.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:28 p.m.
> Look at Roundup for a start. It's not great yet, at least
not out of
> the box, but it will talk to SQL databases as te backend (at least
> MySQL, sqlite3 (a Python thingie), and PostgresQL).
Hans> "not great out of the box" is also something I worry about.
Martin v. Loewis (one of the core Python developers and significant
contributors to Python's new Roundup-based tracker) seems to think that
starting with vanilla Roundup should work just fine (*). (Of
course Stephen may not like how things are presented, but that's all pretty
easily tweakable.)
Skip
(*) http://mail.python.org/pipermail/tracker-discuss/2007-August/001092.html
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:54 a.m.
On Tue, 2007-08-28 at 00:09 -0700, SL Baur wrote:
I worked with Bugzilla some when I was Turbolinux and didn't like
it.
Could you be more specific about what you didn't like? That would be
helpful to get requirements right by knowing what's important to focus
on.
Well, Linus did it, but git maybe was his day job. Before you pull
another
stupid Steve (who chose CVS way back when it was the lesser of all evils,
and GNATS because he was just plain stupid) please refine the
requirements I've already posted. Absolutely one of the ingredients of git
was the fact that Linus already knew what he wanted before he started.
Sure, but there is a huge difference between gathering requirements to
pick an existing product and writing specifications for a new product.
The latter is much more work and not very easy to do with just a mailing
list around. I'm also noticing some strong opinions with respect to this
topic which means that it won't be simply a matter of collecting some
preferences wrt bug tracking, as I'm sure there will be opposing views
which will complicate things and require discussion to work out
properly.
I'm sorry, but I'm simply not up for that job and the level of work it
requires. I agree that there seems to be an opportunity for a better
tool here, and if you want to go for it that would be great, but I'm
afraid I'm not going to help. If that means that we'll make a poor
choice then so be it: I think it is better to have a poor bug tracker
with good bug wrangling rather than a great bug tracker that will take a
lot of time to materialize.
My goal with sending the original email was to get a decent bug tracker
going within a month or so that would help xemacs development along. If
it's going to take longer than that to have something working then I'll
probably drop the whole thing anyway.
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:29 a.m.
Hans de Graaff <graaff(a)gentoo.org> writes:
On Tue, 2007-08-28 at 00:09 -0700, SL Baur wrote:
> I worked with Bugzilla some when I was Turbolinux and didn't like it.
Could you be more specific about what you didn't like? That would be
1+
helpful to get requirements right by knowing what's important to
focus
on.
> Well, Linus did it, but git maybe was his day job. Before you pull another
> stupid Steve (who chose CVS way back when it was the lesser of all evils,
> and GNATS because he was just plain stupid) please refine the
> requirements I've already posted. Absolutely one of the ingredients of git
> was the fact that Linus already knew what he wanted before he started.
Sure, but there is a huge difference between gathering requirements to
pick an existing product and writing specifications for a new product.
The latter is much more work and not very easy to do with just a mailing
list around. I'm also noticing some strong opinions with respect to this
topic which means that it won't be simply a matter of collecting some
preferences wrt bug tracking, as I'm sure there will be opposing views
which will complicate things and require discussion to work out
properly.
I'm sorry, but I'm simply not up for that job and the level of work it
requires. I agree that there seems to be an opportunity for a better
tool here, and if you want to go for it that would be great, but I'm
afraid I'm not going to help. If that means that we'll make a poor
choice then so be it: I think it is better to have a poor bug tracker
with good bug wrangling rather than a great bug tracker that will take a
lot of time to materialize.
My goal with sending the original email was to get a decent bug tracker
going within a month or so that would help xemacs development along. If
it's going to take longer than that to have something working then I'll
probably drop the whole thing anyway.
That's a good realistic goal, Hans.
Can we all agree that we are not going to re-invent the wheel on this?
Let's table the few candidates out there.
So far we have:
roundup
bugzilla
trac
What other products should be considered?
Then let's pick the best fit overall and help Hans to get this set up.
OK?
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
3:01 p.m.
> You must have an XEmacs lisp client. You must be able to submit
bug
> reports with this client. And personally, I could care less about
> any other kind of client, I wouldn't use it.
Hans> So we are back to GNATS. :-) I'm translating this to: must have a
Hans> well-defined API for custom clients so that an XEmacs lisp client
Hans> can be written. ;-)
I don't understand the need for an XEmacs lisp client (*). As far as I
know, I can submit items to Roundup trackers via email. There is also web
submission for all reasonable candidate systems. Last time I looked XEmacs
supported sending email and browsing the web. That should be sufficient,
should it not?
I see no reason that the current XEmacs bug reporter interface can't simply
be modified to provide a little more structure to its submissions and direct
the mail it sends to bugs(a)xemacs.org (or similar).
Hans> Writing something new always sounds good until you realize the
Hans> amount of work involved. I'm not up for this given that I already
Hans> have a day job hacking code and writing a bug tracker doesn't fit
Hans> our business plan.:-)
Amen, brother. It sounds like some people here have tried this before and
failed. I can't believe how long it took the Python folks (all bright
people) to get the current Roundup-based system in place. That's why I
suggested reusing their work (+). Hell, get the ball rolling and start
using the SF tracker if nothing else (or Savannah or one of the other
trackers provided by various open source hosting sites). That would be
better than the status quo. If it proves deficient in some significant way,
then consider migrating to something more tailored to XEmacs's needs
Skip
(*) By "XEmacs lisp client" I assume you mean an API where XEmacs connects
directly to the tracker via some remote procedure call interface (XML-RPC or
SOAP).
(+) I send mail to tracker-discuss(a)python.org yesterday. The thread is
here:
http://mail.python.org/pipermail/tracker-discuss/2007-August/thread.html#...
S
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:46 p.m.
On 8/26/07, Hans de Graaff <graaff(a)gentoo.org> wrote:
Has any work been done on this already?
I did a GNATS about ten years ago. It sucked. We also had a
mailing list devoted to bug reports. It sucked too and was
disk eater as people would mail coredumps no matter how
much we told them not to.
It would be nice to have a bug tracking system that didn't
suck. If at first you don't succeed, give up and let someone
else try it ...
I can offer an evaluation of a system because right now, my
head is buried pretty deep in a bug tracking system.
For anything you're doing though, I'd make sure that you spread
the load out. One or two people handling all the bug reports is
going to suck no matter what.
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6294
days inactive
6298
days old
37 comments
7 participants
participants (7)
-
Adrian Aichner -
Hans de Graaff -
Michael Sperber -
Skip Montanaro -
SL Baur -
Stephen J. Turnbull -
The XEmacs Package Smoketest