[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian services and Debian infrastructure

]] Charles Plessy 

> Personally, I am totally confused by what I read, and do not understand what is
> even the basic stand point of each participant.  May I suggest that you talk
> directly face to face or by videoconference ?

You're of course free to suggest that, but if you read the initial mail
in the thread you'll see that this is an attempt at bringing this
discussion into the open, where it belongs.  Taking it off to some other
medium will work directly against that.

> For me, the take home message is:
>  - Do not develop services that need you to have administrator access, because
>    this is hard to transpose on DSA-hosted machines.

No, because it's a terrible idea in general.  If your service requires
you to have root on the system, it's probably misdesigned.

>  - Sevices on debian.net should be hosted by Debian as much as possible.

Rather, Debian should self-host our own services.  What their domain
name is is less important.

> After many years as a DD, I became better at using a machine via root
> privileges than via collective hosting.  For instance, I completely forgot how
> to use CPAN, and I am much more comfortable configuring apache via
> /etc/apache2/sites-available than via .htaccess files.  Also, by my activity of
> a DD, I am more familiar with Testing-Unstable mixtures than with Stable.  For
> example again, I did the apache 2.4 transition, where the Debian Apache team
> made a great work, and I would prefer to forget how the 2.2 systems work.

If you look at the various setups, you'll see that it's not uncommon for
us to give service admins write access to their vhost setup, so there's
hardly any conflict between that and not having root.  As for mixing
testing and unstable in production, I hope you see why that is not a
great idea on a production system.

> I think that if I enjoyed collective hosting, I would have used it through
> numerus commercial providers, and would not have become a DD.  At work, I would
> happily install software in my home directory on our CentOS servers, and would
> not mumble regularly that we need access to a cloud system instead.

Installing random software in your ~ instead of from packages is a
really bad idea since there's then no central record of what's
installed, there's no uniform way to upgrade the packages, etc.  All the
usual reasons for why we use packages rather than building stuff from source.

> But now I have the impression that self-hosting it is very unwelcome, and that
> the bar for setting up a .debian.net service is very high.

If you're hosting it yourself, ask two questions: Does this (or will it,
in the future) provide a valuable service to Debian?  What happens when
you lose interest or get run over by a bus?

If the answer to the first question is yes (which I hope it is, since
else why are you spending your time on it?) you should have a good
answer to the second question.  My answer is «it runs on Debian
infrastructure, so the underlying OS is maintained, the hardware is
maintained and we're able to grant other interested DDs access to the
service».  I think any reasonable answer that satisfies the same
conditions basically means you're duplicating the work DSA are already
doing, which is inefficient.  If you do have a good answer that doesn't
imply a waste of resources, where the OS and hardware is maintained and
where we, as a project, can have some reasonable level of service
contigency expectation even in the case of catastrophic failure of the
service owner then I'd like to hear it.

> I am not asking for an answer now since you need to clarify a lot of points
> together.  I understand the need for transparency, but on the other hand,
> posting your discussion on -project gives the implicit message that the other
> subscribers should read it.

No, it means we think that other people should be able to read it, which
is not the same thing.  I have no opinion on how the subscribers of our
mailing lists spend their time.

> Please take your time and consider using parallel and more casual
> discussion channels, to focus the postings on -project to the points
> of agreement that you reached, rather than the points of disagreement,
> which we all hope are just transient.

I'm not going to do this for the reasons outlined at the top of this
email.  If this thread bothers you, just ignore it. Heck, it's not as if
-project generally has that much traffic, so just skimming it shouldn't
take that many minutes out of your day.

I find it really disappointing to hear that you would rather have
discussions with project-wide ramifications to be held in secret, rather
than out in the open.

Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Reply to: