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