On 21/01/14 22:09, Tollef Fog Heen wrote: > ]] Lucas Nussbaum > > This mail has been maturing in my in- and outbox for a little while, and > it seems like the debate died down until the recent dda mail, so > restarting the underlying discussion a bit. > >> Q1. How much should we push for Debian services (services useful to >> Debian) to be hosted on Debian infrastructure? > A lot. > >> Q2. Should we seek other hosting opportunities to ease Debian services >> development and hosting? Should I authorize the use of Debian money to >> fund infrastructure not managed by DSA, in the case of a useful service >> that DSA has been unable to accept in the infrastructure it manages? > I don't think so. We've been pretty open with the requirements and the > reasoning behind the requirements. If those requirements don't apply > for some reason, we should fix the requirements and not work around them. > > [...] > >> The recurring pattern seems to be that, when DSA is approached to move the >> service to Debian infrastructure, their evaluation of the service's design >> results in changes requests or constraints that the service maintainers >> consider too hard to satisfy. > I don't think this is an accurate statement. There have been a few > cases where people have shown up with a design we were unable to > accomodate and progress have stopped, but in general there's been a > tremendous forward progress in what's hosted on DSA infrastructure. I > don't think it's ever been easier to get new services hosted on DSA > infrastructure in the history of the project. Examples over the last > six months are voip, tracker, manpages, contributors, and that's without > looking at any of the various static vhosts added.
Looking at the SIP implementation a) I've run SIP perfectly well "my way" (TM) for many years b) when I approached DSA, I discovered there was an alternative to "my way" c) we discussed, we found common ground, the service is live - the DSA way - which is quite OK, because it is better to have it working in a way that is suitable for a team to support rather than relying on any single individual or vendor As I've mentioned before on this DSA services topic, there are many technical issues that differ from one service to the next, e.g. you can't keep private data, credentials, private keys on some cloud system with a SAN underneath. Copying static web content to mirrors in the cloud is probably quite OK and if some apache log file is lost, who cares - but a Git repository is another thing and it should be on our own hardware. DSA can actually hand some responsibilities out to people to allow them to run things in the cloud but this depends on putting the right interfaces in place and keeping any original data within the official infrastructure. One mechanism we used for RTC is RADIUS (FreeRADIUS server) doing a delegated digest authentication for SIP. With this model, it would be possible to run SIP or TURN servers in the cloud and they would not need a copy of the user database or password hashes. The RADIUS server could potentially be the point where DSA responsibility ends and people can then run other types of service that trust authorized users. If we have to relay a lot of video traffic through TURN, then it would make sense to have local TURN servers in different regions. They keep no local data and can potentially do all access control using RADIUS. Rather than having some awkward discussion about it as a social problem, maybe we can try and look for ways to define such interfaces and give DDs a chance to propose things around them. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52dfc3af.30...@pocock.com.au
