* Daniel Lange <DLange@debian.org> [2017-09-11 15:27:42 +0200]:
> Hi,
>
> as discussed with many of you during DC17 the DC core team (whatever
> that really is) would like to try again and move the DebConf
> infra-structure into DSA operations. That effort stalled somewhere after
> DC16 when we made the partial mail migration. So let's try again to get
> more infra cleaned up and into DSA operations.
>
> I've taken the task to collect the items to migrate and drafted an
> initial email to DSA at
>
> https://pad.sfconservancy.org/p/mtvpbvwuWu
>
> Please review that.
Hi Daniel,
Thanks for the draft, and for driving this.
While I can only agree with the general goal of migrating DebConf infra bits
under DSA, I have some concerns about the approach.
My experience with DSA has been that they're happy to provide hosting for
services backed by teams, only if there is a long-term commitment from
individuals to administer said services. If we come up with a list of services
to migrate, without owners to proceed with administering the migrated service
and to perform the migration, DSA will tell us (with reason) to come back when
we have those people.
As such I think that the first step would be to assemble a team (or teams) that
would be willing to administer the services we want to migrate to Debian
infrastructure. AFAIK, currently, only the video team has an existence in DSA's
eyes (as the video review system's frontend is hosted on a DSA system).
One thing that would be useful to know, is whether DSA would prefer a catch-all
"debconf-infra" group, or groups targeted towards individual services. I think
the website group should be separate as it handles sensitive data, but I have
no opinion for other services (nor time to offer to handle them, so my opinion
doesn't matter anyway).
> I'd be most interested in feedback on what to do with cruft we have
> accumulated over the years.
> See https://anonscm.debian.org/cgit/mirror/domains.git/tree/debconf.org
> for probably the best overview available.
> https://debconf.org/resources.shtml is another list (and worth replacing
> itself as it still shows DC16 as "Current DebConf site" so this is
> clearly neither maintained not used.)
>
> I'd really like to reduce the set from what we run for DebConf down to:
> * Wafer (debconfXY.debconf.org)
> * The DebConf wiki (itself in discussion of merging with Debian wiki,
> another thing that's not gone anywhere after DC15 / DC16 discussions)
The Video Team is currently only adding new stuff on the Debian Wiki, with the
endgoal of being able to rely only on it from here on out.
> * Email / Mailing lists
> * {media|git} static file / git (-annex) hosting (ideally moving to the
> alioth successor (currently nicknamed "salsa") at some point in time)
> * Infra for the video team (mostly archive:=storage) as per-DC
> requirements can be covered by temporary VMs / cloud instances
> * The Kanboard instance we have used for DebConf17 and are using for
> DebConf18 now. That seems to be a valuable light weight tool.
> * Anything else I missed which is essential and maintained (please add
> to the above Etherpad!)
As far as I can tell, save from wafer and kanboard, everything you're listing
is in life-support mode rather than maintained. We really need to come up
with service owners before we make any grand migration plans. [the only item
that might short-circuit that requirement is lists, as the DebConf lists are a
small addition to the current burden the Debian listmaster team already
carries, but we shouldn't presume and rather ask]
> [snip]
Unless there's any strong objections I will go ahead with submitting the RT
ticket for Wafer hosting, as the maintenance team for that service already
exists :-)
<3,
--
Nicolas Dandrimont
"Besides, I think [Slackware] sounds better than 'Microsoft,' don't you?"
(By Patrick Volkerding)
Attachment:
signature.asc
Description: PGP signature