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. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
