On Thu, Jul 09, 2026 at 02:57:22PM +1000, Seth McDonald wrote:
On Tue, 07 Jul 2026 at 14:02:41 +0200, Oswald Buddenhagen wrote:
grepping the history for "factor" and "extract" (and "\<move", though that
yields a lot of false positives), you'll find that most refactorings are
directly followed by other changes that build on them.
For comparison, would you consider my initial macOS keychain patch
(d35919d8831c) to be a valid refactor due to the next two patches
building on it, or would it be leaning on being churn?
i still consider the initial version churn. what is in master-next now
is fine.
I ask to better understand what you consider as useful or needless wrt
refactoring.
dunno. the minimal change that yields a clearly improved end result?
but it's always a judgement call.
it's certainly tempting to extract the authentication logic, as that's 500
lines of seemingly well-isolated code.
you can give it another shot, but this time don't try to solve several
problems at once,
Sure thing. Can this involve an imap_auth.c file or must all logic stay
within drv_imap.c?
moving the implementation to a separate file would be the goal. any
added abstractions should be minimal, just enough to avoid circular
coupling between the layers.
Also now that I've learnt the GSASL API I'll try to tag along a second
patch adding that too.
excellent.
I'm inexperienced with regard to working on
branches that have fallen well behind from their base branch. As in I'm
unsure whether to, say, first rebase the branch on a newer commit, or
continue work on its current out-of-date base, or even just start anew
on master/master-next.
delaying the rebase would lead to a lot of duplicated work, so don't do
that. whether you attempt a physical rebase or redo it from scratch
depends on just how badly the code diverged. i suspect that a rebase is
still viable (a cherry-pick would be actually simpler, as it's just one
commit).
but before you start, consider whether the approach actually makes sense
as-is. logical parts are server, connection, protocol (further split
into command and response), store, and box, but i don't know where
actually good separation lines exist (i.e., how to cut without
over-abstracting it). dispatching responses to their associated commands
will be particularly interesting. a feature to plan ahead for would be
re-connecting at the low level while maintaining the high-level state,
so losing the connection wouldn't necessitate re-fetching the box state
from scratch.
the logical separation would be followed by physical separation. i'd
probably squash that after final review, ideally grouped by extracted
subsystem (without really good planning ahead, this may require
extremely conflict-ridden patch re-ordering operations; i've done that
before, just to get a nice history with minimal churn).
logistically, it's best if you create a fork i can directly pull from,
at least for the initial high-level review. sourceforge even has pull
requests, though they suck even more than those on github (i'm more of a
gerrit guy), and often notifications get lost.
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
