Participants ============ present: intrigeri, nodens, ntyni, knowledgejunkie, gregoa hellos/waves from: RoRo, fsfs, axhn regrets from: Work done ========= * Started a gobby document :P * Alioth Services replacement status update * Mailing lists - underway, should be ready before Alioth shutdown. Yay! - alternatives: tracker.debian.org aliases - Shall we ask for a l.d.o discussion list (https://wiki.debian.org/Salsa/Doc#Import_mailing_list)? * 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 * 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 * 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 * 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 ? * Various other Hooks - see migration below * Migration to Salsa * Team name - we need a team + name? '-team' will be appended * Accounts - contact current project members? just the mailing list ? + each member needs to create their own account and ask to join the team - we probably need subteams/namespaces currently we have + meta.git + website.git + scripts.git + packages/ lib.*-perl.git ... + attic/ lib.*-perl.git ... + do we want to keep this structure? probably yes; unless gitlab archiving (?) can replace attic/ ? * project permissions? Is giving permission with the group on the namespace enough? * 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? - 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? * 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 * .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? * 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 * 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 * Enabled all hardening build options on: - libalgorithm-diff-xs-perl - libaudio-flac-header - libencode-detect-perl - libencode-hanextra-perl - libperlio-utf8-strict-perl - libmoosex-role-withoverloading-perl - libnet-bluetooth-perl - libsignatures-perl - libtext-markdown-discount-perl - libtype-tiny-xs-perl - libunix-mknod-perl * Enabled R³ on: - libalgorithm-diff-xs-perl - libaudio-flac-header - libencode-detect-perl - libencode-hanextra-perl - libi18n-acceptlanguage-perl - libnet-bluetooth-perl - libsignatures-perl - libtext-markdown-discount-perl Add "R³: no"? Those of us who want to play add it to a few packages as we go, but we don't turn this into team policy for now. Then we'll get data points and later we can either mass commit or postpone. * replace full CC0-1.0 text with pointer to /usr/share/common-licenses/CC0-1.0 in all affected packages * fix #884626 in liblinux-dvb-perl __DATA__ salsa braindump - people need accounts contact current project members? - we need a team + name? '-team' will be appended - project permissions? - we probably need subteams/namespaces currently we have + meta.git + website.git + scripts.git + packages/ lib.*-perl.git ... + attic/ lib.*-perl.git ... + do we want to keep this structure? probably yes; unless gitlab archiving (?) can replace attic/ ? - do we want to transfer all repos? probably yes - for the transfer: + there are scripts floating around + probably all without subteams + 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? - 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? - currently (in meta.git): pkg-perl-post-receive + KGB * Tincho works on webhook support for kgb-server * formorer has written a ruby kgb-client (which only uses relay-message and connects to his own server): https://salsa.debian.org/formorer/KGBClient * irker webhook exists + PET: ask kanashiro/ansgar alternative: https://udd.debian.org/dmd/?email1=pkg-perl-maintainers%40lists.alioth.debian.org + tagpending: done by Ganneff, needs a webhook configured + commit mails: I think also done? - currently (in meta.git): .mrconfig + 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? - repo management scripts: + setup-repository/remove-repository/rename-repository (in meta.git) probably have to be rewritten to work remotely with the gitlab API + libgitlab-api-v4-perl is packaged + we probably also need a "change repo properties later" (like add/change hooks) script - 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 - 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-*: ? - helper script to change git-remotes locally (and .mrconfig?); do we need this or is a global insteadOf Git config good enough? - mailing lists / Maintainer field: can hopefully be kept, at least for now - 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