Quoting Paul Gevers (2024-05-19 10:05:38) > In this discussion about mandating things, I've been wondering.... > > On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote: > > * mandate VCS-tracking > > * Yes > > * mandate the use of one specific VCS > > * Yes: git > > What do people think this should mean, a *should* or *must* in policy? > That the package has a RC bug if the packaging isn't tracked in git? And > if the packaging is in git but I forgot to push my latest changes to the > documented git server (this happens regularly to me as I do most uploads > with dgit)? RC? In all suites where the packaging version isn't pushed > for? And how about NMU's? (I just checked a random package without git: > aspell-am, last non-NMU upload was in 2013)? > > If *must* and thus RC, can the issue be fixed by "NMU"? I.e. if the > person that did the changes, (and has nice local commits) somehow isn't > available, will the package (if not key) be auto-removed? Or can > everybody fix the repo? What if you don't have write access to the > existing repo? And then what if the uploader comes back and tries to > push the real history? What if my harddisk with local changes crashes > before I push (again, I forget that sometimes, but for me luckily dgit > will mostly have the commits). > > Or is this "just a bug", maybe even at level important, but no other > consequences. Than I think this discussion is going to be moot. I don't > think there's much forcing possible and I think most already agree that > stuff *should* be in VCS, so this isn't going to change for those in > favor. And does it really add enough value if those that are forced are > just going to do "gbp import-dsc" for each upload to the archive on a > ./debian only repository? Because that (or better) we could already > automate (see also my PS). With "mandate" I do not mean kick out if non-compliant. Same as we (as far as I am aware) mandate declaring Poilcy version followed by a package, but don't kick out packages having mismatching declaration or not following latest policy. I think there is a big difference between saying that Salsa (or git, og Debbugs, or public-wide WNPP work tracking) is an optional addon to Debian, to saying that it is expected of everyone (i.e. you are being asocial if you don't, and can expect your behavior being discussed as a public-wide issue for the project). So I disagree that tool-use severity of "important" makes progress moot. I have met developers who have the view that we are already at the point of non-use of Salsa being asocial behavior, and had at least one very interested (and calm) exchange of such differing views at Debconf in Kosovo. Deciding project-wide where we are on that scale do help, I think. > PS: I've always wondered if the dgit server shouldn't track history, > even if uploads don't happen via it. A dgit clone could (should?) > already provide available history, even if no upload happened via it yet. All the points that I listed are all about optional/expected/required *contributor* streamlining. If I understand your comment above about dgit correctly, it is about automation of history tracking, which is (mostly) orthogonal to *contributor* streamlining. - 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
Attachment:
signature.asc
Description: signature