Re: Alioth → Salsa
-=| gregor herrmann, 10.02.2018 21:13:27 +0100 |=-
> On Mon, 22 Jan 2018 19:28:44 +0100, gregor herrmann 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.
It is possible that either nobody cares, or the list readers don't
really read each and every message.
For the later, the sudden stop of mail may be the thing that will
raise awareness of the situation. Since salsa provides similar
functionality ("watch", per group), if somebody really misses the mail
flood, there is still way to get it back.
I.O.W. I think pkg-perl-cvs-commits can be considered as retired and
of no concern for the migration.
> > * 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?
scripts/committer-stats tells me there are 52 contributors with
commits from the past year.
> 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.
> > - we probably need subteams/namespaces
>
> More or less solved except for the naming question :)
Data point: the poll has 12 votes cast and 5 days to go.
> > * 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.
I wonder how pumping 3000+ repositories will affect poor alioth :)
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)
- put a "you can't work here anymore" stopper to the alioth
repository, before the migration, revert it if the migration fails
- incremental migration
- (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)
> The hooks need to be set before the actual migration.
Which hooks do you mean?
> > - 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-*.
> > * 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 :))
I think we can start without the pet/hashes trickery. Maybe salsa is
quick enough to make all this obsolete.
> > * 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.
> 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.
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)
-- dam,
excited to see the migration so close to reality
Reply to: