* [sup-talk] Choosing a bug tracker for Sup
@ 2009-11-01 21:52 Nicolas Pouillard
2009-11-02 1:17 ` Kevin Riggle
` (3 more replies)
0 siblings, 4 replies; 35+ messages in thread
From: Nicolas Pouillard @ 2009-11-01 21:52 UTC (permalink / raw)
To: sup-talk
Hi,
I would like to discuss more the issue of choosing a bug tracker for sup.
(I've made a new thread for clarity)
(This is a cross post of a post[1] on my blog)
OK lets forget Ditz[2] as an option.
Note also that I would make no objection to using a traditional bug tracker.
It seems that we do not find a tool we really like.
A simple question I asked me was:
"Do we really need to invent this (big) tool?"
And more and more the answer I see is that we do not need
yet another big tool. Especially for a bug tracker we need recipes,
protocols more than a nice interface. And generally I think we
better need thinking on how to split the problem in small issues
than writing the tool that tackles all of them in one go.
Again the UNIX philosophy can help us to simplify all this mess!
So we need a web interface for non technical users, great. What
about a pre-formatted email explained on a single web-page for
reporting bugs. This simple web-page will also have a form
to fill which will send the email for them. This micro web
app is really simple and does a very clear job.
So we now have issues as emails. Thus the mailing-list is our
bug tracker as before. However issues are now in a proper format.
A bot will receive emails on the mailing-list and process those which are in
the right format.
I think that the bot will not have a lot of information to store:
(correct me if you find something else)
* Issue type, severity, priority, category, person assigned,
progress status, incriminated version and platform, planned
milestone/released.
* Issue details, discussion, answers, attachments.
All those of the first category can be easily handled in a very
flexible way either with labels, or a simple mapping:
Labels (like the Google bug tracker on code.google.com):
Type-Defect
Priority-Critical
Component-UI
Mapping:
type: defect
priority: critical
component: UI
This is very flexible because this set of labels/attributes is chosen by the
project maintainer to match the complexity of the project.
I would store and manage the first category using a simple YAML file.
The bot acknowledges its updates by simply answering to the discussion.
Those of the second category can be managed using a single email discussion.
Since the discussion is central to the issue, tracking the original message-ID
could be used as the unique identifier.
About the issues identifier I see two options, either we try to allocate
simple integers like most of the trackers or we just keep the unique (long)
identifier.
Then, optionally a simple set of HTML pages can be generated using the YAML file.
About storage of the YAML file I would simply store it in the repository.
If we make the bot accessible, we just have to periodically pull
from it.
I don't know yet how many issues I've forgotten, and if this design is really
as simple and lightweight as I claim it to be. I look forward to your answers on
that.
Best regards,
[1]: http://blog.nicolaspouillard.fr/entries/2009-11-01-bug-tracker-design-issues.html
[2]: http://ditz.rubyforge.org/
--
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-01 21:52 [sup-talk] Choosing a bug tracker for Sup Nicolas Pouillard
@ 2009-11-02 1:17 ` Kevin Riggle
2009-11-02 8:30 ` Nicolas Pouillard
2009-11-02 7:01 ` Tero Tilus
` (2 subsequent siblings)
3 siblings, 1 reply; 35+ messages in thread
From: Kevin Riggle @ 2009-11-02 1:17 UTC (permalink / raw)
To: sup-talk
Excerpts from Nicolas Pouillard's message of Sun Nov 01 16:52:08 -0500 2009:
(snip)
(snip)
>
> I would store and manage the first category using a simple YAML file.
>
> The bot acknowledges its updates by simply answering to the discussion.
>
> Those of the second category can be managed using a single email discussion.
>
> Since the discussion is central to the issue, tracking the original message-ID
> could be used as the unique identifier.
>
> About the issues identifier I see two options, either we try to allocate
> simple integers like most of the trackers or we just keep the unique (long)
> identifier.
>
> Then, optionally a simple set of HTML pages can be generated using the YAML
> file.
>
> About storage of the YAML file I would simply store it in the repository.
> If we make the bot accessible, we just have to periodically pull
> from it.
>
This portion of your proposed system sounds to me a lot like SD
(http://syncwith.us), against which writing your proposed bot would be fairly
straightforward.
- Kevin
--
Kevin Riggle (kevinr@free-dissociation.com)
MIT Class of 2010, Course VI-2 (EECS)
http://free-dissociation.com
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-01 21:52 [sup-talk] Choosing a bug tracker for Sup Nicolas Pouillard
2009-11-02 1:17 ` Kevin Riggle
@ 2009-11-02 7:01 ` Tero Tilus
2009-11-02 8:46 ` Nicolas Pouillard
2009-11-02 14:53 ` William Morgan
2009-11-02 14:50 ` William Morgan
2009-11-03 23:11 ` Jim Cheetham
3 siblings, 2 replies; 35+ messages in thread
From: Tero Tilus @ 2009-11-02 7:01 UTC (permalink / raw)
To: sup-talk
Requirements collected:
- Store/track
- Formal attributes: Issue type, severity, priority, category,
person assigned, progress status, incriminated version and
platform, planned milestone/released
- Informal meta: Issue details, discussion, answers, attachments
- Web-interface (at least for issue submission, searching and displaying)
- Issue submission, commenting, attachments and editing attributes by email
- Notifications by email
Nicolas Pouillard, 2009-11-01 23:52:
> OK lets forget Ditz[2] as an option.
Why? (not that i have any reason why not, i've never used diz)
> Note also that I would make no objection to using a traditional bug
> tracker.
>
> It seems that we do not find a tool we really like.
Looks like this is a issue you have discussed in depth before. Any
pointers to list archives?
> A simple question I asked me was:
> "Do we really need to invent this (big) tool?"
Well... if somebody invented it for us already. :)
> Especially for a bug tracker we need recipes, protocols more than a
> nice interface.
Now we are talking! ...and when trying to choose a tool, we need to
think about what we need it to do for us.
I tried to pick the requirements you used.
> So we need a web interface for non technical users, great.
OK, this seems reasonable requirement.
> What about a pre-formatted email explained on a single web-page for
> reporting bugs.
...
> A bot will receive emails on the mailing-list and process those
> which are in the right format.
Requirement: Bug submission by email?
I'd say we need that.
> I think that the bot will not have a lot of information to store:
>
> (correct me if you find something else)
>
> * Issue type, severity, priority, category, person assigned,
> progress status, incriminated version and platform, planned
> milestone/released.
>
> * Issue details, discussion, answers, attachments.
This is pretty traditional. I'd still want to challenge a bit. Why
do we need severity and priority? What would they be used for?
> I would store and manage the first category using a simple YAML
> file. The bot acknowledges its updates by simply answering to the
> discussion.
Requirement: Email notifications to ticket "subscribers"?
That's reasonable.
> Those of the second category can be managed using a single email
> discussion.
Requirement: Issue comments/attachments and status changes by email?
> I don't know yet how many issues I've forgotten
I can't figure out anything really necessary you would have missed.
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 1:17 ` Kevin Riggle
@ 2009-11-02 8:30 ` Nicolas Pouillard
0 siblings, 0 replies; 35+ messages in thread
From: Nicolas Pouillard @ 2009-11-02 8:30 UTC (permalink / raw)
To: Kevin Riggle; +Cc: sup-talk
Excerpts from Kevin Riggle's message of Mon Nov 02 02:17:31 +0100 2009:
> Excerpts from Nicolas Pouillard's message of Sun Nov 01 16:52:08 -0500 2009:
> (snip)
> (snip)
> >
> > I would store and manage the first category using a simple YAML file.
> >
> > The bot acknowledges its updates by simply answering to the discussion.
> >
> > Those of the second category can be managed using a single email discussion.
> >
> > Since the discussion is central to the issue, tracking the original message-ID
> > could be used as the unique identifier.
> >
> > About the issues identifier I see two options, either we try to allocate
> > simple integers like most of the trackers or we just keep the unique (long)
> > identifier.
> >
> > Then, optionally a simple set of HTML pages can be generated using the YAML
> > file.
> >
> > About storage of the YAML file I would simply store it in the repository.
> > If we make the bot accessible, we just have to periodically pull
> > from it.
> >
> This portion of your proposed system sounds to me a lot like SD
> (http://syncwith.us), against which writing your proposed bot would be fairly
> straightforward.
SD looks indeed really fun, however I think it fails my simplicity goal.
Indeed the tool expose tons of commands and try to abstract how it is made,
I'm in favor of better knowing the underlying store (a YAML file), and simply
storing it with usual DVCS tools.
--
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 7:01 ` Tero Tilus
@ 2009-11-02 8:46 ` Nicolas Pouillard
2009-11-02 9:50 ` Tero Tilus
2009-11-02 14:53 ` William Morgan
1 sibling, 1 reply; 35+ messages in thread
From: Nicolas Pouillard @ 2009-11-02 8:46 UTC (permalink / raw)
To: Tero Tilus; +Cc: sup-talk
Excerpts from Tero Tilus's message of Mon Nov 02 08:01:31 +0100 2009:
> Requirements collected:
> - Store/track
> - Formal attributes: Issue type, severity, priority, category,
> person assigned, progress status, incriminated version and
> platform, planned milestone/released
> - Informal meta: Issue details, discussion, answers, attachments
> - Web-interface (at least for issue submission, searching and displaying)
> - Issue submission, commenting, attachments and editing attributes by email
> - Notifications by email
Nice summary.
> Nicolas Pouillard, 2009-11-01 23:52:
> > OK lets forget Ditz[2] as an option.
>
> Why? (not that i have any reason why not, i've never used diz)
At least temporarily, I think it also fails at staying simple. And while
it is fun to hack that's fine but then it becomes burden and code to maintain.
> > Note also that I would make no objection to using a traditional bug
> > tracker.
> >
> > It seems that we do not find a tool we really like.
>
> Looks like this is a issue you have discussed in depth before. Any
> pointers to list archives?
Not really publicly, and I'm open to seeing tools I don't know.
> > A simple question I asked me was:
> > "Do we really need to invent this (big) tool?"
>
> Well... if somebody invented it for us already. :)
Yes but a big tool imply development, extensions, upgrades...
> > Especially for a bug tracker we need recipes, protocols more than a
> > nice interface.
>
> Now we are talking! ...and when trying to choose a tool, we need to
> think about what we need it to do for us.
I would say that we need a collection of small and clear tools.
> I tried to pick the requirements you used.
>
> > So we need a web interface for non technical users, great.
>
> OK, this seems reasonable requirement.
>
> > What about a pre-formatted email explained on a single web-page for
> > reporting bugs.
> ...
> > A bot will receive emails on the mailing-list and process those
> > which are in the right format.
>
> Requirement: Bug submission by email?
> I'd say we need that.
Yes some people tend to really dislike web UIs, and while it is not
my case I prefer to keep a "by email" option anyway.
> > I think that the bot will not have a lot of information to store:
> >
> > (correct me if you find something else)
> >
> > * Issue type, severity, priority, category, person assigned,
> > progress status, incriminated version and platform, planned
> > milestone/released.
> >
> > * Issue details, discussion, answers, attachments.
>
> This is pretty traditional. I'd still want to challenge a bit. Why
> do we need severity and priority? What would they be used for?
I don't say that we need all of those, that the flexibility point.
The configuration will be something like:
attributes:
type: [defect, enhancement, task]
severity: [critical, ...]
priority: [high, low, ...]
category: [UI, index, ...]
assigned to: [someone, someoneelse, ...]
progress status: [waiting, open, started, closed]
...
This can be tweaked as needed, if we need one more 'type' we add it,
if we do not need severity we remove it.
> > I would store and manage the first category using a simple YAML
> > file. The bot acknowledges its updates by simply answering to the
> > discussion.
>
> Requirement: Email notifications to ticket "subscribers"?
> That's reasonable.
I would say that the mailing-list is the only subscriber, people
choose to follow the discussion or not with their email-client.
This only miss the "vote for this issue" feature, which we can avoid
in the mean time and delegate to a polling tool afterward.
> > Those of the second category can be managed using a single email
> > discussion.
>
> Requirement: Issue comments/attachments and status changes by email?
Right.
> > I don't know yet how many issues I've forgotten
>
> I can't figure out anything really necessary you would have missed.
I got some more input via other channels about the need of an UI to
search, triage, sort issues. I would say that all of this can easily be
done by playing with the YAML file. The only tool I see would be one
to fetch the email discussion given a Message-ID, but this is a matter
of another separated tool.
Thanks for your input!
--
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 8:46 ` Nicolas Pouillard
@ 2009-11-02 9:50 ` Tero Tilus
2009-11-02 14:58 ` William Morgan
0 siblings, 1 reply; 35+ messages in thread
From: Tero Tilus @ 2009-11-02 9:50 UTC (permalink / raw)
To: sup-talk
Nicolas Pouillard, 2009-11-02 10:46:
> Excerpts from Tero Tilus's message of Mon Nov 02 08:01:31 +0100 2009:
>>> "Do we really need to invent this (big) tool?"
>>
>> Well... if somebody invented it for us already. :)
>
> Yes but a big tool imply development, extensions, upgrades...
Unless you take service, not the bare tool. We are already using
gitorius and rubyforge (at least to some extent). I'd go for a issue
tracking service that suits our needs.
>> Requirement: Email notifications to ticket "subscribers"?
>> That's reasonable.
>
> I would say that the mailing-list is the only subscriber, people
> choose to follow the discussion or not with their email-client.
Thats exactly why there were quotes around the word subscribers. ;)
What I was thinking was that you could be a first class citized no
matter the client. You could choose to comment and follow the
discussion on issues using your mua or web interface. Kinda like what
Alue[1] does for discussions in general.
[1] http://antti-juhani.kaijanaho.fi/newblog/archives/572
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-01 21:52 [sup-talk] Choosing a bug tracker for Sup Nicolas Pouillard
2009-11-02 1:17 ` Kevin Riggle
2009-11-02 7:01 ` Tero Tilus
@ 2009-11-02 14:50 ` William Morgan
2009-11-02 17:47 ` Nicolas Pouillard
` (2 more replies)
2009-11-03 23:11 ` Jim Cheetham
3 siblings, 3 replies; 35+ messages in thread
From: William Morgan @ 2009-11-02 14:50 UTC (permalink / raw)
To: sup-talk
Nice writeup. Just brainstorming, here are the features I personally
find vital for an issue tracker that would make me happy:
1. Web submission. The burden of creating a record should be on the
submitter---it's not too much to ask, and it saves developer time. This
also encourages reporters to provide relevant information like version,
platform, Ruby version, etc. upfront, since they can be prompted for
those data explicitly.
2. Developer discussion via email. This is vital. There's no way I would
want to have a technical discussion using text boxes on a website. And
this discussion should be attached to the issue, of course.
3. Canonicality. I want one name for a bug, and I want one URL that I
can point people to when referring to it. That URL should have the
entire history, including developer discussion, of the issue.
4. Browseability. There should be some public way of getting a view of
all the open issues, at a minimum. (Web seems natural.) Other stuff like
sorting by priority, attachign to releases, etc. are icing on the cake,
but if people are going to be chipping in on development effort, or
searching to see if other people have had this bug, they have to be able
to browse what's out there.
> About the issues identifier I see two options, either we try to
> allocate simple integers like most of the trackers or we just keep the
> unique (long) identifier.
I want a simple one. I can remember JIRA-style "ABC-123" names and
that's really handy sometimes.
Just my two cents.
--
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 7:01 ` Tero Tilus
2009-11-02 8:46 ` Nicolas Pouillard
@ 2009-11-02 14:53 ` William Morgan
2009-11-02 17:38 ` Nicolas Pouillard
1 sibling, 1 reply; 35+ messages in thread
From: William Morgan @ 2009-11-02 14:53 UTC (permalink / raw)
To: sup-talk
Reformatted excerpts from Tero Tilus's message of 2009-11-01:
> Requirement: Bug submission by email?
> I'd say we need that.
That's what we have now, basically, and what we had when we were using
ditz, and I didn't like having to do the extra work of making an issue.
> This is pretty traditional. I'd still want to challenge a bit. Why
> do we need severity and priority? What would they be used for?
At least one type of ordering would be nice. There are a large class of
feature requests where my basic feeling is "sure, that would be nice,
but I've got a million other things more important to do", which I would
like to keep around as food for later thought, if nothing else, but
would like to basically ignore in the near term.
--
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 9:50 ` Tero Tilus
@ 2009-11-02 14:58 ` William Morgan
0 siblings, 0 replies; 35+ messages in thread
From: William Morgan @ 2009-11-02 14:58 UTC (permalink / raw)
To: sup-talk
Reformatted excerpts from Tero Tilus's message of 2009-11-02:
> Unless you take service, not the bare tool. We are already using
> gitorius and rubyforge (at least to some extent). I'd go for a issue
> tracking service that suits our needs.
I'm not dead-set against a hosted solution, but I am wary of making too
much of the development cycle reliant on third parties. E.g. I see
people who can't get any work done when Github is down. Well, that's not
Github's fault, per se, but they've integrated it into their process to
such an extent that they're now reliant on it.
Not to say that that would happen with just an issue tracker. But still,
our use of Gitorious and Rubyforge is pretty minimal right now, and I
feel good about that.
(And honestly I find Gitorious merge requests a little irritating,
because they're invariably not rebased properly against master and I
have to have the same discussion every time.)
--
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 14:53 ` William Morgan
@ 2009-11-02 17:38 ` Nicolas Pouillard
0 siblings, 0 replies; 35+ messages in thread
From: Nicolas Pouillard @ 2009-11-02 17:38 UTC (permalink / raw)
To: William Morgan; +Cc: sup-talk
Excerpts from William Morgan's message of Mon Nov 02 15:53:08 +0100 2009:
> Reformatted excerpts from Tero Tilus's message of 2009-11-01:
> > Requirement: Bug submission by email?
> > I'd say we need that.
>
> That's what we have now, basically, and what we had when we were using
> ditz, and I didn't like having to do the extra work of making an issue.
Right, but in this setup only well formatted bug reports are accepted, so
no extra burden on devs.
--
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 14:50 ` William Morgan
@ 2009-11-02 17:47 ` Nicolas Pouillard
2009-11-02 19:20 ` William Morgan
2009-11-02 20:40 ` Joe Wölfel
2009-11-03 14:50 ` Mike Kelly
2 siblings, 1 reply; 35+ messages in thread
From: Nicolas Pouillard @ 2009-11-02 17:47 UTC (permalink / raw)
To: William Morgan; +Cc: sup-talk
Excerpts from William Morgan's message of Mon Nov 02 15:50:08 +0100 2009:
> Nice writeup. Just brainstorming, here are the features I personally
> find vital for an issue tracker that would make me happy:
>
> 1. Web submission. The burden of creating a record should be on the
> submitter---it's not too much to ask, and it saves developer time. This
> also encourages reporters to provide relevant information like version,
> platform, Ruby version, etc. upfront, since they can be prompted for
> those data explicitly.
> 2. Developer discussion via email. This is vital. There's no way I would
> want to have a technical discussion using text boxes on a website. And
> this discussion should be attached to the issue, of course.
1,2: Same for me.
> 3. Canonicality. I want one name for a bug, and I want one URL that I
> can point people to when referring to it. That URL should have the
> entire history, including developer discussion, of the issue.
> 4. Browseability. There should be some public way of getting a view of
> all the open issues, at a minimum. (Web seems natural.) Other stuff like
> sorting by priority, attachign to releases, etc. are icing on the cake,
> but if people are going to be chipping in on development effort, or
> searching to see if other people have had this bug, they have to be able
> to browse what's out there.
3,4:
Right, I think this is part of the web-page generation tool. Which
given the YAML file will produce web-pages. The only unclear point to
me is: "how to find the archive URL for a discussion given the message-ID?"
> > About the issues identifier I see two options, either we try to
> > allocate simple integers like most of the trackers or we just keep the
> > unique (long) identifier.
>
> I want a simple one. I can remember JIRA-style "ABC-123" names and
> that's really handy sometimes.
Right, we want short issue numbers. I'm would still be a bit sad of completely
loosing the distributed property. Maybe a solution would be to allow issues
to have an optional short name. In practice it will be just temporarily,
the time the issue makes its way to the central repository, or being just a
local issue.
--
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 17:47 ` Nicolas Pouillard
@ 2009-11-02 19:20 ` William Morgan
2009-11-02 20:23 ` Nicolas Pouillard
0 siblings, 1 reply; 35+ messages in thread
From: William Morgan @ 2009-11-02 19:20 UTC (permalink / raw)
To: sup-talk
Reformatted excerpts from Nicolas Pouillard's message of 2009-11-02:
> Right, we want short issue numbers. I'm would still be a bit sad of
> completely loosing the distributed property. Maybe a solution would be
> to allow issues to have an optional short name. In practice it will be
> just temporarily, the time the issue makes its way to the central
> repository, or being just a local issue.
I just think it would be really useful to say stuff like "this is a
duplicate of #154" or "fixing this depends on index-48" or whatever, and
have everyone be able to find that easily, e.g. by going to
http://sup.com/bugs/index-48. Having to refer to the hashes in Ditz was
irritating.
--
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 19:20 ` William Morgan
@ 2009-11-02 20:23 ` Nicolas Pouillard
0 siblings, 0 replies; 35+ messages in thread
From: Nicolas Pouillard @ 2009-11-02 20:23 UTC (permalink / raw)
To: William Morgan; +Cc: sup-talk
Excerpts from William Morgan's message of Mon Nov 02 20:20:32 +0100 2009:
> Reformatted excerpts from Nicolas Pouillard's message of 2009-11-02:
> > Right, we want short issue numbers. I'm would still be a bit sad of
> > completely loosing the distributed property. Maybe a solution would be
> > to allow issues to have an optional short name. In practice it will be
> > just temporarily, the time the issue makes its way to the central
> > repository, or being just a local issue.
>
> I just think it would be really useful to say stuff like "this is a
> duplicate of #154" or "fixing this depends on index-48" or whatever, and
> have everyone be able to find that easily, e.g. by going to
> http://sup.com/bugs/index-48. Having to refer to the hashes in Ditz was
> irritating.
I agree, that's way I proposed it.
--
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 14:50 ` William Morgan
2009-11-02 17:47 ` Nicolas Pouillard
@ 2009-11-02 20:40 ` Joe Wölfel
2009-11-02 21:49 ` Nicolas Pouillard
2009-11-03 14:50 ` Mike Kelly
2 siblings, 1 reply; 35+ messages in thread
From: Joe Wölfel @ 2009-11-02 20:40 UTC (permalink / raw)
To: sup-talk
Excerpts from William Morgan's message of Mon Nov 02 09:50:08 -0500 2009:
> 1. Web submission. The burden of creating a record should be on the
> submitter---it's not too much to ask, and it saves developer time. This
> also encourages reporters to provide relevant information like version,
> platform, Ruby version, etc. upfront, since they can be prompted for
> those data explicitly.
>
> 2. Developer discussion via email. This is vital. There's no way I would
> want to have a technical discussion using text boxes on a website. And
> this discussion should be attached to the issue, of course.
Please ignore this suggestion if you feel it is stupid, but couldn't an
internal sup-based bug submission perform prompting and validation tasks just
as easily as a web form? Also, wouldn't it be better for automatically
including or verifying operating system info, version info, libraries, etc?
It seems like this might make for a more natural transition to email-based
developer discussion, reduce the need for centralized infrastructure, make it
easier for users to figure out how and where to submit a bug, and possibly make
critical system and library information more accurate and detailed.
Cheers,
Joe
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 20:40 ` Joe Wölfel
@ 2009-11-02 21:49 ` Nicolas Pouillard
0 siblings, 0 replies; 35+ messages in thread
From: Nicolas Pouillard @ 2009-11-02 21:49 UTC (permalink / raw)
To: Joe Wölfel; +Cc: sup-talk
Excerpts from Joe Wölfel's message of Mon Nov 02 21:40:21 +0100 2009:
> Excerpts from William Morgan's message of Mon Nov 02 09:50:08 -0500 2009:
> > 1. Web submission. The burden of creating a record should be on the
> > submitter---it's not too much to ask, and it saves developer time. This
> > also encourages reporters to provide relevant information like version,
> > platform, Ruby version, etc. upfront, since they can be prompted for
> > those data explicitly.
> >
> > 2. Developer discussion via email. This is vital. There's no way I would
> > want to have a technical discussion using text boxes on a website. And
> > this discussion should be attached to the issue, of course.
>
> Please ignore this suggestion if you feel it is stupid, but couldn't an
> internal sup-based bug submission perform prompting and validation tasks just
> as easily as a web form? Also, wouldn't it be better for automatically
> including or verifying operating system info, version info, libraries, etc?
>
> It seems like this might make for a more natural transition to email-based
> developer discussion, reduce the need for centralized infrastructure, make it
> easier for users to figure out how and where to submit a bug, and possibly make
> critical system and library information more accurate and detailed.
This is indeed a nice option. Add to sup a way to send a bug report. It could
simply be an email in the chosen format for bug reporting. And indeed the
bonus is more precise information.
However in the long run this only complementary with other way to report bugs.
--
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-02 14:50 ` William Morgan
2009-11-02 17:47 ` Nicolas Pouillard
2009-11-02 20:40 ` Joe Wölfel
@ 2009-11-03 14:50 ` Mike Kelly
2009-11-03 15:16 ` William Morgan
2 siblings, 1 reply; 35+ messages in thread
From: Mike Kelly @ 2009-11-03 14:50 UTC (permalink / raw)
To: sup-talk
On Mon, 02 Nov 2009 06:50:08 -0800, William Morgan
<wmorgan-sup@masanjin.net> wrote:
> Nice writeup. Just brainstorming, here are the features I personally
> find vital for an issue tracker that would make me happy:
>
> 1. Web submission.
>
> 2. Developer discussion via email.
>
> 3. Canonicality.
>
> 4. Browseability.
>
> I want a simple one. I can remember JIRA-style "ABC-123" names and
> that's really handy sometimes.
As much as I hate to suggest it... RT[1] should have all of these
qualities. It's used by CPAN, among other things. And, a sample ticket of
mine[2].
[1] http://bestpractical.com/rt
[2] https://rt.cpan.org/Public/Bug/Display.html?id=45040
--
Mike Kelly
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 14:50 ` Mike Kelly
@ 2009-11-03 15:16 ` William Morgan
2009-11-03 15:34 ` Mike Kelly
2009-11-03 16:20 ` Sebastian Schwarz
0 siblings, 2 replies; 35+ messages in thread
From: William Morgan @ 2009-11-03 15:16 UTC (permalink / raw)
To: sup-talk
Reformatted excerpts from Mike Kelly's message of 2009-11-03:
> As much as I hate to suggest it... RT should have all of these
> qualities.
Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it?
(I've heard people complain about it before, but I don't remember any of
the details.)
--
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 15:16 ` William Morgan
@ 2009-11-03 15:34 ` Mike Kelly
2009-11-03 16:49 ` Reid Thompson
2009-11-03 16:20 ` Sebastian Schwarz
1 sibling, 1 reply; 35+ messages in thread
From: Mike Kelly @ 2009-11-03 15:34 UTC (permalink / raw)
To: sup-talk
On Tue, 03 Nov 2009 07:16:15 -0800, William Morgan
<wmorgan-sup@masanjin.net> wrote:
> Reformatted excerpts from Mike Kelly's message of 2009-11-03:
>> As much as I hate to suggest it... RT should have all of these
>> qualities.
>
> Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it?
> (I've heard people complain about it before, but I don't remember any of
> the details.)
Yes, somewhat, IIRC. But, I haven't really ever had to set it up. It's one
of those things which requires half of CPAN to work. So, it was annoying
when I made an attempt to package it for a distro, but if you're just
installing it following their directions, it's probably not that bad.
But, someone is able to get away with charging $3250 a month for a
"platinum" managed install of it. (Then again, some enterprises will pay
anything for hosting...)
Let me try a test install real quick, and I'll get back to you.
--
Mike Kelly
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 15:16 ` William Morgan
2009-11-03 15:34 ` Mike Kelly
@ 2009-11-03 16:20 ` Sebastian Schwarz
2009-11-03 17:03 ` Daemian Mack
` (2 more replies)
1 sibling, 3 replies; 35+ messages in thread
From: Sebastian Schwarz @ 2009-11-03 16:20 UTC (permalink / raw)
To: sup-talk
On 2009-11-03 at 07:16 -0800, William Morgan wrote:
> Is it a pain to set up?
I have never installed, administered or used RT before, but curiously
digging around its homepage I found this:
http://bestpractical.com/rt/features.html praises it as "Easy to
install". However on http://wiki.bestpractical.com/view/HomePage
it says:
> RT doesn't come with a formal, formatted users or administrators
> guide, but it's likely most of what you need to know to use and run it
> is contained somewhere within this wiki, so look around a little, be
> patient... and try not to install RT on a Sunday night when you need
> to run it in production on Monday: it's big, and learning how to set
> it up can take some time.
Can anyone with more experience with RT comment on this?
Moreover I'd like to advertise/suggest [Roundup][1]. Apart form a slim
web interface -- [here][2] Python's issue tracker as an example -- it
also offers a fully functional [email interface][3], which allows --
from what I understand -- creating, discussing and setting properties
like status and labels of issues.
As a note on the ease of installation: Roundup's [documentation on
installation][4] begins with: "Set aside 15-30 minutes." But again
I have no personal experience to back this claim up. Can anyone
comment on this or Roundup in general?
[1]: http://roundup.sourceforge.net/
[2]: http://bugs.python.org/
[3]: http://roundup.sourceforge.net/docs/user_guide.html#e-mail-gateway
[4]: http://www.roundup-tracker.org/docs/installation.html#installation
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 15:34 ` Mike Kelly
@ 2009-11-03 16:49 ` Reid Thompson
2009-11-03 17:03 ` Reid Thompson
2009-11-03 18:04 ` William Morgan
0 siblings, 2 replies; 35+ messages in thread
From: Reid Thompson @ 2009-11-03 16:49 UTC (permalink / raw)
To: Mike Kelly; +Cc: sup-talk
On Tue, Nov 03, 2009 at 10:34:24AM -0500, Mike Kelly wrote:
>
> On Tue, 03 Nov 2009 07:16:15 -0800, William Morgan
> <wmorgan-sup@masanjin.net> wrote:
> > Reformatted excerpts from Mike Kelly's message of 2009-11-03:
> >> As much as I hate to suggest it... RT should have all of these
> >> qualities.
> >
> > Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it?
> > (I've heard people complain about it before, but I don't remember any of
> > the details.)
>
> Yes, somewhat, IIRC. But, I haven't really ever had to set it up. It's one
> of those things which requires half of CPAN to work. So, it was annoying
> when I made an attempt to package it for a distro, but if you're just
> installing it following their directions, it's probably not that bad.
>
> But, someone is able to get away with charging $3250 a month for a
> "platinum" managed install of it. (Then again, some enterprises will pay
> anything for hosting...)
>
> Let me try a test install real quick, and I'll get back to you.
I just started looking at it, so not sure if it fits all needs but
fossil has a built in bugtracker
http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 16:20 ` Sebastian Schwarz
@ 2009-11-03 17:03 ` Daemian Mack
2009-11-03 18:06 ` Mike Kelly
2009-11-03 17:25 ` William Morgan
2009-11-03 18:33 ` Tero Tilus
2 siblings, 1 reply; 35+ messages in thread
From: Daemian Mack @ 2009-11-03 17:03 UTC (permalink / raw)
To: sup-talk
Excerpts from Sebastian Schwarz's message of Tue Nov 03 11:20:47 -0500 2009:
> > RT doesn't come with a formal, formatted users or administrators
> > guide, but it's likely most of what you need to know to use and run it
> > is contained somewhere within this wiki, so look around a little, be
> > patient... and try not to install RT on a Sunday night when you need
> > to run it in production on Monday: it's big, and learning how to set
> > it up can take some time.
>
> Can anyone with more experience with RT comment on this?
Having evaluated RT3 for fairly-intense production use at a prior
job, I can't really say I'd recommend it for our use here. As an
'enterprise-ready' solution, it's a bit ungainly out of the box, and
the bulk of its feature-set would probably be overkill for sup's
needs. It makes heavy use of the 'departmental queue' model whereby
many departments, consisting each of many employees, have some
permission set for many queues. Customization was a bit opaque (though
perhaps less so if you're very familiar with Perl), and though there's
an O'Reilly book for RT, I found it often fell short of my needs.
I'd suspect, with the glut of ticket-tracker software available,
there's something a good deal better-suited for sup out there. I'll
chime in again if I manage to find something that seems helpful.
--
http://daemianmack.com/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 16:49 ` Reid Thompson
@ 2009-11-03 17:03 ` Reid Thompson
2009-11-03 18:04 ` William Morgan
1 sibling, 0 replies; 35+ messages in thread
From: Reid Thompson @ 2009-11-03 17:03 UTC (permalink / raw)
To: Reid Thompson; +Cc: sup-talk
On Tue, Nov 03, 2009 at 11:49:53AM -0500, Reid Thompson wrote:
> On Tue, Nov 03, 2009 at 10:34:24AM -0500, Mike Kelly wrote:
> >
> > On Tue, 03 Nov 2009 07:16:15 -0800, William Morgan
> > <wmorgan-sup@masanjin.net> wrote:
> > > Reformatted excerpts from Mike Kelly's message of 2009-11-03:
> > >> As much as I hate to suggest it... RT should have all of these
> > >> qualities.
> > >
> > > Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it?
> > > (I've heard people complain about it before, but I don't remember any of
> > > the details.)
> >
> > Yes, somewhat, IIRC. But, I haven't really ever had to set it up. It's one
> > of those things which requires half of CPAN to work. So, it was annoying
> > when I made an attempt to package it for a distro, but if you're just
> > installing it following their directions, it's probably not that bad.
> >
> > But, someone is able to get away with charging $3250 a month for a
> > "platinum" managed install of it. (Then again, some enterprises will pay
> > anything for hosting...)
> >
> > Let me try a test install real quick, and I'll get back to you.
>
> I just started looking at it, so not sure if it fits all needs but
> fossil has a built in bugtracker
>
> http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
>
forgot to mention, it's developed by the same person as sqlite
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 16:20 ` Sebastian Schwarz
2009-11-03 17:03 ` Daemian Mack
@ 2009-11-03 17:25 ` William Morgan
2009-11-03 17:37 ` Dan Falcone
2009-11-03 18:33 ` Tero Tilus
2 siblings, 1 reply; 35+ messages in thread
From: William Morgan @ 2009-11-03 17:25 UTC (permalink / raw)
To: sup-talk
Reformatted excerpts from Sebastian Schwarz's message of 2009-11-03:
> Moreover I'd like to advertise/suggest [Roundup][1]. Apart form a slim
> web interface -- [here][2] Python's issue tracker as an example -- it
> also offers a fully functional [email interface][3], which allows --
> from what I understand -- creating, discussing and setting properties
> like status and labels of issues.
Nicolas suggested this too. I tried installing it locally (late on a
Sunday night, with a screaming infant in my ear) and couldn't get it to
behave. But, bugs.python.org looks great, and it looks like they're using
email to discuss and change issue state, which is awesome. I'll give it
another shot.
--
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 17:25 ` William Morgan
@ 2009-11-03 17:37 ` Dan Falcone
0 siblings, 0 replies; 35+ messages in thread
From: Dan Falcone @ 2009-11-03 17:37 UTC (permalink / raw)
To: William Morgan; +Cc: sup-talk
[-- Attachment #1.1: Type: text/plain, Size: 2060 bytes --]
Hi all,
Thought I'd chime in regarding RT. I've never configured it, but we use it
internally where I work, so I can comment on it from a user perspective. I
mainly use the email interface, which is very finicky. If you include
attachments that are too large, RT will ignore your message and will not
attach it to an existing ticket or open a new ticket. Our instance is well
known to modify attachments (changing the md5sums), which causes all kinds
of problems for us. Maybe this part is user error, but it also sends 2
copies of every message and doesn't always CC everyone on the ticket when it
is supposed to. So you either get 2 copies of each email, or zero. Either
way it sucks. We have lots of processes in place to work around the issues
RT creates for us. Basically the only reason we use it is for archival
purposes.
Again, I did not install and do not administer this instance, so there could
be configuration issues or possibly newer versions that address these
shortcomings. However, given my past experience, I wouldn't recommend it.
-Dan
On Tue, Nov 3, 2009 at 1:25 PM, William Morgan <wmorgan-sup@masanjin.net>wrote:
> Reformatted excerpts from Sebastian Schwarz's message of 2009-11-03:
> > Moreover I'd like to advertise/suggest [Roundup][1]. Apart form a slim
> > web interface -- [here][2] Python's issue tracker as an example -- it
> > also offers a fully functional [email interface][3], which allows --
> > from what I understand -- creating, discussing and setting properties
> > like status and labels of issues.
>
> Nicolas suggested this too. I tried installing it locally (late on a
> Sunday night, with a screaming infant in my ear) and couldn't get it to
> behave. But, bugs.python.org looks great, and it looks like they're using
> email to discuss and change issue state, which is awesome. I'll give it
> another shot.
> --
> William <wmorgan-sup@masanjin.net>
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
[-- Attachment #1.2: Type: text/html, Size: 2774 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 16:49 ` Reid Thompson
2009-11-03 17:03 ` Reid Thompson
@ 2009-11-03 18:04 ` William Morgan
2009-11-03 19:30 ` Reid Thompson
1 sibling, 1 reply; 35+ messages in thread
From: William Morgan @ 2009-11-03 18:04 UTC (permalink / raw)
To: sup-talk
Reformatted excerpts from Reid Thompson's message of 2009-11-03:
> I just started looking at it, so not sure if it fits all needs but
> fossil has a built in bugtracker
>
> http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
Is it possible to use the bug tracker without keeping all the code in
Fossil itself? My impression is no. I'm very happy with git and
changing development to a brand new SCM is extremely unlikely to happen
at this point.
--
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 17:03 ` Daemian Mack
@ 2009-11-03 18:06 ` Mike Kelly
0 siblings, 0 replies; 35+ messages in thread
From: Mike Kelly @ 2009-11-03 18:06 UTC (permalink / raw)
To: sup-talk
On Tue, 03 Nov 2009 12:03:38 -0500, Daemian Mack <daemianmack@gmail.com>
wrote:
> Having evaluated RT3 for fairly-intense production use at a prior
> job, I can't really say I'd recommend it for our use here.
>
> I'd suspect, with the glut of ticket-tracker software available,
> there's something a good deal better-suited for sup out there. I'll
> chime in again if I manage to find something that seems helpful.
Yes, feel free to ignore me. It's a pain in the butt to get going. :p
On the hopefully-less-sucky front, there's Bugzilla. There is apparently a
plugin for it that lets you reply to tickets by email, but I haven't set it
up myself.
But, I'm a perl guy, so I'm likely highly biased... :)
--
Mike Kelly
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 16:20 ` Sebastian Schwarz
2009-11-03 17:03 ` Daemian Mack
2009-11-03 17:25 ` William Morgan
@ 2009-11-03 18:33 ` Tero Tilus
2 siblings, 0 replies; 35+ messages in thread
From: Tero Tilus @ 2009-11-03 18:33 UTC (permalink / raw)
To: sup-talk
Sebastian Schwarz, 2009-11-03 18:20:
> Moreover I'd like to advertise/suggest [Roundup][1].
Now that you mention it, I've used it in couple of projects and liked
very much.
> As a note on the ease of installation: Roundup's [documentation on
> installation][4] begins with: "Set aside 15-30 minutes." But again
> I have no personal experience to back this claim up. Can anyone
> comment on this or Roundup in general?
I've set it up once long time ago and I don't remember anything about
it really. Installation was fluent I guess. ;)
Another one I like is Redmine, but its whole a lot different kind of
tool, nice and fluent tho. It also might do pretty much what we want,
but I'd guess Roundup does it with less tuning and pluginnig.
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 18:04 ` William Morgan
@ 2009-11-03 19:30 ` Reid Thompson
0 siblings, 0 replies; 35+ messages in thread
From: Reid Thompson @ 2009-11-03 19:30 UTC (permalink / raw)
To: William Morgan; +Cc: sup-talk
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
On Tue, 2009-11-03 at 10:04 -0800, William Morgan wrote:
> Is it possible to use the bug tracker without keeping all the code in
> Fossil itself?
I just created an empty repository. Contains no source code files.
$ fossil new bugtracker-only
$ fossil open bugtracker-only
$ ls -rlt /tmp/bugtracker-only
-rw-r--r-- 1 rthompso staff 50176 2009-11-03 14:23 /tmp/bugtracker-only
$ fossil ui
did minimal admin/config -> http://localhost:8080/setup_config
then added tickets etc, looks like the data entry is free-form, so not
tied to a source version existing etc.
attached png.
[-- Attachment #2: TestBugTrackerOnly.png --]
[-- Type: image/png, Size: 127986 bytes --]
[-- Attachment #3: Type: text/plain, Size: 140 bytes --]
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-01 21:52 [sup-talk] Choosing a bug tracker for Sup Nicolas Pouillard
` (2 preceding siblings ...)
2009-11-02 14:50 ` William Morgan
@ 2009-11-03 23:11 ` Jim Cheetham
2009-11-04 0:07 ` Mike Kelly
3 siblings, 1 reply; 35+ messages in thread
From: Jim Cheetham @ 2009-11-03 23:11 UTC (permalink / raw)
To: sup-talk
On Mon, Nov 2, 2009 at 10:52 AM, Nicolas Pouillard
<nicolas.pouillard@gmail.com> wrote:
> I would like to discuss more the issue of choosing a bug tracker for sup.
Having had a quick read of this thread, I think that trac
(http://trac.edgewall.com) would meet your goals.
It's a simple single-project combination of wiki, ticketing engine and
repository browser. Tickets can be received by email, ticket updates
can be emailed to a set of interested subscribers, and checkins to the
repository can close tickets (via simple hooks). The wiki markup
provides simple access to changes, tickets & files.
-jim
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-03 23:11 ` Jim Cheetham
@ 2009-11-04 0:07 ` Mike Kelly
2009-11-04 9:38 ` Michael Stapelberg
0 siblings, 1 reply; 35+ messages in thread
From: Mike Kelly @ 2009-11-04 0:07 UTC (permalink / raw)
To: sup-talk
On Wed, 4 Nov 2009 12:11:31 +1300
Jim Cheetham <jim@gonzul.net> wrote:
> On Mon, Nov 2, 2009 at 10:52 AM, Nicolas Pouillard
> <nicolas.pouillard@gmail.com> wrote:
> > I would like to discuss more the issue of choosing a bug tracker
> > for sup.
>
> Having had a quick read of this thread, I think that trac
> (http://trac.edgewall.com) would meet your goals.
>
> It's a simple single-project combination of wiki, ticketing engine and
> repository browser. Tickets can be received by email, ticket updates
> can be emailed to a set of interested subscribers, and checkins to the
> repository can close tickets (via simple hooks). The wiki markup
> provides simple access to changes, tickets & files.
Trac doesn't really allow you to reply to tickets by email. At least,
not with any plugin that I've used.
Also, I've used trac for years for another project, and I wouldn't
recommend it. (It's been a memory hog, among other things).
--
Mike Kelly
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-04 0:07 ` Mike Kelly
@ 2009-11-04 9:38 ` Michael Stapelberg
2009-11-04 9:44 ` Israel Herraiz
0 siblings, 1 reply; 35+ messages in thread
From: Michael Stapelberg @ 2009-11-04 9:38 UTC (permalink / raw)
To: sup-talk
Hi,
Excerpts from Mike Kelly's message of Mi Nov 04 01:07:24 +0100 2009:
> Also, I've used trac for years for another project, and I wouldn't
> recommend it. (It's been a memory hog, among other things).
I’ve also used trac for quite some time now and I don’t recommend it
either. As soon as the spammers find your website, problems start. trac
has no built-in possibility to delete a comment/ticket, nor do any of
the anti-spam plugins work as they should (either they don’t recognize
spam, they have false-positives or they are totally cumbersome for the
user).
Best regards,
Michael
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-04 9:38 ` Michael Stapelberg
@ 2009-11-04 9:44 ` Israel Herraiz
2009-11-04 10:00 ` Michael Stapelberg
0 siblings, 1 reply; 35+ messages in thread
From: Israel Herraiz @ 2009-11-04 9:44 UTC (permalink / raw)
To: sup-talk
Excerpts from Michael Stapelberg's message of Wed Nov 04 10:38:20 +0100 2009:
> I’ve also used trac for quite some time now and I don’t recommend it
> either. As soon as the spammers find your website, problems start. trac
> has no built-in possibility to delete a comment/ticket, nor do any of
> the anti-spam plugins work as they should (either they don’t recognize
> spam, they have false-positives or they are totally cumbersome for the
> user).
I am not going to recommend Trac, because it does not fulfill the
requirements listed by William, but that thing you say is simply not
true.
I have been using Trac since a couple of years now, and it is sensible
to spam, ok, but you can always delete comments, tickets, or anything
in general, and force people to register to post comments or tickets,
to fight against spam.
Cheers,
Israel
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-04 9:44 ` Israel Herraiz
@ 2009-11-04 10:00 ` Michael Stapelberg
2009-11-04 10:05 ` Israel Herraiz
0 siblings, 1 reply; 35+ messages in thread
From: Michael Stapelberg @ 2009-11-04 10:00 UTC (permalink / raw)
To: sup-talk
Hi,
Excerpts from Israel Herraiz's message of Mi Nov 04 10:44:02 +0100 2009:
> I have been using Trac since a couple of years now, and it is sensible
> to spam, ok, but you can always delete comments, tickets, or anything
I am referring to trac 0.11.5, which does not have a possibility to delete
comments or tickets without installing a third-party plugin (which is
hard to use because you have to use ticket IDs). If I am wrong, please tell me
where they hid the possibility, so I don’t need the plugin anymore.
> in general, and force people to register to post comments or tickets,
> to fight against spam.
I consider forcing people to register to post comments/tickets as the end of
bug reports for my project. I personally would only register at a bugtracker if
the bug was *really* important and there would be *no* other possibility to
contact the author of the software. However, I want to get every bugreport for
my software and thus lower the requirements for users to actually help me
improve my software by submitting bugreports.
Best regards,
Michael
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-04 10:00 ` Michael Stapelberg
@ 2009-11-04 10:05 ` Israel Herraiz
2009-11-04 23:40 ` Israel Herraiz
0 siblings, 1 reply; 35+ messages in thread
From: Israel Herraiz @ 2009-11-04 10:05 UTC (permalink / raw)
To: sup-talk
Excerpts from Michael Stapelberg's message of Wed Nov 04 11:00:43 +0100 2009:
> I am referring to trac 0.11.5, which does not have a possibility to delete
> comments or tickets without installing a third-party plugin (which is
> hard to use because you have to use ticket IDs). If I am wrong, please tell me
> where they hid the possibility, so I don’t need the plugin anymore.
Check the *_ADMIN permissions. Any user with say TICKET_ADMIN
permission can remove tickets. Same applies to WIKI_ADMIN (remove wiki
pages), etc.
> I consider forcing people to register to post comments/tickets as the end of
> bug reports for my project. I personally would only register at a bugtracker if
> the bug was *really* important and there would be *no* other possibility to
> contact the author of the software. However, I want to get every bugreport for
> my software and thus lower the requirements for users to actually help me
> improve my software by submitting bugreports.
Right. It is not the best elegant solution at all.
Cheers,
Israel
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [sup-talk] Choosing a bug tracker for Sup
2009-11-04 10:05 ` Israel Herraiz
@ 2009-11-04 23:40 ` Israel Herraiz
0 siblings, 0 replies; 35+ messages in thread
From: Israel Herraiz @ 2009-11-04 23:40 UTC (permalink / raw)
To: sup-talk
Excerpts from Israel Herraiz's message of Wed Nov 04 11:05:45 +0100 2009:
> Check the *_ADMIN permissions. Any user with say TICKET_ADMIN
> permission can remove tickets. Same applies to WIKI_ADMIN (remove wiki
> pages), etc.
I am afraid I am wrong with this. Tickets can only be deleted by
manipulating the database. So Michael was right.
Sorry for the noise.
Israel
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2009-11-04 23:40 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-01 21:52 [sup-talk] Choosing a bug tracker for Sup Nicolas Pouillard
2009-11-02 1:17 ` Kevin Riggle
2009-11-02 8:30 ` Nicolas Pouillard
2009-11-02 7:01 ` Tero Tilus
2009-11-02 8:46 ` Nicolas Pouillard
2009-11-02 9:50 ` Tero Tilus
2009-11-02 14:58 ` William Morgan
2009-11-02 14:53 ` William Morgan
2009-11-02 17:38 ` Nicolas Pouillard
2009-11-02 14:50 ` William Morgan
2009-11-02 17:47 ` Nicolas Pouillard
2009-11-02 19:20 ` William Morgan
2009-11-02 20:23 ` Nicolas Pouillard
2009-11-02 20:40 ` Joe Wölfel
2009-11-02 21:49 ` Nicolas Pouillard
2009-11-03 14:50 ` Mike Kelly
2009-11-03 15:16 ` William Morgan
2009-11-03 15:34 ` Mike Kelly
2009-11-03 16:49 ` Reid Thompson
2009-11-03 17:03 ` Reid Thompson
2009-11-03 18:04 ` William Morgan
2009-11-03 19:30 ` Reid Thompson
2009-11-03 16:20 ` Sebastian Schwarz
2009-11-03 17:03 ` Daemian Mack
2009-11-03 18:06 ` Mike Kelly
2009-11-03 17:25 ` William Morgan
2009-11-03 17:37 ` Dan Falcone
2009-11-03 18:33 ` Tero Tilus
2009-11-03 23:11 ` Jim Cheetham
2009-11-04 0:07 ` Mike Kelly
2009-11-04 9:38 ` Michael Stapelberg
2009-11-04 9:44 ` Israel Herraiz
2009-11-04 10:00 ` Michael Stapelberg
2009-11-04 10:05 ` Israel Herraiz
2009-11-04 23:40 ` Israel Herraiz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox