Hello,
I see several problems with the proposal.
In general I think it seems to assume that there are way more contributors
than there are in reality.
Then it makes no effort to define communication channels. Before making some
time consuming change, it's usually better to just ask if that's a good idea
or not. Not doing so means that the person proposing the change will
inevitably have a bad feeling if it gets rejected. Which can be avoided by
communicating in advance.
It seems that the idea for packages that violate this is to open bug reports.
This would be very noisy and not very useful in my opinion, especially since
in several cases there would be no way to fix the bug.
> anybody reading the source code can easily view everyindividual change and
> to review when and how a specific line of code was changed, and reason about
> why it was changed.
Then the document should enforce a particular commit style. I've seen several
people who do a bunch of unrelated changes in a single commit.
I've had a boss (who worked at amazon before) who was imposing to use a single
commit per ticket.
> the package should at least be mirrored on Salsa for the sake of
> facilitating collaboration
How would that facilitate collaboration, if whatever happens on the salsa
mirror is invisible to the real contributors on the real place where
development happens?
> Run Salsa CI at least once before every upload to ensure minimal level of
> quality
Can you tell me how to do a CI for python3-motor, given that it's a client for
a proprietary database?
Testing GUI packages, or fonts packages, or clients is generally very difficult
if not impossible. What's the plan in those cases?
I presume writing a "return true" CI is not what we are trying to do here.
> While collaboration can happen based purely on developers submitting patch
> files as email attachments directly to each other, to mailing lists or in bug
> reports, it does not scale well.
It scales better than having to open salsa, find out the git:// url, add a new
remote in the local git, diff the patch locally, then of course I can't just
merge the patch locally because salsa doesn't know about that, so I have to go
again on salsa and click to merge.
All of this with salsa being not fast nor responsive by any definition of those
terms.
> nor even that they must spend time doing code reviews
So it must be possible to send merge requests, but it's ok to completely
ignore all of them. This doesn't seem very ideal to me.
> Allow changes to be reviewed before uploads to Debian
I guess this means that we should have some mandatory waiting time from the
last commit to the upload. How long would this time be? Would it apply even if
we're talking about fixing a libc upload that will break any system where it
gets installed?
Best
--
Salvo Tomaselli
"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei
https://ltworf.codeberg.page/Attachment:
signature.asc
Description: This is a digitally signed message part.