Gregory Stark wrote:
> "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?
TODO items and patches are often in the middle of threads.
> > 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?
The discussion was mostly related to the 8.3 patches_hold queue where
people wanted help processing it.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +