Il 03/08/2024 15:59, Jonas Smedegaard ha scritto:
annoyance maintainers for update it on many package, with a url that point to an external file can be update once for even on tens, hundreds or more packages it could be set onQuoting Fabio Fantoni (2024-08-03 15:39:00)Il 03/08/2024 14:40, Kentaro Hayashi ha scritto:Hi,Even though +1 for DEP-18 basically, I think that it might be better to add an option to formalize package owner's (single person maintainer) collaboration policy especially about non-team maintained packages under https://salsa.debian.org/debian/. If such a package repository enables merge request feature, then I will send merge request and send E-mail to bugs.d.o about url of the MR to notify it. But it is not true that such MR is merged in timely manner. (Surely collaboration takes longer time, I know.) If the package owner expresses a collaboration policy in advance, it can improve such a situation in a particular case and we can respect it. NOTE: The following idea might be out-of-scope in DEP-18, but specific use-case to improve collaboration in Debian, IMHO. Here is just an idea: put collaboration policy metadata in debian/control. (The following idea assumes that non-maintainer DD tend to hesitate to commit/merge it) * Collaboration-Policy: debian/CONTRIBUTION.md Yes, we have README.source already, but it might be better to note in a separate file about collaboration. * Collaboration-Policy-Commit: yes It declares that the package owner encourages non-maintainer DD to commit directly without merge request. * Collaboration-Policy-Merge: yes It declares that the package owner encourages non-maintainer DD to allow merge requests. (DD has maintainer right in salsa.d.o by default as you know, but you can merge without worry if there is it.) * Collaboration-Policy-LowThresholdNmu: yes It declares that LowThresholdNmu rule [1] is applied. * Collabollation-Policy-NMU-Delay: 15 It declares that NMU delay the package owner wants. [1] https://wiki.debian.org/LowThresholdNmu Pros: * DD/DM and contributors can respect the package owner's intent about the package collaboration. * Reduce a chance to cause inconsistency between the content of each package repository on salsa.d.o and NMU'ed package source. * Because other DD (non package owner) can commit/merge, then ship NMU package. Cons: * Maintainers will be bothered to add that new field to every package (If there is no Collaboration-Policy, it is safe that sending merge request and let it the package manager, thus nothing changed) * No mechanism to enforce Collaboration-Policy-Commit: no or Collaboration-Policy-Merge: no policy because DD has maintainer rights on salsa.d.o and can commit/merge it in reality. It might worry too much, but it might be able to block an unfortunate accident, a so-called package hijack with incomplete communication in some cases.Hi, this I think is can be useful (beyond the example use of salsa/debian packages which is not necessary as replied by Tobias Frost), I think will be better with only one additional (and optional) field in d/control, like Collaboration-Policy that point a file or url, this I think that can decrease the possible annoyance and in the case of teams or even single maintainers having a single policy file to point to and update in a simpler and faster way (especially if there were the same policies for dozens of packages or more, there could be also hundreds or thousands)What annoyance are you referring to?
not only new but also any contributors that want to contribute on other package, also about that I tried to explain something in one of my previous mailAre some new contributors annoyed by the lack of formalized rules for collaboration?
Are some maintainers annoyed by how some new contributors initiate collaborative contributions?
I don't know how likely it is, I hope it's very rare
As a maintainer, I can imagine getting annoyed by *non-collaborative* contributions done in ways that I feel leaves an extra burden on me. One description for that is "drive-by contributions", meaning that someone contributes without having the time to *collaborate* on it, to align the contribution with how the package is maintained. But since this whole thread is about "true open collaboration", I assume that you are talking about *collaborative* work, and then I cannot recognize what is the kind of annoyance you are referring to.
There is a lot of other information that may vary on how to contribute in certain packages or teams beyond what is already listed, here only some example:
Debian Python Team - https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
Java team - https://www.debian.org/doc/packaging-manuals/java-policy/ Rust team - https://wiki.debian.org/Teams/RustPackaging go team - https://go-team.pages.debian.net/packaging.html
Kind regards, - Jonas
OpenPGP_signature.asc
Description: OpenPGP digital signature
