Il 03/08/2024 15:16, Jonas Smedegaard ha scritto:
Quoting Kentaro Hayashi (2024-08-03 14:40:51)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.What is the core purpose of adding these suggested new metadata fields? An NMU is non-collaborative - it is a non-maintainer that not only offers a contribution but bypasses maintainers and issues a release with the contribution integrated. It makes sense for me that we have ways for maintainers to communicate ahead of time, how NMUs are acceptable, because NMUs lack collaboration. I was under the impression that collaboration was, well, collaborative. That it was about collaboration between contributors and maintainers. Am I mistaken, and it is instead about collaboration between contributors and non-maintainer mentors, which potentially ends in an NMU? If not - if it is collaboration with maintainers - then I don't understand the need for signalling ahead of time how maintainers prefer to work, as contributors can simply ask the maintainer.
there is a purpose and that is what I was trying to explain in a part of one of my emails: to have certain information on how to contribute in a simple and fast way, without having to write emails to which you might never receive a reply, or after days or even weeks
so you can instead immediately proceed to contribute in the preferred methods indicated and even if there is no response
less emails to answer from maintainers and instead spend that time analyzing the contributions received (maybe more likely as he or his team prefers)
more chance of contributions, rather than maybe sending an email to the maintainer, waiting and since he doesn't respond you think it's useless to contribute there and you avoid it (in some packages where I wanted to contribute occasionally I ended up doing that). once there are contributions there is a greater chance that they will be made NMU by DD (especially if RC), if already mostly ready, more chance that they will be used by other DD in case of team packages, or possibly by contributors trying to save an abandoned package, and these are some examples that come to mind
- Jonas
OpenPGP_signature.asc
Description: OpenPGP digital signature
