Re: obvious questions

Thank you for the detailed response. It has helped me understand the
flexibility of the bug tracking system much better.
I have tried to use agile tools and was literally boggled by all the
different players (wing captains, etc) and terms involved.
Based on what you told me about templates, it seems like Roundup will
accommodate diverse kinds of workflows.


I clearly have a lot of reading to do to fully realize all the
different use cases, but for the near term I just need a software
issue tracker and the template is just fine for that.

I do intend to use Roundup as a way to report faults found during
automated circuit board tests.
So from the sounds of it, I could repurpose a Milestone, to be a
production batch, and any faulty boards will automatically generate
"bugs" in that Milestone. Then as bugs are cleared the milestone could
be considered complete.

> Which tracker template are you using: devel or responsive?
> I think those two have the fields you mention below.

I chose responsive.

> >What makes a task different from an issue (other than the presence of
> >a severity column)?
>
> Issue is the generic term used by the classic tracker template (and
> jinja2 template since it uses the same schema). An 'issue' is
> something that can get update messages and is able to be tracked from
> start to finish.
>
> It looks like the devel template defines 'tasks' and 'bugs' as
> different issue types.
>
> A tracker can define multiple issue types. For example:
>
>    https://www.roundup-tracker.org/docs/customizing.html#tracking-different-types-of-issues
>
> defines a 'support' issue.
>
> My opinion on task vs. bug is:
>
>   bug - actual failure of software (or maybe misleading documentation issue)
>   task - request for enhancements, possible doc changes, build system changes
>          etc.
>
> but that's just my opinion. Unlike a lot of bug trackers or help desk
> software, it is not rigid. The schema and interfaces can be changed to
> support how you want to work.  If you don't want bugs and tasks, you
> can ignore the task issue type or remove it from schema.py.

This makes sense to me, thanks.

>
> Also the two types may have different visibility (access
> permissions). E.G. bugs might be visible to the anonymous user while
> tasks are not.

This is a good factor to keep in mind.

>
> I took a quick look at the schema. It looks like task links to a bug.
> So my guess is the intended use is:
>
>   * that bugs are submitted by the public/customers
>   * a task is opened to fix the bug.
>
> But I am just guessing here.
>
> Also, since multiple trackers came up in an earlier thread,
> https://www.roundup-tracker.org/docs/installation.html#running-multiple-trackers might be applicable.

Yes, multiple bug trackers will be essential; I will have a disjoint
sets of users.

> Hopefully some others will chime in about how they set up a tracker to
> support their software development.

Look forward to it.

Thanks,
Dave