meetings/sync_up/discussion/sync_up_2024-01-16_discussion.mdwn

   1 # Discussion of commit frequency - Tuesday 16th January 17:00 UTC
   2
   3 * Link to sync-up meeting:
   4
   5 Discussion of commit frequency and other points mentioned in
   6 [this](https://lists.libre-soc.org/pipermail/libre-soc-dev/2024-January/005912.html)
   7 email thread. After meeting discussion, points agreed upon will be documented
   8 in the wiki.
   9
  10 ## Points to be discussed
  11
  12 Dmitry's main point of concern:
  13
  14 * As a developer, I should have a liberty to interactively rebase, fixup,
  15 squash commits, commit when I can and want, and same for push. If there are
  16 restrictions on this from NLnet side, these must be explicitly published on
  17 their own guidelines. I'm sure they have different forms than the ones
  18 exposed.
  19
  20 Jacob's response:
  21
  22 * Assuming you're not working directly on the master branch, I think it
  23 should be sufficient to push a WIP commit with whatever changes have been
  24 made by the end of the day, that can be rebased, squashed, amended, etc.
  25 next time you work on it. (if you're working on master, please don't
  26 rebase/squash/amend any commits, use a separate branch if you want that,
  27 then push to master once the commits won't change anymore)
  28
  29 * It would also be useful but not required to push your current code if
  30 you're posting major results or asking questions, so others can see your
  31 code -- after all it's really hard to spot bugs in code you can't see!
  32
  33 * I don't think there are any NLNet restrictions other than that code needs
  34 to be public before submitting RFPs.
  35
  36 Luke's responses:
  37
  38 The "regular commit push" approach imitates corporate backup systems:
  39
  40 ```
  41 if you were working for a Corporation (and they were any good)
  42 your private machine would be backed up by the IT Staff,
  43 onto redundant servers, every day, without fail, so that there
  44 is abolutely no chance work could be lost.
  45
  46 it would not be your problem, because the Corporation IT Staff
  47 set up your machine, give it to you with backup software
  48 pre-installed, it s basically not your problem, and you would
  49 not be "wasting your time" on backups.
  50
  51 the FOSS equivalent of that is that you push, again, without
  52 fail, to a public repository, but this is of course taking
  53 up *your* time to do it. this is unfortunate but necessary,
  54 as we obviously cannot invade your privacy of *your* personal
  55 local machine to forcibly push to Libre-SOC servers to ensure
  56 backups and Transparency!
  57 ```
  58
  59 Luke ensures there are at least 3 backups of the LibreSOC project:
  60
  61 ```
  62 i have TWO remote machines doing daily backups of the server
  63 and i want it increased to 3. i also do a 3rd intermittent
  64 server backup (manual rsync) because being on a Mobile Internet
  65 it costs me USD 3 per Gigabyte, i only do that if absolutely
  66 critical.
  67
  68 so that is 3 backups and i really want it to be 4.
  69
  70 then also there is salsa and other servers and all developers also have
  71 clones of the repos, but they are intermittent and
  72 cannot be relied on, plus cannot back up the full server itself,
  73 just the repos.
  74 ```
  75
  76 Luke's point whether Nlnet requires such restrictive measures
  77 (answer to Jacob's point):
  78
  79 ```
  80 yes you are correct, but the backgground/context is that it
  81 is far stronger than that with very serious implications.
  82
  83 their mandate is "Works for the Public Good".
  84 if it's not public, then they would be in flagrant
  85 direct violation of Dutch Foundation Law to give money
  86 out for private work, which no messing about
  87 is jail time for the Directors.
  88 ```
  89
  90 Luke also asked Dmitry why is it an issue to follow the approach
  91 of committing and pushing frequently.
  92
  93 One of the reasons perhaps could be slow or low-bandwidth
  94 internet, but given the low overhead of git pulls/pushes, this
  95 isn't an issue in practice.
  96
  97 The point to perform regular git commits is documented in
  98 [[HDL_workflow]] (documents LibreSOC standard procedures),
  99 in the "git" section.
 100
 101 Luke mentions that if an argument exists for not following the
 102 procedure, it needs to be mentioned:
 103
 104 ```
 105 if you can provide an explanation as to why you consider it
 106 reasonable to not follow the Project Standard Procedures
 107 as outlined in the HDL Workflow page, then we have a
 108 justification to put in front of NLnet and the EU Auditors,
 109 and everything is fine.
 110
 111 this is basic ISO 9001 QA Procedure, which I trained in back in
 112 1993. the "red flag fail" is not when you don't document
 113 something, it's when you say you are going to follow a certain
 114 procedure / practice *and then do not follow it*.
 115
 116 it is documented in HDL Workflow *all* commits shall be pushed,
 117 and you are requesting, Dmitry, not to follow that Procedure.
 118 you therefore explicitly need to explain clearly (and publicly),
 119 no fuss, and there is no criticism here expressed *or implied*:
 120 why you are not going to follow that Documented Procedure, ok?
 121 ```
 122
 123 *(Andrey: I didn't see HDL_workflow say
 124 "all commits shall be pushed". It makes sense given that Nlnet
 125 only pays for published work, but perhaps this needs to be
 126 written explicitly?)*
 127
 128 Luke also made a point that
 129 there may be exceptions due to privacy/security concerns, but
 130 those must be discussed outside of LibreSOC public sytems:
 131
 132 ```
 133 if there is a privacy or security reason
 134 that you cannot reveal publicly, then NLnet will be perfectly
 135 understanding of that as well, but the discussion there
 136 has to move *offline* and not take place on Libre-SOC public
 137 servers. it is one of the *only* exceptions to the rule
 138 "everything is public". NLnet do actually fund some very
 139 senstive projects, where anonymity of the developers is
 140 absolute top priority... *but* the work still has to be
 141 public, to fulfil "Works for the Public Good" Mandate.
 142 ```
 143
 144 Also a point on Nlnet:
 145
 146 ```
 147 as Jacob points out, you absolutely cannot
 148 get paid for private work, as this directly conflicts with
 149 NLnet's "Works for the Public Good" mandate.
 150 ```
 151
 152 Point made by Andrey to Dmitry:
 153
 154 * I understand your concern of being able to develop independently,
 155 committing changes when ready for comment/review (*so long as the
 156 development history is clear; which is easy to do with separating big
 157 changes into many commits, before pushing*).
 158