Melvin Vermeeren:
Hi Chris, On Saturday, 5 December 2020 01:20:07 CET Chris Knadle wrote:
[...]
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-helpYeah 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/
In the WNPP page [1] above the suggestion is to rename the "O:" bug with "ITA:" and set ownership of the bug to yourself in order to start the process.
In terms of not being a Debian Maintainer ... no, that isn't required. I know because I did this myself in 2014 for Mumble when its maintainer neglected it and then did not respond to communication about the package being broken:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739997I filed to become a Debian Maintainer in 2015 after taking care of a couple of packages in Debian for a while. That's the typical path to becoming a Debian Maintainer (and eventually Developer) today -- so it's expected to start off with taking care of one or more packages without being a DM first.
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.
As far as I'm aware Git-Buildpackage is what is still most often recommended. There are some further details like whether or not to use dgit. I wanted to try dgit but didn't like the way it worked with patches, because I like my patches to contain comment headers for what the patch is for, and last I spoke to DDs about it this was something that dgit conflicted with. The basic idea with dgit is that everything is a direct commit, so there wouldn't be any use of quilt for patch creation. There's also some new 'git' package format that I haven't investigated much. (I'm still most comfortable with the '3.0 quilt' format.)
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?
A project on Salsa is usually made available on request; so if you wanted the project to exist under the python-team/ area then it makes sense to join that team and then request creation of the project in order to have a Git repo location for the package. That way the package can be team maintained rather than it being under a personal area.
Although it's nice to have an online Git repo available for a package, it's also not a requirement. For instance I typically do an upload to Debian and /then/ push to the repo, so that if I have to back out changes in my local repo that it won't mess up the online repo. To start with when taking over a package I'll usually do the first upload with no listed Git: location in the debian/control file. Then usually I find a Git repo location to store the package repo, push, then update the Git: location in the debian/control file on the next upload. All of the work is done in Git-Buildpackage and made available later, it's just not available for the first upload. That's at least the path I've used so far ... having an online Git repo immediately for the first upload would be nice, but so far I've found that to be easier to work out later after there's repo changes to store rather than before there is.
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-packageIndeed 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
Weird. Okay.
mel.vin Debian repo =-=-=-=-=-=-=-=-=-=
[...]I'll email you directly concerning the rest as the rest doesn't pertain to the breathe package.
-- Chris -- Chris Knadle Chris.Knadle@coredump.us
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature