Re: bugs that have not been replied-to on list

Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> As in have a (hyptothetical) tracker being subscribed to -bugs (and maybe
> the other lists in the future as well) so the workflow would look like
> this:

Well there is a WIP to use an ArchiveOpteryX based solution to replace
the archives and get rid of the artificial breaking of pages. My guess
is that adding a status table linking to emails and that a set of
volunteers (they gave their names!) maintain would make our day.

> 1a. if somebody submits a request through the webform the tracker assigns an
> id and can automatically track all responses on the list

The AOX archive based system has a nice thread view based on some CTE
queries. Assigning an ID to emails that are not a response shouldn't be
hard to do in a trigger if necessary, and parsing the email subject line
for cases when the ID exists looks feasible too.

> 1b. if somebody submits directly to -bugs we could either have the tracker
> automatically create an id and track it or we could have a trivial interface
> to take a message-id and import on demand

AOX will just archive the mail in its PostgreSQL database upon
receiving, it's just another subscriber to the list.

> 2a. we can simply have the tracker export a dashboard status of:
>
> *) stuff that had no reply too (which is one of the open questions)
> *) if a commit has the bug id we could have it autoclose/autotrack that as
> well

That would be a set of queries with some dynamic web scripting
around. Plus the all the work to get to a usable WebUI of course.

> 2b. for the case of "not a bug"/"added to TODO"/"works as
> intended"/"pgadmin"/"JDBC" - we would either have to do a trival web
> interface to claim so or people could send status updates inline in the
> mail(at least the BZ emailinterface can take commands like "@close NOTABUG"
> or whatever)
>
> 2c. if a bug gets a reply but will never result in a solution per 2a or 2b
> we could add other dashboard as in "bug replied but no conclusion yet"

The triage would have to be manual. Or we could have some nice Tsearch
based queries to parse the mail content and offer an AI based dashboard
of waiting bugs. Sounds fun, he?

> Implementing this on our own (if that is about the workflow we want) is
> probably not even a lot of work, but we could also use an existing solution
> just as the backend engine and do the frontends ourselfs.

Did I mention AOX and the work in progress for the archives? :)
--
dim