Re: Next commitfest app release is planned for March 18th

> 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.
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
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.

> Perhaps it would be possible for the tooling to attribute bug fixes to
> 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(at)bowt(dot)ie> wrote:

> On Tue, Mar 4, 2025 at 4:38 PM Jacob Brazeal <jacob(dot)brazeal(at)gmail(dot)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
>