Re: Alioth → Salsa
(cut things we seem to agree on or no longer needing work)
-=| gregor herrmann, 11.02.2018 15:22:58 +0100 |=-
> On Sun, 11 Feb 2018 10:32:57 +0000, Damyan Ivanov wrote:
> > > 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.
Right. Let's do it this way then.
At some point we'd need to figure out the yearly activity ping, but by
that time we should have some experience with salsa's services.
> > 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).
ACK.
"Sorry, alioth, we tried" :)
> > - put a "you can't work here anymore" stopper to the alioth
> > repository, before the migration, revert it if the migration
> > fails
>
> Ack.
Done in alioth2salsa (thanks to gregor for watching over for silly
mistakes)
> > - incremental migration
>
> Hm?
Suppose we start the migration in the morning, and by noon alioth
reboots because of the overload. We don't want to start over in the
afternoon, but to continue from where the morning run left.
Maybe by checking whether the alioth repo already has the pre-receive
hook used to disable pushes.
> > > > * .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?
That could work nicely. Or dpt salsa createrepo can also update meta's
mrconfig, like dpt alioth-repo does now.
> > > > * 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
Each wiki is backed by a Git repository that can be cloned and worked
on locally, then pushed. See
https://salsa.debian.org/kgb-team/kgb/wikis/git_access for an example
(and ignore the part for starting a local wiki engine).
However, I can't find a way to create a wiki for perl-team/modules,
only for individual repositories under perl-team/modules/packages.
So, scratch that idea.
> > 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.
I started filling in
infinote://gobby.debian.org/Teams/Perl/Alioth2Salsa
-- dam
Reply to: