[Alioth-staff-replacement] Some details for the sprint tomorrow

[Philip Hands]

Alexander Wirt <formorer at debian.org> writes:

> - get a replacement for git.d.o
>   - finally decide about the replacement (I do prefer gitlab as a
>     replacement, but I want to hear your opinion first)

Following on from what was said last night, I have some thoughts that
I'll put down in writing to kick of further discussion while I'm sitting
on the S-Bahn:

It seems that there is nothing that is packaged that we're willing to
use.  I had thought that one of the points in favour of gitlab was that
it was packaged, but if we're agreed that the version that's been
packaged is outdated and insecure to an extent that means we should just
use whatever upstream is releasing, then that does not apply.

Does this not free us up to consider other options?  It looks like we
have several offers of help from upstreams (GitLab, Pagure, Kallithea)
to make their software work for us.  How about giving them all a chance
by encouraging them all to set up experimental instances in parallel,
and then letting DDs loose on all of them to give chance for people to
form opinions?

Obviously, this could delay things, so I think the people present at the
sprint should just go ahead with doing whatever they were planning on
doing, but keeping in mind that other things might get set up in
parallel, and a) making room for that, and b) trying to make sure that
things are not tightly coupled to whatever solution we're currently
working on.

Assuming that we do get multiple enthusiastic groups pushing multiple
platforms, is there actually any reason to choose only one?  Could we
not have gitlab.d.o, pagure.d.o ... and then have git.d.o be a thin
shell that lets people find repos on whichever platform the maintainers
for that package prefer at the moment.  That would avoid the pain of
migration in the future, as failing platforms would naturally wither as
maintainers abandon them for better options, and new platforms could be
added to the mix as they appear in future.  I can see that this might
result in a sub-optimal outcome, so just take it as a discussion point.

Having settled on a non-packaged solution, we're going to end up outside
the DSA fence, which seems like a shame to me.

Might I suggest that we make a commitment to not chase the latest
version of upstream (with the exception of security updates) so that
people packaging the thing have a mostly non-moving target to aim at?

Also, if it is the case that gitlab in stable is unlikely to ever be
supportable, a couple of things occur to me:

  1) using packages out of unstable seems like it's closer to what DSA
  can tolerate than using the upstream direct, so perhaps we should
  just do that (or could this perhaps be the thing that will finally
  provide enough motivation for bikesheds to become a reality? ;-) )

  2) Having a version of gitlab in stable seems like a disservice to
  Debian's users, if we're not willing to touch it.  If the software
  really is not stable, we should make that clear by ensuring that it
  doesn't get in releases, so that people know that they're having to
  grab it out of unstable, and thus what to expect.

HTH

See you later.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/alioth-staff-replacement/attachments/20170818/1ddb3346/attachment.sig>