Hi Chris, On Saturday, 5 December 2020 01:20:07 CET Chris Knadle wrote: > I looked up the bug CCed in the email and see that the Breathe package was > marked as Orphaned via the BTS; however the package still has a listed > maintainer instead of Debian QA Group <packages@qa.debian.org>, meaning the > full orphaning of the package hasn't been completed yet. More explanation > here: > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphani > ng-a-package > > At the moment all this means is that the Breathe package in Debian will have > no official maintainer -- it doesn't necessarily mean that the package will > be removed from the archive soon. Package removals happen sometimes for > packages that go out of maintenance for an extended period, but this > package was only _just_ been (partially) orphaned, so as far as I know, the > situation is not "alarming". Breathe has now joined 1175 other packages > that have been orphaned -- you can see a list of them here, many of which > have been orphaned for several years: > > https://www.debian.org/devel/wnpp/orphaned Thanks for the explanation and references, much appreciated! > In terms of the Breathe package itself, I'm unfamiliar with it... and to > date I've never used Doxygen or Sphinx, I'm not (yet) familiar with > reStructuredText, and at the moment I'm only doing sporadic Python3 > programming. Debian Developers are encouraged to be familiar with the > packages that they upload or in sponsoring for uploads in case there are > bugs in the package that require familiarity to fix. I'm probably not the > right maintainer to sponsor uploads directly, but I /am/ interested in > helping guide you through the process of getting you what you need to take > care of the package. I'd likely be comfortable helping do NMUs > (non-maintainer uploads) for targeted bug fixes, and I would also be > comfortable helping with preparing and/or reviewing package uploads to > mentors.debian.net to help get a sponsor for uploads. > > https://mentors.debian.net/sponsors/ > > And assuming you'd like to take over for maintenance of the breathe Debian > package yourself and have sponsored uploads, the next step for that would be > to file an "ITA" (Intent To Adopt) bug, I believe. It seems you've got some > Debian package development experience already, so this seems quite fitting. > There's some additional explanation of the "ITA:" bug subject here: > > https://wiki.debian.org/how-can-i-help Yeah I'd say going for ITA makes most sense here so that's what I would like to do. Reading around a bit I find WNPP wiki page[1], the "ITA" entry of the "Removing entries" seems appropriate. However not being an Debian maintainer currently it seems inappropriate for me to actually do this. [1] https://www.debian.org/devel/wnpp/ The mentor system also seems to have some overlap with GitLab's merge requests. I know Salsa is relatively new in Debian and am guessing it's mostly a maintainer preference which tooling and flow to use. So far I am most comfortable with the gbp tooling, as it nicely integrates with a git-based workflow which I'm used to. I am used to working with GitLab and prefer direct merge requests as the ability to iterate with inline diffs with explicit thread resolution is a very nice review process in my opinion. Typically in a situation where a non-privileged user is contributing (that would be me) I would either fork the project and submit merge requests to upstream. Somewhat more comfortable is being granted developer permissions[2] on the project and then protecting[3] the primary branches so that only a maintainer can push/merge to those. [2] https://docs.gitlab.com/ee/user/permissions.html [3] https://docs.gitlab.com/ee/user/project/protected_branches.html Currently the Breathe repository is under Sebastian's namespace[4]. For the above workflow to work the repository would ideally be owned by the actual uploader/sponsor or possibly the python team[5]? That way it is ensured that the main branches contain finalised and reviewed work. [4] https://salsa.debian.org/sramacher/breathe [5] https://salsa.debian.org/python-team/packages Mostly just writing some ideas down above, hopefully it is somewhat relevant. Perhaps a starting point would be to fork the project inside my personal namespace on Salsa and create a merge request internally there for reviewing? > Strangely I don't see the "ITA:" bug explained in the Debian Developer's > Reference guide under "Adopting a package", which I would like to see > updated for that. > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adoptin > g-a-package Indeed somewhat inconsistent. I also found a reference to a WNPP page[6] that seems to be intended as a redirect to devel/wnpp but also provides some information, but here too ITA is missing. [6] https://wiki.debian.org/WNPP > mel.vin Debian repo > =-=-=-=-=-=-=-=-=-= > > I had a quick look at your Debian repository at the [2] link from your email > and wonder how the package list is being updated -- if the package list > being automatically generated I would be interested in knowing how to do > that. Indeed it is being automatically updated with a little shell script[7]. The other scripts and some documentation is part of the same project[8]. Do note though I am currently reworking some of the repository on an internal GitLab instance as part of the migration to vermware, this will be push-mirrored to gitlab.com and probably Salsa once it's done. Mostly further automation and minor polish, the overall system will stay the same. (The goal is that once a git package tag is pushed CICD automatically builds the package for multiple architectures and also uploads the resulting package to the repository.) [7] https://gitlab.mel.vin/debian/repo/-/blob/master/rsync.sh [8] https://gitlab.mel.vin/debian/repo > The other thing I noticed in the list of packages is that there's a mumble > backport package. The maintainer for the Mumble backport in Debian hasn't > done an upload for 2 years, so if you'd be interested in seeing your > backport uploaded to Debian backports directly, that would be something I'd > be interested in talking about. I would very much like to help with that! Could you create a new branch buster-backports or similar in the Salsa repository for mumble[9] based upon the current release in testing? There are a million ways to do this, such as the following CLI snippet or on GitLab directly[10]. $ git checkout -b buster-backports debian/1.3.2-1 $ git push ... [9] https://salsa.debian.org/pkg-voip-team/mumble [10] https://salsa.debian.org/pkg-voip-team/mumble/-/branches/new After that I'll update my backport for 1.3.2-1 and verify proper operation and building in a personal fork. After that I can create a merge request to the official Salsa mumble repository targeting the buster-backports branch, which will result in a proper single project for all the official mumble packaging. (I was having some doubts about the writing style and information sharing of the above paragraphs. Trying to not assume things about workflow familiarity and be clear, hopefully it doesn't end up looking pretentious.) Here too though post-merge post-git-tag it is time to upload to the Debian archives, which is something I am clueless about. Possibly you are the official maintainer in the debian/changelog and do the actual uploading, and I do the [Melvin Vermeeren] thing for the backport-specific changelog part? Cheers, -- Melvin Vermeeren Systems engineer
Attachment:
signature.asc
Description: This is a digitally signed message part.