On Mon, 22 Jan 2018 19:28:44 +0100, gregor herrmann wrote:
> At yesterday's LHF meeting, we collected and sorted the status and
> open points for the migration of our repos and surrounding helpers
> from Alioth to Salsa. -- Thanks to nodens for the initiative and for
> bringing this into some shape :)
Let's look where we are now:
> * Alioth Services replacement status update
> * Mailing lists
> - underway, should be ready before Alioth shutdown. Yay!
Should be fine, thanks to Dom and alexm.
> * IRC notification (KGB)
> - formorer runs an irker instance (active on #debian-mysql #alioth
> #debian-gnome #debian-ruby #debian-gis), see
> https://wiki.debian.org/Salsa/Doc#IRC_notifications
> - formorer has written a ruby kgb-client (which only uses relay-message
> and connects to his own server):
> https://salsa.debian.org/formorer/KGBClient
> - Tincho works on implementing webhook support in kgb-server.
> + Status ?
> - in all cases, needs to be set up on all projects
dam has addedd webhook support to kgb-bot (yay!), currently live only
on his instance; kgb.debian.net (with a CNAME to his instance) added.
Maybe there will be kgb.debian.org at some point, maybe not, but the
issue itself is mostly solved.
`dpt salsa configurerepo' sets the kgb webhook.
> * BTS Interaction
> - A webhook exists (needs to be set up on all projects):
> https://wiki.debian.org/Salsa/Doc#Dealing_with_Debian_BTS_from_commit_messages
Also set by `dpt salsa configurerepo'.
> * 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.
> * PET:
> - ask kanashiro/ansgar (or pet-devel@lists.alioth.debian.org)
> - alternative: https://udd.debian.org/dmd/?email1=pkg-perl-maintainers%40lists.alioth.debian.org
> + doesn't that rely on PET for the VCS info ?
kanashiro said he'd look into adding webhook support or writing a
small relay. -- But I think we shouldn't block in this.
> * Migration to Salsa
> * Team name
> - we need a team
> + name? '-team' will be appended
perl-team exists
> * 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?
Adding works via the web interface obviuosly, or via `dpt salsa
adduser'.
> - we probably need subteams/namespaces
More or less solved except for the naming question :)
> * 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.
Please review, comment, improve.
(And ignore the debug features like acting only on one repo, under
attic/.)
The hooks need to be set before the actual migration.
> - 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).
> * repo management scripts:
> - setup-repository/remove-repository/rename-repository (in meta.git)
> probably have to be rewritten to work remotely with the gitlab API
> + setup project
> + permissions
> + webhooks
> + libgitlab-api-v4-perl is packaged
> + we probably also need a "change repo properties later"
> (like add/change hooks) script
Should all exist in dpt-salsa.
> * .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 :))
> * 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!
> * packages to update:
> - dh-make-perl (or maybe not much - Vcs-*: ?)
> - pkg-perl-tools:
> * dpt-alioth-repo - needs to use gitlab API
> * dpt-alioth-author - probably obsolete
> * dpt-packagecheck - only maintainer, Vcs-*: ?
> * lintian checks - mostly docs
> * dpt-get-ubuntu-packages - ssh's into alioth to connect to udd -> API
> * dpt-takeover - repo creation (uses dpt-alioth-repo)
> - libconfig-model-dpkg-perl: mostly documentation; Vcs-*: ?
> * Misc
> - helper script to change git-remotes locally
> (and .mrconfig?); do we need this or is a global insteadOf Git
> config good enough?
> - ping-inactive-maintainers: has to be rewriten. not urgent.
> - some occurences in script.gt/* but nothing really relevant
> + scripts/qa/maintainercheck and scripts/qa/wnppcheck can just die
dpt-alioth-repo is now `dpt salsa pushrepo', the rest has to happen.
Maybe someone wants to come up with a one-liner to change the remotes
[1] locally and/or the .mrconfig?
As for dpt-get-ubuntu-packages, the salsa API won't help for _Ubuntu_
packages; but that's no blocker either.
Speaking of dpt-salsa: Please review, comment, improve, play around
with it. [0]
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?
Cheers,
gregor
[0] running dpt from git is easy:
~/.dpt.conf
DPT__SCRIPTS=$DPT_PACKAGES/pkg-perl-tools/scripts
export PERL5LIB=$DPT_PACKAGES/pkg-perl-tools/lib
with DPT_PACKAGES already set to /home/<user>/<path to pkg-perl stuff>/meta/packages/
before.
Then dpt-salsa needs DPT_SALSA_PRIVATE_TOKEN from
<https://salsa.debian.org/profile/personal_access_tokens>
Enjoy `dpt salsa --man' etc. :)
[1]
btw, do we want the https or the ssh URL? In `dpt salsa pushrepo' I
currently use
= 'git@salsa.debian.org:'
. $config{perl_team_modules_packages_path}
. "/$pkg.git";
but the https URL works as well, with
[url "git@salsa.debian.org:"]
pushInsteadOf = https://salsa.debian.org/
in ~/.gitconfig. Ok, needs one more step, so the former probably
makes more sense.
--
.''`. 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: Dire Straits: Ride Across The River
Attachment:
signature.asc
Description: Digital Signature