Hi! > > I published a complete rewrite of the earlier draft as: > > > > https://salsa.debian.org/dep-team/deps/-/merge_requests/12 > > DEP-18: Encourage Continuous Integration and Merge Request > > based Collaboration for Debian packages > > > > If you are in favor of having this as a DRAFT in the DEP directory, > > please give it a thumbs up. > > I think it's falling between two stools: are you giving project > improvement ideas or a personal view of how to package (which seems very > perscriptive and im afraid not clearly argued)? > > I think the you could edit it to something much shorter > that said: > > - all packages should be available in git via salsa.debian.org > - salsa CI should be enabled > - (sensible) merge requests on salsa should be accepted > > this first doesnt preclude people having other workflows as well, but > the 3rd ensures people can take advantage of modern approaches
Thanks for reading DEP-18. I am trying to help Debian here by accelerating the convergence on common practices to make it easier for people to collaborate using Salsa. These are not personal views, but based on the analysis of all team policies in Debian and from collecting stats from Debian packages, using for example data points that 13573 packages in Debian have explicitly a debian/gbp.conf file already. The previous version also had more background info, but I was told that it does not fit a DEP text, which I agree so I rewrote the whole thing. I am trying to think if I should expand the Q&A section, or perhaps publish elsewhere more docs / stories on how collaborative maintenance using Salsa currently looks like in many teams/packages.. Thanks for the viewpoints and the input that further argumentation is needed. In the previous version (https://salsa.debian.org/dep-team/deps/-/merge_requests/8, raw file at https://salsa.debian.org/dep-team/deps/-/blob/f9ba136130ab02b9715d863aea948a604c278bff/web/deps/dep18.mdwn) the suggestions were more high-level and in principle. The feedback was that a DEP needs to be more prescriptive, thus in the rewrite I among others added git-buildpackage, as that way maintainers will automatically get the ability to easily gbp clone/build/commit/push/merge etc the packaging code. This recommendation is based on what most maintainers and teams already use, and thus I don't think it is unreasonable. Anyway a DEP is not a policy, and with the new title, this DEP only applies for a subset of Debian packages and does not mandate that all packages should be on salsa.debian.org, as in the previous feedback round many voiced that they don't want to use Salsa.