From: Andrey Miroshnikov Date: Mon, 15 Jan 2024 18:52:55 +0000 (+0000) Subject: sync_up: Discussion page for tomorrow's meeting X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=aca4531c8bd000104e6d71ba1fff82dbe6cb1b18;p=libreriscv.git 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 index 000000000..e0d071853 --- /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*). +