[Libre-soc-dev] Task 980 needs an attention

[Andrey Miroshnikov]

Dmitry, apologies for taking up your valuable holiday/break time, and I 
also apologise to your family.

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/).

As LibreSOC operates by consensus, and this is not the first time this 
has been challenged, it is time we all discussed and reaffirm whether an 
hour-by-hour level of /real time reporting/ is how LibreSOC wants to 
operate. I will bring it to the next LibreSOC meeting (16th Dec 
17:00UTC) to get agreement by all how this should be handled by 
collating the important points of this email thread and including them 
as a list on the sync-up meeting page.

Both yourself Dmitry, Jacob, and Luke have made very good points in this 
thread, which we should consider and discuss.

Thanks,

Andrey

On 10/01/2024 04:00, Luke Kenneth Casson Leighton wrote:
> 
> 
> On Wednesday, January 10, 2024, Jacob Lifshay <programmerjake at gmail.com 
> <mailto:programmerjake at gmail.com>> wrote:
> 
>  > thank you for taking the time to work on this, most of us probably 
> didn't realize your christmas is in january, until you mentioned it.
> 
> none of us had any idea, Dmitry, apologies.
> 
> 
>  >>
>  >> The last thing I would like to waste my time on are such
>  >> debates.
>  >>
>  >> 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 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!
> 
> 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.
> 
>  >
>  > 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 sounds reasonable to me as well. Dmitry, what do you think?
> 
>  > 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!
> 
> pretty much! :)
> 
> yes this was what prompted the issue: 3 days ago Dmitry you
> demonstrated output from code that nobody but you had access
> to.
> 
> sorry to have to say it Dmitry but that *is* a huge no-no, interacting 
> publicly with people who cannot replicate what you
> are talking about.
> 
> if NLnet or the EU Auditor notices that, and does not then see
> that it has been resolved in a follow-up, we could get into
> trouble on an Audit.
> 
>  > That's always how I've worked (though i sometimes push more often 
> than that).
> 
> i have always done around 30 commits (and immediate pushes)
> a day. this is how i have worked for 25 years.
> 
> 
>  > I don't think there are any NLNet restrictions other than that
>  > code needs to be public before submitting RFPs.
> 
> 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.
> 
> Dutch Foundation Law is REALLY strict here.
> 
>  > Luke, does this sound sufficient?
> 
> i do not want any risks taken here.
> 
> Dmitry if you have time can you explain what the issue is?
> why is pushing all work to repositories, even just at the end
> of the day (or before talking publicly about it) an issue?
> 
> do you have a low-bandwidth internet connection, or
> a faulty one?
> 
> for example, i only have a 4G/LTE mobile broadband that is
> affected by rain, or just sometimes it is in "maintenance".
> i have to actually move location or use a backup mobile
> connection which drops back sometimes to 2G/EDGE (!!)
> 
> 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*.
> 
> *that's* the "Fail" on ISO 9001 QA.
> 
> 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?
> 
> when the explanation is available, we can point to it and
> *everything is okay* then, ok?
> 
> we went through ths before, remember? all you need to do is
> write, publicly, the justification.  no fuss, no criticism
> has been implied: just write it out, and we move on immediately,
> ok?
> 
> if you *don't* provide the simple explanation (no fuss, just
> write it out) then yes, that is indeed when we have a conflict.
> but if you just simply answer the question, there is no
> problem whatsoever, ok?
> 
> (but, the limit is: 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.)
> 
> l.
> 
> p.s. Dmitry: caveat: 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.
> 
> 
> -- 
> ---
> geometry: without it life is pointless
> the fibonacci series: easy as 1 1 2 3
>