Re: Debian services and Debian infrastructure
On 13446 March 1977, Lucas Nussbaum wrote:
> Q1. How much should we push for Debian services (services useful to
> Debian) to be hosted on Debian infrastructure?
A lot.
> 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?
Like wasting money on essentially dead systems, like m68k?
> However, there has been several episodes, involving the development of new
> services or their move to Debian infrastructure, that generated a lot of
> frustration and demotivation on both sides (DSA and service developers).
> As examples, one can think of codesearch, or the fedmsg GSOC project.
>From what I followed on some service, a good part of the frustration
came from real unrealistic requirements that just got thrown in front of
DSA. One thing i remember is "Oh, we just need fast storage, a recent
SSD is enough [...] its only a hundred or so dollars" - which is an easy
thing to say talking about desktop machines where you put one. But DSA
operates on a different level and suddenly putting SSD storage came out
multiple thousand dollars. Not surprising that it wasnt taken all that
good a suggestion.
And another can be summarized to "here, take this, no, your ideas aren't
considered, all the rest of the world eats this too, so you have to eat
it also". Makes people love to help you.
> There are also services that have been developed outside of Debian's
> infrastructure, with AFAIK no plans to move them to Debian infrastructure.
> 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.
And that is a problem. Not directly with DSA, not directly with the
service maintainers, but with the structure of having development of
services done outside the infrastructure it later on should run on and
then blindly assuming that the infrastructure can just take it.
That does not work.
> I'm worried that this situation is harmful for the project.
Yes, seperate development with different requirements than the
production environment is harmful. It's a lesson that every larger
company with an IT Department goes through at some point - and it's
the same for our project.
You need a development environment that is build and handled the same
way as the production environment. Sure you need to evolve that, it may
not stand still, with new requirements coming along, but you need to do
that in close work with the people maintaining the production one, to
ensure that the way thinks evolve is actually something that can be
mirrored in the area it is intended to be run later.
(Alternatively you can have a free-for-all run development and then get
a third env, in which you then try to get to run the new release in a
(newer version of the) production env).
> Similarly to how we increased the amount of collaborative packages
> maintainance over the years, we should improve on collaborative
> service maintainance, and we should move away from the myriad of
> unofficial services maintained by a sole DD, and hosted on this DD's
> personal machine.
Oh yes, I don't think anyone will disagree with "Services for/around
Debian should be run on official hosted resources".
> 1. to improve communication between DSA and service maintainers
> + have an archived, public list where (prospective) service maintainers
> can engage with DSA about stuff they are planning/thinking about.
> (Maybe recycle debian-admin@l.d.o, or use debian-services-admin@l.d.o?)
+ Have service maintainers accept that other people (eg DSA) have
knowledge too. And accept their input.
> + have DSA provide collective answers more often, rather than a set of
> individual answers. It's often not clear if something is a final
> decision, or the opinion of a DSA member.
If it gets a requirement that DSA has to give collective answers and
otherwise should refrain from commenting, then its bad. Also, an
individual DSA answering and giving his opinion shouldn't be a
problem - it only would if the team itself is splitted and you get 5
opinions from 3 people.
> 2. to improve the tracking of services
> + request wiki pages from maintainers that detail who are the contact
> points, what the service does, what are its requirements. State a
> "service level agreement" (informative of expectations, not punitive,
> of course)
> + have service maintainers create similar pages for services in
> development, to provide some kind of "incubation process" during which
> DSA can provide feedback.
+ have service maintainers engage with DSA *early*, as early as
remotely possible, listen to them and work with them to get
useful (for both sides) compromises to make the service a good
guest on Debian resources.
>> 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?
> For services development (something for which we don't have a good
> answer yet), I think that we should explore getting specific sponsored
> hosting. As you know, Amazon provides Debian with free credits on the
> AWS Cloud. Those credits are normally used for archive rebuilds, but
> have already been used by a GSOC project (PTS rewrite), and more
> recently, to start work on an archive-wide autopkgtest setup. A few more
> virtual machines could be accomodated, and I will investigate if we
> could extend that even more. Also, codesearch.d.n is hosted on
> Rackspace's Cloud[1]. I will also follow up on that.
> [1] http://people.debian.org/~stapelberg//2013/12/25/codesearch-rackspace.html
I disagree on the part of having that full external. Some "Debian cloud"
where one can develop stuff and not have to use own resources too much
(not everyone has tons of servers around to use) sure would be nice,
even better if its nicely integrated into Debian. Having "throw-away"
VMs where a DD/DM (or maybe someone vetted by a DD) could have access to
even root to easy development could also be good.
>> Q3. What should be our definition of "official services"?
> Even if this is highly preferable, I don't think that official services
> (.d.o services) should necessarily be running on Debian hardware managed
> by DSA, provided that:
> - the service is clearly useful and used
> - the service has a sustainable maintainance model (active team +
> instructions on how to contribute, run a local copy, etc. + DFSG-free)
> - the service's design does not raise security or scalability concerns
I disagree on that, official services should run under project
overview. So far that the project can take it over and move it, should
all of the team go away. Active team today doesn't mean they are there
tomorrow to properly hand it over. Having the project itself have access
(via DSA at least) ensures it can continue.
--
bye, Joerg
[2.6.15.4 direkt nach 2.6.15.3]
<HE> Linus muss Gentooler hassen.
<formorer> wieso?
<HE> Naja, die dürften ihre optimierten Kernel gerade fertig gebaut
haben und müssen jetzt aus prompter Versionitis auf das
Ausprobieren verzichten und den neuen kompilieren...
Reply to: