sync_up: Discussion page for tomorrow's meeting

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
new file mode 100644 (file)
index 0000000..e0d0718
--- /dev/null
+++ b/meetings/sync_up/discussion/sync_up_2024-01-16_discussion.mdwn
@@ -0,0 +1,158 @@
+# Discussion of commit frequency - Tuesday 16th January 17:00 UTC
+
+* Link to sync-up meeting: 
+
+Discussion of commit frequency and other points mentioned in
+[this](https://lists.libre-soc.org/pipermail/libre-soc-dev/2024-January/005912.html)
+email thread. After meeting discussion, points agreed upon will be documented
+in the wiki.
+
+## Points to be discussed
+
+Dmitry's main point 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
+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.
+
+Jacob's response:
+
+* Assuming you're not working directly on the master branch, I think it
+should be sufficient to push a WIP commit with whatever changes have been
+made by the end of the day, that can be rebased, squashed, amended, etc.
+next time you work on it. (if you're working on master, please don't
+rebase/squash/amend any commits, use a separate branch if you want that,
+then push to master once the commits won't change anymore)
+
+* It would also be useful but not required to push your current code if
+you're posting major results or asking questions, so others can see your
+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.
+
+Luke's responses:
+
+The "regular commit push" approach imitates corporate backup systems:
+
+```
+if you were working for a Corporation (and they were any good)
+your private machine would be backed up by the IT Staff,
+onto redundant servers, every day, without fail, so that there
+is abolutely no chance work could be lost.
+
+it would not be your problem, because the Corporation IT Staff
+set up your machine, give it to you with backup software
+pre-installed, it s basically not your problem, and you would
+not be "wasting your time" on backups.
+
+the FOSS equivalent of that is that you push, again, without
+fail, to a public repository, but this is of course taking
+up *your* time to do it. this is unfortunate but necessary,
+as we obviously cannot invade your privacy of *your* personal
+local machine to forcibly push to Libre-SOC servers to ensure
+backups and Transparency!
+```
+
+Luke ensures there are at least 3 backups of the LibreSOC project:
+
+```
+i have TWO remote machines doing daily backups of the server
+and i want it increased to 3. i also do a 3rd intermittent
+server backup (manual rsync) because being on a Mobile Internet
+it costs me USD 3 per Gigabyte, i only do that if absolutely
+critical.
+
+so that is 3 backups and i really want it to be 4.
+
+then also there is salsa and other servers and all developers also have
+clones of the repos, but they are intermittent and
+cannot be relied on, plus cannot back up the full server itself,
+just the repos.
+```
+
+Luke's point whether Nlnet requires such restrictive measures
+(answer to Jacob's point):
+
+```
+yes you are correct, but the backgground/context is that it
+is far stronger than that with very serious implications.
+
+their mandate is "Works for the Public Good".
+if it's not public, then they would be in flagrant
+direct violation of Dutch Foundation Law to give money
+out for private work, which no messing about
+is jail time for the Directors.
+```
+
+Luke also asked Dmitry why is it an issue to follow the approach
+of committing and pushing frequently.
+
+One of the reasons perhaps could be slow or low-bandwidth
+internet, but given the low overhead of git pulls/pushes, this
+isn't an issue in practice.
+
+The point to perform regular git commits is documented in
+[[HDL_workflow]] (documents LibreSOC standard procudures),
+in the "git" section.
+
+Luke mentions that if an argument exists for not following the
+procedure, it needs to be mentioned:
+
+```
+if you can provide an explanation as to why you consider it
+reasonable to not follow the Project Standard Procedures
+as outlined in the HDL Workflow page, then we have a
+justification to put in front of NLnet and the EU Auditors,
+and everything is fine.
+
+this is basic ISO 9001 QA Procedure, which I trained in back in
+1993. the "red flag fail" is not when you don't document
+something, it's when you say you are going to follow a certain
+procedure / practice *and then do not follow it*.
+
+it is documented in HDL Workflow *all* commits shall be pushed,
+and you are requesting, Dmitry, not to follow that Procedure.
+you therefore explicitly need to explain clearly (and publicly),
+no fuss, and there is no criticism here expressed *or implied*:
+why you are not going to follow that Documented Procedure, ok?
+```
+
+*(Andrey: I didn't see HDL_workflow say
+"all commits shall be pushed". It makes sense given that Nlnet
+only pays for published work, but perhaps this needs to be
+written explicitly?)*
+
+Luke also made a point that
+there may be exceptions due to privacy/security concerns, but
+those must be discussed outside of LibreSOC public sytems:
+
+```
+if there is a privacy or security reason
+that you cannot reveal publicly, then NLnet will be perfectly
+understanding of that as well, but the discussion there
+has to move *offline* and not take place on Libre-SOC public
+servers. it is one of the *only* exceptions to the rule
+"everything is public". NLnet do actually fund some very
+senstive projects, where anonymity of the developers is
+absolute top priority... *but* the work still has to be
+public, to fulfil "Works for the Public Good" Mandate.
+```
+
+Also a point on Nlnet:
+
+```
+as Jacob points out, you absolutely cannot
+get paid for private work, as this directly conflicts with
+NLnet's "Works for the Public Good" mandate.
+```
+
+Point made by Andrey to Dmitry:
+
+* I understand your concern of being able to develop independently, 
+committing changes when ready for comment/review (*so long as the 
+development history is clear; which is easy to do with separating big 
+changes into many commits, before pushing*).
+