Richard Laager <rlaa...@wiktel.com> writes: > This all looks very good. > > Presumably the repository / Salsa project name should match the source > package name? If so, that might be good to note, at least as the > default. >
I'm curious what other people think about this point, because it could cause a lot of churn either in source package renames or salsa project renames and uploads to fix VCS links. > I'd love to see more information about a recommended branch > structure. FWIW, I've been using branches named for each release > (e.g. "sid" is the default, but I also have "buster" for a (proposed) > stable update, will likely soon have "buster-backports"). This works > really well, and also scales to also having branches for Ubuntu > (e.g. I have "bionic" and "cosmic" too due to some SRUs). It also > keeps "master" available for the upstream master branch. This seems so > obvious and wonderful to me, but I'm not sure how popular it is. > https://dep-team.pages.debian.net/deps/dep14 It sounds like you're already using something similar :-) [1] One modification to DEP14 that I'd like to see is a requirement to set the Debian development branch as the default branch on Salsa, so that a debcheckout will put the user in the right place to get work done. Eg: "debian/next", "debian/sid", "debian/devel", etc. This also makes it easier for new contributors to submit MRs based on the correct branch. [snip] > If this message is threaded wrong, my apologies. While I am now, I was > not subscribed to debian-devel at the time. I have tried to set > In-Reply-To directly, but this is my first attempt at doing so. In > these situations, I would normally download the mbox archive, import > it, and reply to the message that way, but mbox archives are seemingly > unavailable (at least to non-DDs?) for Debian lists. > I didn't notice a threading problem; however your email had long lines that I had to manually reflow. wf...@debian.org writes: > Sam Hartman <lea...@debian.org> writes: > >> General Recommendation >> ====================== >> [...] >> You should document the branch format (such as patches unapplied (gbp >> pq)) that your repository uses. Best practice for documenting this is >> still evolving. The best current option is to document your branch >> format in debian/README.source. > > I'm not sure this best current option (README.source) is something I'd > actually recommend. Granted, it's annoying to have to figure the git > workflows, and a freeform documentation text like README.source helps if > you have to do it a couple of times, but it still isn't a thing you can > automate. Thus I think that the overall burden it creates outweighs its > value. Also, from the Policy: "maintainers are encouraged to document > in a debian/README.source file any source package with a particularly > complex or unintuitive source layout or build system" -- do we intend to > recommend something "particularly complex or unintuitive"? > [2] I wonder if the investigative work Ian did for tag2upload can be recuperated for the development of an extension of the source format specification. Namely, a shorthand git-project format. One would then consult the table for repos that declare a style using a shorthand key term that one isn't familiar with. "other" would need to be an option for a while. I'm not sure if it should go in L2 of "source/format" or somewhere else. > I have to admit I haven't read the full discussion. Have we got a list > of items we need to know about the "branch format"? Your text mentions > patches applied or unapplied, which dpkg-source (and, according to you, > dgit) already handles, so a utility could provide the answer if there's > at least one patch in the package; why document it then? If the > heuristic is deemed too fragile or we want to store this information > even in the absence of patches, perhaps we could invent a new (local) > dpkg-source option to override it and require using that (just an > idea). The utility would parse [2]. I'm not sure about using heuristics and suspect that the "branch format" list will need to be manually maintained. It might also benefit from codification in Policy for the following case: a decade from now someone adopts a package, but the "branch format" document/section has substantially changed since the last upload. Codification in Policy would allow the person adopting the package to reference a historical copy of Policy to more easily decipher the branch format. > Another obvious item is the main packaging branch, which is declared by > Vcs-Git ("ideally", says the Policy -- shouldn't we make this stronger?) > See [1]. I'd prefer for the general case to be solved on salsa rather than using extra Vcs-Git metadata. To get the affect of "debcheckout foo && cd foo" and be ready for work ISTM that debcheckout (and other tools) would need to parse this and switch to the correct branch. How can this approach solve the problem of getting the wrong working branch after a salsa fork and clone? eg: How to avoid raising the barrier of entry to new contributors? > If we really want to go beyond these, the next step would be discovering > the actual names of the DEP-14 entities, I guess. This would probably > start with identifying the tooling (gbp, git-debrebase, git-dpm, etc.) > then reading their configuration (if any). This would give answers for > the previous items as well. But do we target mass operations on this > scale of variability at all? > > Anyway: I think we should recommend setups which allow reliable > determination of the needed information, thus not requiring manual > textual documentation. I agree that this would be the ideal. How would one distinguish between git-debrebase, git-dpm, and manually cherry picked upstream commit? Cheers, Nicholas
signature.asc
Description: PGP signature
