sync_up: Discussion, add rest of points from thread

diff --git a/meetings/sync_up/discussion/sync_up_2024-01-16_discussion.mdwn b/meetings/sync_up/discussion/sync_up_2024-01-16_discussion.mdwn
index 1da0ebe360827dd9b21125bea6e4f520649dc944..b54cf44176e41c98e34135a3aacca232b5c78484 100644 (file)
--- a/meetings/sync_up/discussion/sync_up_2024-01-16_discussion.mdwn
+++ b/meetings/sync_up/discussion/sync_up_2024-01-16_discussion.mdwn
@@ -9,7 +9,7 @@ in the wiki.
 
 ## Points to be discussed
 
-Dmitry's main point of concern:
+Dmitry's points of concern:
 
 * As a developer, I should have a liberty to interactively rebase, fixup,
 squash commits, commit when I can and want, and same for push. If there are
@@ -17,6 +17,55 @@ restrictions on this from NLnet side, these must be explicitly published on
 their own guidelines. I'm sure they have different forms than the ones
 exposed.
 
+* My point is, as I work on it as an individual in my free time, I
+should have flexibility to a certain degree to develop it when and how
+I want. And I commit the code when it's at least somewhat "ready" and
+"stable" and "beautiful" according to my personal standards. I
+extensively use interactive rebase to make the history readable. When
+I find that some branch commit introduced an error, I go back there
+and edit it interactively, then force push. This makes the linear
+history work when the master is rebased, decreases the chance of the
+later bisect and simply avoids the trash like "oh look I fixed a typo"
+for the code which just got rebased into the master (unless required).
+
+* Obviously this works better in branches or in master if you have force
+push rights (and likely develop alone); but it has its own benefits.
+Obviously it isn't a silver bullet, but it makes the history way
+better, and that's the approach I always follow. And now, despite that
+nobody had problems with this before, now we have this discussion.
+This is not the first time we have some rules established for which we
+lack the explicit requirements. The lack of these is fine as long as
+there's a technical rationale. I doubt any real SW project has a
+"commit whatever you have" policy. Real SW projects follow "commit
+respectively and wisely" policies instead.
+
+* Indeed, these statements are vague and reflect my own personal
+experience and preferences. But, unless you have a real severe cause
+to completely bend someone else's behavior and habits into the way you
+like it, I'd prefer to avoid it. You know I don't have massive chunks
+of the code with me (I wouldn't even if I had time, what's the
+purpose?). But I try to avoid "trash" commits, I try to commit things
+which work, and I always worked this way. After all, it's an Open
+Source development, not some corporate idiocracy.
+
+* As for "we're afraid something might get lost", I'd recommend starting
+with the different places to think about. For example, git and CI.
+These seem to be much better targets; these are the real points of
+failure.
+
+* Yes this is subjective; I hope we _all_ are subjects though. "Commit
+once you think it's good enough to show to others, it breaks nothing,
+there's nothing to be ashamed of, you find it appropriate to publish
+at this stage" -- these all look reasonable. The beauty is in the eyes
+of the beholder.
+
+Dmitry's point on his personal time:
+
+* My point is, I
+really have not much time to work, and I indeed try hard to dedicate
+all the free time I have. Please don't make me feel that I waste this
+time taking the spokes out of the wheels. :-)
+
 Jacob's response:
 
 * Assuming you're not working directly on the master branch, I think it
@@ -33,6 +82,16 @@ code -- after all it's really hard to spot bugs in code you can't see!
 * I don't think there are any NLNet restrictions other than that code needs
 to be public before submitting RFPs.
 
+* we should probably put our conclusions in the developer documentation,
+Andrey would you be willing to do that? icr if that docs bug is closed
+yet...there's probably a good task to put this under.
+
+* maybe just expand the existing wiki section somewhat?
+
+*(Andrey: I agree. A first rough draft will probably be this page.
+Only the most important points the team agrees on will be written
+into HDL_workflow, if not already present.)*
+
 Luke's responses:
 
 The "regular commit push" approach imitates corporate backup systems:
@@ -149,6 +208,13 @@ get paid for private work, as this directly conflicts with
 NLnet's "Works for the Public Good" mandate.
 ```
 
+Luke on git history cleanup:
+
+```
+i worked out Dmitry, that you probably actually enjoy doing the
+git history cleanup, it is a sense of satisfaction and pride :)
+```
+
 Point made by Andrey to Dmitry:
 
 * I understand your concern of being able to develop independently,