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

From Andres Freund
Subject Re: New CF app deployment
Date
Msg-id 20150206120148.GD24534@awork2.anarazel.de
Whole thread Raw
In response to Re: New CF app deployment  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On 2015-02-06 11:51:50 +0100, Magnus Hagander 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.

Sounds good.

> First of all - assuming we'lI fix this particular thing. Are there *other*
> things that you would also say makes the tool "essentially unusable"?

I personally don't have any really fundamental complaints but this
one. I'd like to be able to add some CF app only annotations to the
whole patch, but that's not that important.

> What kind of annotation are we actually talking about here?

Well, to explain where, at least I, am coming from, let's have a look at
an example:
https://commitfest.postgresql.org/4/17/

a) The linked messages aren't going to help either the author, a  committer or prospective reviewers to find existing
reviews.And  looking through the whole thread isn't realistic at that message  count. And all of them need to.
 
b) The 'latest attachement' isn't actually the patch that's supposed to  be reviewed. The first patch is completely
outdated.So one would  need to grovel through all the linked patches.
 
c) By just looking at the CF entry I have no clue what the status of the  patch actually is. Sure it "Needs review",
butthat can mean minor  changes or major reworks. In the old app the comments to the patches  and reviews could say
thingslike "major issues identified,  significant work needed", "some cosmetic issues remain", "new version  of patch
withmajor redesign" or "rebased patch without other changes".
 

I don't think any of these questions can be answered by improved
automatisms alone.

This really doesn't matter much on a 5-10 message thread about a simple
patch. But we regularly have thread with hundreds of messages.


Makes sense?


> Are you looking for something that's basically "star a message" (like
> you'd do in a MUA in a lot of cases)? Or "assign tag" (from a set of -
> editable of course - pre-existing tags). Or a complete free-text
> field?

I think it has to be free form. If you look at the above, it's hard to
do that sanely with tags.

> Then, what do you need to be able to annotate on?

I think both individual messages and the CF entry itself, without an
email, make sense.

> Right now the app only shows messages that actually have attachments on
> them, assuming that you'd want to read the whole thread if you want to look
> at other things.

I don't think anybody can realistically do that on more complex
patches. Often the discussion in the beginning has little bearance on
later state, so even if you had the time to do so, it'd better be spent
doing something else.

> Are you saying you want to be able to attach an annotation to *any*
> message in the thread?

Yes.

> If so, we'd have to pull in and show every single message on the
> thread in the UI - I'm thinking that might become more than a little
> cluttered in a lot of cases.

Well, we only would need to show commented on messages in the UI when
viewing the entry.

> If that is what you're talking about, any
> suggestions for how to actually make that into an UI that's not that
> cluttered?

The simplest seems to be to simply allow comments using the message id
:(. I've no really good idea how to allow to select the message to
comment on. Even if we find something else, it should probably be at
least an option - it certainly is quicker for me to grab the message id
of an email I just read or wrote and paste it than pretty much any other
method.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_basebackup may fail to send feedbacks.
Next
From: Michael Paquier
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes