Re: New CF app deployment - Mailing list pgsql-hackers

On Fri, Feb 6, 2015 at 5:20 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Fri, Feb 6, 2015 at 5:51 AM, Magnus Hagander <magnus@hagander.net> wrote:
> So in an attempt to actually move this forward in a constructive way I'm
> going to ignore  a bunch of what happened after this email, and fork the
> discussion at this point.

Thanks, and I probably owe you an apology for some of that, so, sorry
about that.

I think the core of the problem here is that the old application saw
its goal in life as *summarizing* the thread.  The idea is that people
would go in and add comments (which could be flagged as comment,
patch, or review) pointing to particularly important messages in the
discussion.  The problem with this is that it had to be manually
updated, and some people didn't like that.[1]  The new app attaches
the entire thread, which has the advantage that everything is always
there.  The problem with that is that the unimportant stuff is there,
too, and there's no way to mark the important stuff so that you can
distinguish between that and the unimportant stuff.  I think that's
the problem we need to solve.

I'd like the ability to add a comment which does not get turned into an email.

I liked to add comments which would point out some fact that was important to testing but which was non-obvious. Often this fact was mentioned somewhere in the 300 message thread, but it needs to be called out specifically for people interested in testing but not so interested in architectural debates.  Obviously adding another email to a overly-long thread is going the wrong way when it comes to making things stand out better.  (Also, if the comment is about a uncommitted dependency, then the comment can be deleted once the dependency is committed)

One thing that would probably *help* is if the list of attachments
mentioned the names of the files that were attached to each message
rather than just noting that they have some kind of attachment.  If
people name their attachments sensibly, then you'll be able to
distinguish parallel-seqscan-v23.patch from
test-case-that-breaks-parallel-seqscan.sql, and that would be nice.

Yes, I was going to request that as well.