On Sun, 11 Feb 2018 10:32:57 +0000, Damyan Ivanov wrote: > > > * E-mail notifications > > > - It's working: https://wiki.debian.org/Salsa/Doc#Email_notifications > > > + using list address or dispatch@tracker.debian.org (do we use that > > > currently ?) > > > + it needs to be enable on each project where we want it > > > > Also set by `dpt salsa configurerepo', to > > pkg-perl-cvs-commits@lists.alioth.debian.org. > > dam wanted to run a survey on the list if it's still needed; if not > > we can remove this part from dpt-salsa. > I have mailed pkg-perl-cvs-commit@alioth.d.o two weeks ago. No replies > so far. Ok. > I.O.W. I think pkg-perl-cvs-commits can be considered as retired and > of no concern for the migration. Ack. Removed from dpt-salsa. > > > * Accounts > > > - contact current project members? just the mailing list ? > > > + each member needs to create their own account and ask to join the team > > Needs to be done. > > Join requests are turned off after previous discussions, the web > > interface points to the list. > > We might also consider adding people who have been active in the last > > year? > scripts/committer-stats tells me there are 52 contributors with > commits from the past year. Sounds about right :) > > Adding works via the web interface obviuosly, or via `dpt salsa > > adduser'. > The paranoid me prefers adding by request, but perhaps mass-adding > last year's contributors is the way to go. It would be easier for > contributors and admins, and the yearly activity-ping nicely takes > care of the seemingly inactive contributors. However we do the activity ping :) (It currently relies on alioth). I'm fine either way, pre-adding known active contributors might just save some work. > > > * repository migration > > > - do we want to transfer all repos? probably yes. What about attic/ ? > > > + there are scripts floating around > > > + probably all without subteams (but we could maybe use a non-subteam aware > > > script for the packages/ namespace) > > > + and not written in perl :) > > > + after the final transfer: a pre-receive hook on alioth in all repos > > > with exit 1 and a helpful message > > > + we might need a script which can replay the migration? > > > > I've committed a first version of `alioth2salsa' to scripts.git > > earlier today. Written in shell :) using gitlab-api-v4 and dpt-salsa. > > And not (yet) idempotent, i.e. it fails if a project already exists. Side note for for gitlab-api-v4: It needs a config: % cat ~/.gitlab-api-v4-config { "private_token" : "ABC", "url" : "https://salsa.debian.org/api/v4/" } % grep SALSA ~/.dpt.conf DPT_SALSA_PRIVATE_TOKEN=ABC With the token ("ABC") coming from https://salsa.debian.org/profile/personal_access_tokens > Further ideas (that I'd like working on, but may be not immediately): > - try to use local repositories when available (after a pull) to ease > the burden on alioth (at the expense of local bandwidth) I've tried something like this (for dpt-salsa pushrepo) and noticed that this doesn't push not-locally-checkedout branches easily. So I think importing directly from Alioth is the safer way to get the exact same repo (or at least less work). > - put a "you can't work here anymore" stopper to the alioth > repository, before the migration, revert it if the migration fails Ack. > - incremental migration Hm? > - (perhaps in a separate script) mass-change the remote's address of > the local repositories. If done by alioth2salsa, that may be used > as a flag that the migration is done (for the incremental function) Right, changing the local remotes is something I also noticed elsewhere in this long list :) > > The hooks need to be set before the actual migration. > Which hooks do you mean? In my words: | > > > + after the final transfer: a pre-receive hook on alioth in all repos | > > > with exit 1 and a helpful message In your words: | > - put a "you can't work here anymore" stopper to the alioth | > repository, before the migration, revert it if the migration fails In your actions: https://deb.li/bsSd Thanks! > > > - redirect map: > > > https://salsa.debian.org/salsa/AliothRewriter > > > + mass-commit Vcs-* changes? > > > + do we really need that or is the anonscm.d.o rewriter the long term > > > solution too? > > Needs to be done at the actual migration (the rewriter). > That would still need the mass-change of Vcs-*. Ack but that's not time-critical if the rewriter is in place. > > > * .mrconfig (currently in meta.git) > > > - piggy-backs on pet data (used by split-json-info in meta.git, also compare-hashes) > > > - updated by setup-repository/remove-repository/rename-repository (in meta.git) > > > - future? > > > > That's a bit hairy. I've added `dpt salsa mrconfig' and `dpt salsa > > githashes' which (currently only output to stdout and don't write > > files but) might serve as building blocks for getting something as we > > have now with our .mrconfig and split-json-info and compare-hashes. > > > > Maybe someone has time to look into this? > > (Ideally dam as he has written the original machinery :)) > > I think we can start without the pet/hashes trickery. Maybe salsa is > quick enough to make all this obsolete. Yup, maybe this works. But then we still want some kind of dynamic .mrconfig to have a current list of repos. Maybe a template .mrconfig in meta.git, and then dpt-salsa mrconfig takes it and fills in the current list of repos? > > > * our website: website.git > > > - alexm has been working on an update with sphinx > > > - pages currently not yet enabled on salsa, should work with the sphinx version? > > > - lots of references to alioth/moszumanska > > alexm and nodens are looking into the GitLab pages / CI / ... > > thingie; thanks! > I wonder if the salsa's wiki option is suitable for our needs. Less > tricks make life simpler :) Modifications can be restricted to group > members. The cost is converting from POD to markdown. True but an additional cost is having to edit the wiki in the browser ... > > In general I think that, once the naming is clear, the website > > generation is sorted out, and alioth2salsa and dpt-salsa are > > reviewed, we could actually do the transition. The SnowCamp days (Feb > > 22nd - Feb 25th) look like a good opportunity to me? > Sure. Having the transition done in a weekend looks very nice. Cool. > Maybe having a check/task list in gobby would help to make the rush > more streamlined? (just an idea; sometimes I am over-structuring > things) I think that's a good idea, to get the steps done in the right order and have responsibilities and small jobs for people willing to help. > -- dam, > excited to see the migration so close to reality :) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Funny Van Dannen: Traum Traum
Attachment:
signature.asc
Description: Digital Signature