fix(TUI): selected column and row of table are now preserved during update

[JosephGoulden]

Currently if you move around a TUI table (e.g. peers) with the arrow keys your selection is reset every time the table is updated with a call to set_items(). This change is to preserve the selected row and column which should make is easier to monitor a selected peer for example.

[antiochp]

🔥 Let me test this out locally. 👍 on what we are fixing here.

[antiochp]

We do need to make a decision around the trade-offs involved in merging this (and any other fixes) between now (beta.1) and 3.0.0 release.
I would lean toward merging this but we should have some consensus here around the decision making process itself.

The trade-off being fixing issues and improvements vs. the risk of introducing other (potentially subtle) issues inadvertently.

[lehnberg]

As per the timeline in our process doc, code freeze is scheduled for Dec 12, defined as:

No changes are permitted on the branch to be released except critical bugs.

Today is the 9th. So technically, this could get merged in before Thursday and it would be fine. After Thursday it would not be fine.

Personally however, I lean towards not merging anything that's not in scope and not critical at this point, because I prefer a more solid quality, less capable build, over a more capable but less performant release. And I worry about our testing capabilities. I suspect it's quite easy for problematic bugs to sneak in without us noticing it, but I have no basis for this claim. We'd add more risk, at a point where I feel we have enough risk as is already.

That's just my 2 grins worth. But yes, might be something to talk about in tmrw's dev meeting, if you'd like to add a point to the agenda?

[hashmap]

what about aiming for 3.1 in a month after 3.0?

[yeastplume]

There's one or two things I wouldn't mind squeezing in this week, (mostly very superficial), let's discuss at dev meeting tomorrow.

[JosephGoulden]

Sorry I might not be able to available to discuss tomorrow. This is relatively low risk in my opinion, over a month of testing seems like plenty of time. But I've not been around for previous releases so if consensus is it's too risky then that's fine. I'll have some time the next few weeks to help fix any issues (particularly with things I worked on).

[antiochp]

So technically, this could get merged in before Thursday and it would be fine.

Personally however, I lean towards not merging anything that's not in scope and not critical

Yes. That's kind of what I mean - "code freeze" does not necessarily mean anything goes prior to that.
That said I agree with @JosephGoulden here, this is low risk and I think likely fine (pending some extra eyes on it and some local testing).

I just wanted to bring this up somewhere and this was as good a place as any.

[antiochp]

Tested this locally with #3160 and it all looks good. I think its worth the minimal risk involved in merging this close to beta.2