On 17/05/16 09:06, Jonas Oberg wrote:
Dear Fellow,
over the next months, we'll be rolling out an idea of fellow-run services. As you know, the FSFE has been offering several services to its volunteers over the years: a blog platform, an XMPP service, email forwards, our wiki, and so on.
One of our volunteers, Florian Snow, has volunteered to coordinate a team of volunteers who will look at the possibility of taking over maintenance of our blog platform and run this as a service for other volunteers.
By forming small volunteer teams around specific services, we hope this will provide first the necessary autonomy to the individual teams to run the service as they would want it run, and second, a useful learning experience for the volunteers who take up the role of maintaining a service.
Can you comment on what this means from a technical perspective? Does autonomy mean that volunteers will be able to pick any arbitrary version of an application and start running it on FSFE hardware? Or will volunteers run it on their own hardware and if so, how will things like authentication credentials be shared?
In Debian we also have services that are maintained by individual developers, they fall into two categories:
a) *.debian.net - these services run on a Developers' own servers, debian.net DNS is the only thing managed centrally, Debian provides no guarantees about the availability of such services
b) *.debian.org - services running on Debian (DSA) managed hardware. Any applications used on such machines have to be packaged and backported to the stable release (e.g. jessie-backports). These have a higher level of availability and security updates.
People who want to ensure a service is available 24x7 can generally help by ensuring all the software and dependencies are properly packaged and backported or helping raise funds for a developer to do that work. While it seems tedious at first, this is how we achieve security and availability. For example, when the developer of a package or backport is on vacation or retires, it is relatively easy for a security team member who never saw the package before to get involved and release an official patch for it.
I often come across people who insist that they have to run the latest version of something from Git, usually with a hodge-podge of dependencies downloaded directly from different web sites. These types of arrangements are often very unique and very hard to support when the person is on holiday or decides to stop supporting it.
Regards,
Daniel