Sorting for applied and thanked reviews

Sorting for applied and thanked reviews

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

Hi Konstantin,

Currently it looks like in progress, applied and thanked reviews are all
sorted together (by activity I think?), with reviews that are snoozed or
waiting for new versions sorted after them.  This seems a bit
surprising, I'd expect at least the thanked reviews to be sorted even
further down the list than those that are in progress but waiting for
something.

Thanks,
Mark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Sorting for applied and thanked reviews

[Konstantin Ryabitsev]

On Tue, Mar 17, 2026 at 07:22:03PM +0000, Mark Brown wrote:
> Currently it looks like in progress, applied and thanked reviews are all
> sorted together (by activity I think?), with reviews that are snoozed or
> waiting for new versions sorted after them.  This seems a bit
> surprising, I'd expect at least the thanked reviews to be sorted even
> further down the list than those that are in progress but waiting for
> something.

We currently split all your tracked series into "action required" ones at the
top and "action not required" ones at the bottom, which is why all your
snoozed and waiting series are below everything else. Within these two
sections, the series are sorted by when they were last added to your tracking,
not by most recent activity. I used to sort them by latest activity but I
hated that they jump around -- if you have 5 series that you're working on
throughout the day, you benefit from visual memory if they all sit in one
spot.

I was expecting that "thanked" series would be prime candidates for archiving,
which is why they are kept in "action required". However, it's an easy change
to add them into "no action required".

We can instead differentiate this into:

active:

    - new
    - reviewing

action required:

    - replied
    - accepted
    - thanked

inactive:

    - snoozed
    - waiting

Does that work, and how would you sort these?

-- 
KR

Re: Sorting for applied and thanked reviews

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

On Tue, Mar 17, 2026 at 05:03:51PM -0400, Konstantin Ryabitsev wrote:

> We currently split all your tracked series into "action required" ones at the
> top and "action not required" ones at the bottom, which is why all your
> snoozed and waiting series are below everything else. Within these two
> sections, the series are sorted by when they were last added to your tracking,
> not by most recent activity. I used to sort them by latest activity but I
> hated that they jump around -- if you have 5 series that you're working on
> throughout the day, you benefit from visual memory if they all sit in one
> spot.

Is "last added" last update to the series?  I did notice the order
seemed to move at times.

> I was expecting that "thanked" series would be prime candidates for archiving,
> which is why they are kept in "action required". However, it's an easy change
> to add them into "no action required".

Given that I'm using the queued thanks feature things sit in applied for
a bit before they actually get pushed out and thanked, the sorting of
thanked mostly followed from expecting applied to get moved out of the
active list while I go through other things that might get applied.  

I'm not actually currently archiving anything because I need to sort out
how I sync that between machines (which is one of the things I've jumped
on b4 review to solve) but that's a separate thing.  I think I know what
I'm doing there but I didn't actually do it yet.

> We can instead differentiate this into:

> active:

>     - new
>     - reviewing

> action required:

>     - replied

As a side note b4 is picking up replies I send with other mail clients
but doesn't track them as changing series state AFAICT.  I'm not sure if
this shouldn't sort into inactive (as waiting for reply) but it's going
to be more a case by case thing I think ("Thanks for doing this, let me
test!" vs "Could you clarify these things?").

>     - accepted
>     - thanked

> inactive:
> 
>     - snoozed
>     - waiting

> Does that work, and how would you sort these?

That would work for me I think.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

Re: Sorting for applied and thanked reviews

[Konstantin Ryabitsev]

On Tue, Mar 17, 2026 at 10:21:38PM +0000, Mark Brown wrote:
> Is "last added" last update to the series?  I did notice the order
> seemed to move at times.

It's when the series was first added to your tracking, which shouldn't change.
However, the sort is stable within each tier, so if a series changes tiers
(e.g. goes from "reviewing" to "waiting" and back), it may end up in a
different position relative to its neighbours. I'll keep an eye on whether
that's confusing in practice.

> Given that I'm using the queued thanks feature things sit in applied for
> a bit before they actually get pushed out and thanked, the sorting of
> thanked mostly followed from expecting applied to get moved out of the
> active list while I go through other things that might get applied.

I've now landed the 3-tier sort, plus a "queued" pseudo-state for exactly this
case. When you accept a series and queue the thank-you letter, it will show
with a different symbol and sort into the inactive tier alongside snoozed and
waiting series. Once the thank-you is actually delivered, it becomes "thanked"
and stays in the inactive tier. So neither queued nor thanked series will crowd
your active list.

The tiers are:

    active:        new, reviewing
    action needed: replied, accepted
    inactive:      snoozed, waiting, queued, thanked

> As a side note b4 is picking up replies I send with other mail clients
> but doesn't track them as changing series state AFAICT.  I'm not sure if
> this shouldn't sort into inactive (as waiting for reply) but it's going
> to be more a case by case thing I think ("Thanks for doing this, let me
> test!" vs "Could you clarify these things?").

Yes, I'm not sure we can reasonably make the right call here. I would
recommend judicious use of the "snooze" action here. :)

Regards,
-- 
KR

Re: Sorting for applied and thanked reviews

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

On Wed, Mar 18, 2026 at 10:17:12AM -0400, Konstantin Ryabitsev wrote:
> On Tue, Mar 17, 2026 at 10:21:38PM +0000, Mark Brown wrote:

> > Given that I'm using the queued thanks feature things sit in applied for
> > a bit before they actually get pushed out and thanked, the sorting of
> > thanked mostly followed from expecting applied to get moved out of the
> > active list while I go through other things that might get applied.

> I've now landed the 3-tier sort, plus a "queued" pseudo-state for exactly this
> case. When you accept a series and queue the thank-you letter, it will show
> with a different symbol and sort into the inactive tier alongside snoozed and
> waiting series. Once the thank-you is actually delivered, it becomes "thanked"
> and stays in the inactive tier. So neither queued nor thanked series will crowd
> your active list.

Thanks, this seems to be working great.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

b4 review handing of rebasing issues for new versions

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

Hi Konstantin,

The new series version handling has a bit of an inconvenient interaction
with the new version being required for rebasing reasons.  The status of
the series is keyed off whatver version of the series that is currently
applied and if a new version is sent it'll be offered as an upgrade.  If
that new version fails to apply to something useful a common way of
handling it would be to say so and wait for the submitter to resend but
if you mark the series as waiting for a new version without applying the
current version then any time you check for updates the version that
fails will be seen and the series moved out of waiting which is
unhelpful.  It'd be good if the new version tracking noted what the
expected new version was rather than assuming that it's anything newer
than the currently applied one.

Thanks,
Mark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: b4 review handing of rebasing issues for new versions

[Konstantin Ryabitsev]

On Tue, Mar 17, 2026 at 07:13:54PM +0000, Mark Brown wrote:
> The new series version handling has a bit of an inconvenient interaction
> with the new version being required for rebasing reasons.  The status of
> the series is keyed off whatver version of the series that is currently
> applied and if a new version is sent it'll be offered as an upgrade.  If
> that new version fails to apply to something useful a common way of
> handling it would be to say so and wait for the submitter to resend but
> if you mark the series as waiting for a new version without applying the
> current version then any time you check for updates the version that
> fails will be seen and the series moved out of waiting which is
> unhelpful.  It'd be good if the new version tracking noted what the
> expected new version was rather than assuming that it's anything newer
> than the currently applied one.

That makes sense. I'll make it possible to specify which version you're
waiting for on the waiting screen.

bugspray tag b4/review

-- 
KR

Re: b4 review handing of rebasing issues for new versions

[B4 Bugbot]

Hello:

This conversation is now tracked by b4 bug tracker.
There is no need to do anything else, just keep talking.

--
Deet-doot-dot, I am a bot.
b4 bug tracker (bugspray 0.1-dev)

Re: b4 review handing of rebasing issues for new versions

[B4 Bugbot]

Konstantin Ryabitsev writes in commit fed4cd88f9dc9b7370fcdb292aa27ecf40626635:

review: do not re-promote waiting series for already-known versions

When a newer version of a series fails to apply and the maintainer
puts the series back into waiting, the next update cycle would
immediately wake it up again because the (broken) version is still
newer than the checked-out revision. Fix this by comparing discovered
versions against what was already known in the revisions database
before this update cycle, rather than against the applied revision.

This means a waiting series is only promoted when a genuinely new
version appears — one that was not already recorded in the database.

Reported-by: Mark Brown <broonie@kernel.org>
Closes: https://msgid.link/069aac52-a9a2-44e1-bdbb-eabc82e23641@sirena.org.uk # 4a2fb75
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Assisted-by: claude-opus-4-6-20250904

--
Deet-doot-dot, I am a bot.
b4 bug tracker (bugspray 0.1-dev)