Fossil Forum

danshearer 2 weeks, 6 days ago

Post: Difference between bug forum and tickets

There is a big difference between Tickets and the Bug Forum. There is ticket documentation but this is different to the nice new Bug Forum as used for SQLite. The Bug Forum seems to be a few bug features on top of the documented ordinary forum and looks like a pretty smooth way of handling the hard problem of ticket management.

I am reviving a project that used the bugtracking feature a bit. While I don't care about migrating ticket history, I'm committed to using Fossil (because LumoSQL follows SQLite) and so the Bug Forum is probably what I need for future bug flow.

Where can I learn about the new Bugs Forum feature? Perhaps it's just a config feature I haven't noticed.

Thanks

--
Dan Shearer
[email protected]

stephan 2 weeks, 6 days ago

The Bug Forum seems to be a few bug features on top of the documented ordinary forum and looks like a pretty smooth way of handling the hard problem of ticket management.

The "forum-statuses" setting was added right after sqlite.org/bugs (a standalone, forum-only repository) went online, as a way to quickly sort through those posts. Yes, we could have used Fossil's ticket system, but it seems fair to say that none of us are very fond of it and the forum (which we all adore!) gives us about 95% of what this particular family of projects really needs from a ticket tracker.

Where can I learn about the new Bugs Forum feature? Perhaps it's just a config feature I haven't noticed.

It is exactly that:

stephan 2 weeks, 6 days ago

Edit reply: Difference between bug forum and tickets

danshearer 2 weeks, 6 days ago

Thanks, that helps.

So we just define a second forum (how does one do that?) and in that second forum, and set the statuses. Simple! It would be helpful if the status example had a full set of handy statuses rather than "..." so we can copy/paste a setup known to work to start with, even if a user will later edit it to suit.

D

stephan 2 weeks, 6 days ago

So we just define a second forum (how does one do that?)

Each is its own standalone, independent repository.

and in that second forum, and set the statuses

Correct.

It would be helpful if the status example had a full set of handy statuses rather than "..." so we can copy/paste a setup known to work to start with, even if a user will later edit it to suit.

There's not really a one-size-fits all list, and we do not want this setting turned on by default (so there's no default value), but here's the setting from sqlite.org/bugs:

[
{label:"Open",value:"open"},
{label:"Resolved",value:"resolved"},
{label:"Not Planned",value:"not-planned"}
]

Some care must be taken in the "value" parts - if those IDs change, forum posts which refer to the old IDs will behave as if they had the default status value, meaning the first one in the list.

danshearer 2 weeks, 6 days ago

Thanks, that helps.

So we just define a second forum (how does one do that?) and in that second forum, set the statuses. Simple! It would be helpful if the status example had a full set of handy statuses rather than "..." so we can copy/paste a setup known to work to start with, even if a user will later edit it to suit.

D

MelvaigT 2 weeks, 6 days ago

Edit: if your browser (like mine) is not jumping to that #status anchor

Which mine didn't, either - I think because the h2 tag has a 'name' attribute. Should be 'id', no? Ditto next two h2's.

andybradford 2 weeks, 6 days ago

but it seems fair to say that none of us are very fond of it and the forum

I actually do like the ticket system but I just don't have much use for it; especially that it's integrated. Maybe if I used it more I might find that I don't really like it.

stephan 2 weeks, 5 days ago

... 'name' attribute. Should be 'id', no? Ditto next two h2's.

Fixed, thank you. There's a long history of confusion between name and id on my part :/.

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button