Re: Next commitfest app release is planned for March 18th - Mailing list pgsql-hackers
| From | Jacob Brazeal |
|---|---|
| Subject | Re: Next commitfest app release is planned for March 18th |
| Date | |
| Msg-id | CA+COZaBCrqeWeQYwM5r+OtfYNtUQ7N3z2gWb9Y=9zvpAsHWRkw@mail.gmail.com Whole thread Raw |
| In response to | Re: Next commitfest app release is planned for March 18th (Peter Geoghegan <pg@bowt.ie>) |
| List | pgsql-hackers |
> It'd be nice if the UI had usable hyperlinks that could be bookmarked
> by my browser. One hyperlink for each of the views.
Sounds reasonable!
> Probably "Recommended patches for you to check". Things that are on
> the periphery of my interests have the greatest chance of being picked
> up, I think.
> the periphery of my interests have the greatest chance of being picked
> up, I think.
That's great. I think, from the feedback we've gotten so far, that we're pretty good at finding patches relevant to particular committers. However, there are several plausible ways to filter; any thoughts on your prefered defaults here?
* Does the patch need another reviewer?
* Am I already in the thread, as author or reviewer, and need to respond?
* Are there outstanding issues in the thread?
(Maybe we just make them all explicit toggles in the UX).
Right now, the default view is basically "show me patches that are relevant to me, and need another review."
> I guess it would be nice if the tooling could figure out which commits
> ultimately came from a given closed-out CF entry -- without requiring
> the user to update that manually when they go to mark an entry as
> committed
> ultimately came from a given closed-out CF entry -- without requiring
> the user to update that manually when they go to mark an entry as
> committed
Oh, that makes sense. We'd need to get this thing properly integrated with commitfest, but it seems to me we could cross-reference the patches in a thread with new commits.
> particular commits, where the bug first appears.
Difficult, in the general case. :) We are looking into something related on the buildfarm side though, as it's easier to tell when a particular failure began there. Of course, most bugs don't break the farm.
On Tue, Mar 4, 2025 at 2:12 PM Peter Geoghegan <pg@bowt.ie> wrote:
On Tue, Mar 4, 2025 at 4:38 PM Jacob Brazeal <jacob.brazeal@gmail.com> wrote:
> Out of curiosity, what features would make it most useful to you? Right now it's trying to do all of the following:
> * Summarize threads
> * Help you find threads about things you're interested in, independent of what you've commented on
> * Help you find threads that need a review
> * Help you find threads to commit, if you're a committer.
Those are useful goals. The difficulty is putting it all into action.
> I think the UX is a bit confusing right now and it might not be obvious how to do all of these things. For example,
> I think your default view right now is mostly showing you patches you wrote, which is a bit of an accident (if you
> scroll down, you'll see some patches you didn't author, but are probably relevant to you.)
It'd be nice if the UI had usable hyperlinks that could be bookmarked
by my browser. One hyperlink for each of the views.
> I think we can fix all of this up in the UX, but my question to you might be:
> * What would a good default view be?
Probably "Recommended patches for you to check". Things that are on
the periphery of my interests have the greatest chance of being picked
up, I think.
> * What filters would be useful to you?
Nothing comes to mind.
> * How could we optimize your patch-review workflow, in general?
I guess it would be nice if the tooling could figure out which commits
ultimately came from a given closed-out CF entry -- without requiring
the user to update that manually when they go to mark an entry as
committed. Attributing a commit or commits to a given closed out CF
entry is squishy at times, but it wouldn't have to be perfect.
Perhaps it would be possible for the tooling to attribute bug fixes to
particular commits, where the bug first appears. That isn't always
possible, even for a human expert. But it is often fairly obvious,
even to a non-expert.
I have no idea how feasible any of this is, or what the constraints
really are. These suggestions are made based on some fairly optimistic
assumptions about how hard this would be to put into action. These are
just nice-to-haves for me, so if it was a great deal of work then it
seems hard to justify.
--
Peter Geoghegan
pgsql-hackers by date: