Quoting Fabio Fantoni (2024-08-03 16:45:24) > Il 03/08/2024 15:59, Jonas Smedegaard ha scritto: > > Quoting 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? > 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 on > > > > Are some new contributors annoyed by the lack of formalized rules for > > collaboration? > 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 mail > > > > 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
My understanding now, about the purpose of the suggested set of metadata fields, is that it is to reduce annoyance for contributors: Be able to read how a maintainer prefer to collaborate without needing to ask, because asking involves waiting for the maintainer to respond. I hope I understood that correctly - otherwise please do correct me. Thank you for clarifying. - 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
