The idea I had/have is to do the conversion and place them in a separate namespace/group, ready to be picked up by a prospective maintainer.
I've now created a group for that on Salsa under which the converted repos can
be stored: https://salsa.debian.org/groups/alioth-to-salsa-migration-team (*)
That way a prospective maintainer can use that as *a* source, but can also use
other sources like f.e. "gbp import-dscs" to create/rewrite a/the proper (git)
history to their liking for the to be adopted package before it gets placed in
the 'normal' Salsa structure.
This is all fine and dandy, but one matter that doesn't seem to be
mentioned in anything I've read is how/if you are going to match the SVN usernames with proper git-ready authorship information (i.e. email addresses).
- 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?
* lintian-brush has a mapping of team names to locations in salsa,
here: https://salsa.debian.org/jelmer/lintian-brush/-/blob/master/lintian_brush/ salsa.py
Did you prepare such matching list? Like, I have a 111 lines authors
file that I used in the past for some conversions I did (coming from the debian-med team, fwiw), but I'm sure that if you are going to properly convert collab-maint you'll need quite a longer list.
- 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?
On Friday, 27 January 2023 20:14:43 CEST Jelmer Vernooij wrote:
* lintian-brush has a mapping of team names to locations in salsa,
here: https://salsa.debian.org/jelmer/lintian-brush/-/blob/master/lintian_brush/ salsa.py
While I haven't made such a list yet, it surely was considered.
As for the how, that'll likely be a manual task in which I will try to construct such a mapping file by (a lot of) searching.
Did you prepare such matching list? Like, I have a 111 lines authors
file that I used in the past for some conversions I did (coming from the debian-med team, fwiw), but I'm sure that if you are going to properly convert collab-maint you'll need quite a longer list.
One of the reasons for posting about this is the hope that someone else who may have experience with a SVN-to-Git migration would share their experiences,
tools and other things that could benefit such a migration, like f.e. an authors list. So if you could share that, that would be most welcome :-)
I think the git repositories should just be created directly under
debian/. There's no reason not to, it makes it easier to find them
(not everybody will know about the alioth-to-salsa-migration-team),
and removes the need to create a separate group and to fork them to
debian/ later. There's not much controversial there - it's just pure
git to git.
On the subversion migrations, the hardest part is in dealing
with the differences in habits between svn-buildpackage and git-buildpackage (or whatever you're expecting people to use). You'll need
to convert svn-buildpackage settings to e.g. git-buildpackage somehow, and e.g. potentially weave in the upstream sources
(lots of packages in svn ship just debian/ whereas in git it's common
to include the upstream source). If you don't do that, then
it's probably better to not do a conversion from svn at all, but e.g.
do a straight import from the archive (e.g. based on the dgit
repository).
Hi,
On Friday, 27 January 2023 20:14:43 CEST Jelmer Vernooij wrote:
I've been looking at how to do a mass conversion. There's about 375 packages
still listed as being on alioth (~100 in SVN, ~267 in Git, the rest in something else). https://janitor.debian.net/cupboard/result-codes/hosted-on-alioth?campaign=u
nchanged&include_transient=off&include_historical=off
That page now returns 747 packages?
What still needs to happen is:
* The mapping still needs to be tied together with the import script, to
generate correct URLs to push to and set the Vcs-* headers
appropriately
I'm not sure what to do with packages whether the owning user or team
is not on salsa. Add them to the "debian" group?
* The import script supports just git right now, not svn. There's ~8
repositories in a VCS other than SVN or Git, which we could just
migrate manually.
After sufficient procrastination I started working on this again ;-)
The idea I had/have is to do the conversion and place them in a separate namespace/group, ready to be picked up by a prospective maintainer.
I've now created a group for that on Salsa under which the converted repos can
be stored: https://salsa.debian.org/groups/alioth-to-salsa-migration-team (*)
That way a prospective maintainer can use that as *a* source, but can also use
other sources like f.e. "gbp import-dscs" to create/rewrite a/the proper (git)
history to their liking for the to be adopted package before it gets placed in
the 'normal' Salsa structure.
There's also a practical reason (for me) as f.e. the id3lib repo is stored under `collab-maint/deb-maint/id3lib` and having a group on Salsa allows me to
create subgroups and subsubgroups under which to store the git repo(s).
I'm open to suggestions how to structure the converted repos and possible (git) repos created to support this mass migration.
I have attached the document I've written thus far wrt Subversion, but that really needs to be put under version control and possibly/likely split up (and
linked from a README.md document?).
*) I've also added/invited Jelmer to that group as Owner, possibly for practical reasons, certainly for the bus-factor reason.
On Wednesday, 12 April 2023 18:45:31 CEST Jelmer Vernooij wrote:
I think the git repositories should just be created directly under
debian/. There's no reason not to, it makes it easier to find them
(not everybody will know about the alioth-to-salsa-migration-team),
and removes the need to create a separate group and to fork them to
debian/ later. There's not much controversial there - it's just pure
git to git.
If debian/control points to the alioth-to-salsa-migration-team repo, it shouldn't be hard to find.
On the subversion migrations, the hardest part is in dealing
with the differences in habits between svn-buildpackage and git-buildpackage
(or whatever you're expecting people to use). You'll need
to convert svn-buildpackage settings to e.g. git-buildpackage somehow, and e.g. potentially weave in the upstream sources
(lots of packages in svn ship just debian/ whereas in git it's common
to include the upstream source). If you don't do that, then
it's probably better to not do a conversion from svn at all, but e.g.
do a straight import from the archive (e.g. based on the dgit
repository).
Then it's better to abort the migration attempt at all and do a straight import from the archive.
I wanted to convert id3lib to git and then use that to *learn* packaging with git-buildpackage (and related stuff). But if I first have to learn that and also
svn-buildpackage, which I really don't want, then it's kind of pointless for me. It would also increase the amount of work 10 or 100 fold?
And I have no idea how I would _assume_ how other people would use it as I know virtually nothing about (git) packaging myself.
The idea I had with the a-t-s-m-t repos is that I would not (have to) assume anything about how a prospective maintainer would want to do their packaging, but leave that choice entirely up to them. That's why I wanted to leave open the option of them being able to rewrite the git history to suit their needs and before the repo would be moved to f.e. the debian/ namespace.
All they would get is the old SVN repo, but converted to git.
On Tue, May 02, 2023 at 07:37:00PM +0200, Diederik de Haas wrote:
Hi Jelmer,
My email program ate the contents of the email including the attachment. This is the private email Mattia send us. Could you forward it to me?
Here it is:
Another possibly nice authors-file could be the one that was used in the DPMT/PAPT migration. Stefano Rivera <stefanor@debian.org> took care of
the PAPT one, so maybe email him to see if he has a compiled list of authors?
If you do, could you possibly share with me the final result?
Thank you!
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 87:47:55 |
| Calls: | 6,697 |
| Calls today: | 2 |
| Files: | 12,232 |
| Messages: | 5,348,232 |