Choosing a bug tracker for Sup

[Nicolas Pouillard-2]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Kevin Riggle-3]

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@...)
MIT Class of 2010, Course VI-2 (EECS)
http://free-dissociation.com
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Tero Tilus-2]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Nicolas Pouillard-2]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Nicolas Pouillard-2]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Tero Tilus-2]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[William Morgan-4]

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@...>
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[William Morgan-4]

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@...>
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[William Morgan-4]

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@...>
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Nicolas Pouillard-2]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Nicolas Pouillard-2]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[William Morgan-4]

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@...>
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Nicolas Pouillard-2]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Joe Wölfel-2]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Nicolas Pouillard-2]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Mike Kelly-2]

On Mon, 02 Nov 2009 06:50:08 -0800, William Morgan
<wmorgan-sup@...> 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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[William Morgan-4]

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@...>
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Mike Kelly-2]

On Tue, 03 Nov 2009 07:16:15 -0800, William Morgan
<wmorgan-sup@...> 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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Sebastian Schwarz]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[jreidthompson]

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@...> 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@...
http://rubyforge.org/mailman/listinfo/sup-talk