On Wed, Apr 08, 2026 at 06:54:19PM +1000, Seth McDonald wrote:
(0) Does the codebase use as reference any particular set of standards
or implementations when choosing what libraries and functions to use?
For example, does it only use standard system calls that are included in
POSIX.1 (and if so, which version?), or that are available on Linux,
FreeBSD, macOS, etc.?
i'm not overly conservative about function use. if it's been widely
deployed on the major platforms for a while, it's good to go.
adding new library dependencies is a different story. the added value
would have to be rather substantial.
(1) When sending patches, do you prefer each single change as its own
patch in an overall patchset, or multiple related changes squashed into
a single patch? I personally default to the former, but can do the
latter if desired.
i think we are on the same page in principle.
(2) Would you be open to accepting patchsets whose sole purpose is to
refactor the code, such as for better modularity, extensibility,
flexibility, or just readability?
if the improvement is substantial, i'm open to it. but i don't like
pointless churn that just messes with git-blame. best you ask in
advance.
(3) Same as above, but for patches which mainly add function comments.
I do actually have a specific reason for this one. Many functions seem
to have a loosely defined purpose and behaviour, such that calls to them
sometimes depend on details of the function's implementation which need
not stay the same over time. Adding some comments outlining exactly
what behaviour should or should not be relied upon would (I think) be
beneficial for preventing such subtle misuse of functions.
i don't like verbosity, and it's in fact the reason why i haven't
applied your last series yet ... i need to think of ways to condense it
without losing the info i find valuable in principle.
comments have a very strong tendency to become stale.
for highly specialized functions with a single caller, having proper
apidocs is arguably more of a liability than an asset. such call chains
should be understood as a unit anyway, and should be modifiable with
minimal overhead.
for more general utility functions, something doxygen-like makes sense
in not entirely self-explanatory cases. i'm a fan of documenting
constraints with assert()s, some of which you'll find in my more recent
code. descriptions of object ownership are useful in non-obvious cases.
(4) Would you prefer patchsets be sent in only after any previous
patchset was reviewed and (if accepted) pushed upstream, or patchsets be
sent in whenever they're ready?
i don't care. you need to do the rebasing ...
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
