Re: No Issue Tracker - Say it Ain't So!] - Mailing list pgsql-hackers
| From | Magnus Hagander |
|---|---|
| Subject | Re: No Issue Tracker - Say it Ain't So!] |
| Date | |
| Msg-id | CABUevEwQCcfKS=_sW7dwcwbwFHAaN7ScpJZVP68dgx7btduFGg@mail.gmail.com Whole thread Raw |
| In response to | Re: No Issue Tracker - Say it Ain't So!] (Nathan Wagner <nw+pg@hydaspes.if.org>) |
| List | pgsql-hackers |
On Mon, Oct 5, 2015 at 2:08 AM, Nathan Wagner <nw+pg@hydaspes.if.org> wrote:
On Sun, Oct 04, 2015 at 04:30:49PM -0700, Josh Berkus wrote:
> That would be the key part, wouldn't it? Nice that you have [code to
> store and parse email messages].
Yeah. It actually made most of the work pretty easy. It's available
with a bunch of other code at https://pd.if.org/git/ if anyone wants it.
I did find a bug in my header processing though, so I'll need to commit
that fix.
Note that we already have all the emails in a database, as parsed out for archives.postgresql.org. There is also an API for this, but it's only available internally. This one is used for example by the commitfest app, which is in many ways doing things that are very similar to this one. If we were to proceed down this road, I would strongly suggest that we utilize this API (at least then we will have a consistent set of MIME parsing bugs..)
> We'd also want a way to link a bug fix to a commit, and probably a way
> to give the bug a list of searchable keywords (and add to that list).
I've been thinking of hooking it up to the fti machinery and providing
a search box. I've never really used fti before, so this might be a
good opportunity to learn it for real.
Again, we already have an API for searching the archives that can do this for us. No need to re-invent the wheel there. (And it's based on the PostgreSQL fts functionality - of course)
> > it probably makes sense to just close up front bugs that are marked
> > against unsupported pg versions, or haven't had any activity for too
> > long, perhaps two years.
> I'm reluctant to close all of those unexamined, since part of the
> purpose of this is to find bugs which were never fixed. Probably we
> should organize a posse to comb trhough all of the old bugs and
> hand-close them.
I'm doing some of that as I poke at the bugs pages. Perhaps it would
make sense to have a closed status of 'stale' or the like (perhaps
that's what you meant by 'timed out') which could be used to get bugs
out of the main list but still be marked as 'not human reviewed'. These
could then be reviewed by the posse.
I think this is definitely a state that's needed, no matter what it's called. In particular in the beginning.
But if looking at the bugtrackers at other projects, this is a state that often holds a *lot* of bugs. And having an explicit one like that would make it easier for all the volunteers to know what to look at immediately - it would be a good goal for such a group to ensure that no bugs remain in that state.
> Yeah, fixing this [email's without a bug id] would probably be tied to
> the possible change to mailman. Unless someone already has a way to
> get majordomo to append a bug ID.
How are bug ids assigned now? From the evidence, I assume there is a
sequence in a database that the web submission form queries to format a
resulting email to the bugs mailing list. Do the mailing lists live on
the same server? If so, perhaps it would be easy to assign a new bug id
to a new thread on -bugs. But perhaps that's too aggressive in creating
bugs.
Correct, that's exactly what it does.
I don't think we want to assign a new bug id to a new thread immediately. Given how many people post a new thread referencing an old one.
I think we'd want an interface that lets you either pick an existing thread on bugs that has no bug id and create one for it, or pick a thread and attach it to an existing thread. Note that we also need to cover things like threads on hackers (it's very common that a thread is opened on hackers about the same point), as well as the enentual commit message.
Again, this is fairly similar to what the commitfest app does, by allowing you to attach multiple threads.
I'm not saying it's a good idea to use the CF app as-is, but the fact is that much of what it does is very similar - it adds a bunch of metadata to mailthreads and tracks that metadata. Which is pretty much what this tool would/should do. But it's an almost completely different set of metadata, so I don't think merging them is a good idea.
> > 5: How can we use email to update the status of a bug?
> >
> > I suggest using email headers to do this. 'X-PGBug-Fixed:
> > <commitid>' and the like. I assume here that everyone who might
> > want to do such a thing uses an MUA that would allow this, and they
> > know how.
>
> I guess that depends on who we expect to use this, at least for
> closing stuff.
I could certainly support more than one mechanism. A web interface for
those who would prefer such and emails would seem to be the basic
requirements.
Using email headers I think is a no-go. Way too many of the people who would be doing it don' use MUAs that let them do that. I think the way to go is in-message keywords at the start of a line. And in that case everybody should use those, to make things consistent.
> > 6: Does there need to be any security on updating the status?
> >
> > Probably not. I don't think it's the sort of thing that would
> > attract malicious adjustments. If I'm wrong, I'd need to rethink
> > this. I realize I'm making security an afterthought, which makes my
> > teeth itch, but I think layers of security would make it much less
> > likely to be actually adopted.
>
> I think there needs to be some kind of administrative access which
> allows, for example, an issue to be closed so that it can't be
> reopened.
I guess technically we have that now since I'm the only one who can
close or open a bug in the db I've set up :)
Seriously though, I think it probably makes the most sense to tie the
system in with the existing pg community accounts if it goes that far.
Yes, absolutely 100% that. We do not need another set of userids etc.
We might want to need the ability to assign permissions based on *what* is done. More workflow base. As said, it will probably be required to be able to prevent a bug from being reopened. But I think it's a good idea to by default allow anybody to do that - sort of like the wiki, where we let anybody do the edits, but we do end up locking some pages later on if things are being abused.
//Magnus
pgsql-hackers by date: