* Daniel Lange <dla...@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)
signature.asc
Description: PGP signature
_______________________________________________ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
