"Bruce Momjian" <bruce@momjian.us> writes:
> Suppose we were using a web-based discussion forum, rather than email.
That would be crazy, why would I suppose such a thing?
> For the patches lists I need to take sometimes entire threads, sometimes
> groups of comments, and store them in a format so people can review them
> as a digest.
Why do you need to do any such thing? What does any of that have to do with a
patches queue?
> If I link to a comment URL, how do people know if they should look at
> that comment or all comments below it?
They should look at whatever they want to. I usually have to back up several
messages to understand the context and then follow several messages later. You
can't possibly know how much context people will need to understand. You can't
try to control people to that level of detail.
> If I had omment URLs, how would I present those in a threaded way?
> So, if we did have a tracker, how would it be different? Comments would
> be more integrated but I am unclear how the patches_hold queue would be
> different.
A patches queue is just a list of patches with their current status. Not a
replacement for our mailing lists. You're trying to solve the wrong problem.
The current status for a patch is just something like "waiting for feedback on
questions from message [link]" or "waiting for new version addressing issues
raised in review [link]". That's it.
The critical information we need are: What's the most recent version of the
patch? what is it blocking on? and who is it blocking on?
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!