Introducing our new blog team

[Daniel Pocock]

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