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

[Luke Kenneth Casson Leighton]

On Wednesday, January 10, 2024, Jacob Lifshay <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