Hi! This is AFAIK my first interaction with debian-qa, so if I'm doing it incorrectly (like I should've filed a bug), please let me know. This mail will be quite long. I was looking at https://bugs.debian.org/770255 regarding "O: id3lib3.8.3" and I'll use that as an example, but I think it applies to (many?) more packages. 1) I saw some time ago that another (wnpp?) bug had an 'affects' tag and that allows the person looking at the bug to quickly go to the bug list of that affected package and from that you can then click through to it's Package Tracking System page, which provides a wealth of information regarding the package. If someone wants to potentially adopt a package, that would be the most informative starting place (IMO). I don't know if it's possible (to automate), but I think it would be a great addition to wnpp bugs if they (all) get an 'affects' tag so it would become much easier to potential contributors/adopters to get the info they'd need. And now for the big one ... 2) I've now added the 'affects' tag to bug 770255, but I had already found the tracker page for it and it has a link to another vital part (IMO) to evaluate for potential contributors/adopters: a link to the VCS repo. That is (nowadays) mostly on salsa and I think that's great. The id3lib package however has a link to a Subversion repo ... and when clicked upon it, you'll get a 404 ... I'm not new to Debian itself, but ~0 experience with packaging, so I was aware of (and had an account on) Alioth. I knew it was decommissioned, but I also assumed that there likely was some archive of it's contents 'somewhere'. Asking on #debian-mentors and 'Myon' pointed me to alioth-archive.debian.org. Awesome. The repo (section) for id3lib was in collab-maint ... which archive turned out to be 866 MB. I have a 100Mbit connection and no DL limit (afaik), so that's not an issue for me, but I think that Debian should be aware that that's not the case for everyone. See also/f.e. https://lists.debian.org/debian-kernel/2023/01/msg00372.html So now I had an archive and extracted it ... and then what? I actually used to have my own SVN repo, but that was probably 15-20 years ago, so no working knowledge. So now I need to learn about Subversion ... again and how to setup a repo and/or import the archive I had. Apparently kdesvn can view it directly on the file system, so that might help a bit. But I don't want to interact with SVN (nor learn about it again), I want to use git, so that means learning how to convert a SVN repo to git ... ideally before all the guides on the 'net return 404's too. One thing I've learned is that you should create some kind of mapping file so the SVN committers get (properly) translated to git committers. And you also need to learn about svn-to-git conversion tools scripts which seem to have their own (additional) configuration file as not every svn repo is the same. And ideally you should do that for every tool as you don't know in advance which one is better (for the repo at hand). So I'm looking at weeks(/months?) of work because I want to get the packaging history of ONE package. And all that before I can/would get to the actual 'job': learning how to package and (potentially) adopting the package. And if someone else wants to adopt another package which is not stored in salsa, they'd have to go through that whole chore again ... and again. FTR: id3lib repo is available on salsa, it's just entirely empty. I wouldn't be surprised if most people would bail out at the first 404 message. There must be a better way? - I don't know if someone has already done this migration and could share their experience/tools/etc? - If it needs to be done, isn't it way better to do a mass-migration of all the repos which haven't been converted yet? There may be a high similarity between the various SVN repos, but all the projects within one SVN repo likely share many things? Like svn-user to git-user mapping? - And then update d/control so that the PTS page links directly to the salsa repo? (- I don't know if snapshot.d.o could/should play a role in this) Would love to hear some thoughts on this. Cheers, Diederik
Attachment:
signature.asc
Description: This is a digitally signed message part.