State of the archive

Dave Airlie airlied at gmail.com
Thu May 11 03:25:01 PDT 2006


> > The access question touches on other issues:
> > 1. The present situation of having a single admin for the machine was
> >   requested by the admin. He'd be better qualified to comment on the
> >   reasons than I am.
>
> Predating this, is a request from some members of the board to provide a
> machine that is 'private' to the board so that some documents and such
> can be kept there. Expo.x.org is that machine. Enforcing this privacy policy
> seemed easiest if there were not a lot of people (with possibly different
> goals), trying to admin this one machine.

Now why didn't we all know this earlier? I'm happy that there is a
requirement that x.org have a machine for board members to collaborate
on (granted I think you have to at least give people who administrate
machines in general some trust, we've all got root on systems with
users on them, we don't look at users data, it part of being
professional).

But why move www.x.org and ftp.x.org to this machine? I don't see
board members intersecting releasers at all, from what I can see that
intersection is probably Kevin. We could    have moved ftp.x.org and
www.x.org to fd.o hosting until we had a machine ready to commit to
the task.

If you look at fd.o, somehow Keith manages to find people to admin the
boxes, while I appreciate Stuart's time donation, I believe we can
find admins for x.org boxes from the fd.o admins group, most of which
are x.org committers if Keith can give them enough sushi. One admin is
not sufficient to admin x.org boxes in a timely manner, if that one
admin won't work with an admin team, then thanks for the work and move
on....

> We have always believed that additional machines would be arriving within
> a couple of weeks, so keeping expo private did not seem like a problem. These
> other machine would be admined by the normal group of those that know how to
> do such things.
>
>
> Part of this thread which has not yet occured, is a desciption of how the
> additional machines will be administered. I think that several people have
> an idea of how they will be used, and feel that such usage should be obvious.
> Unfortunately, becasue there are humans involved in this, I'm afraid that
> there are just as mant different ideas as there are people with ideas. Thus
> far, no one had enumarated how the machines should be used.
>
> What OS should be run on each machine? What services should be run on which
> machines? How will users have access to what parts of what machines? What
> filesystems/archives will be copied from which machine to which machine. What
> is the policy for add-on software? Build & install from source, or only use
> packages that are available? Who is watching for security announcements for
> the add-on packages that are being used?

Do we have any conditions imposed by Sun on the machines? Do they have
to run OpenSolaris etc.. can any background info be made public
please? If we don't have any conditions, I recommend running Debian
the same as is on the fd.o machines, its probably the least political
OS for a cross vendor setup, granted master.kernel.org runs FC4 and
nobody runs about shouting about it, so maybe we can keep politics out
of it...

Packages available for the OS should reall be used as much as
possible, again debian suits this as nearly everything is packaged for
it... that's why I'm against Open Solaris at least, adminning Solaris
always seems to require more effort.

As for what goes where on the machines, perhaps someone could list the
services  X.org machines are required to provide.

1. X.org board common working area - on expo - only board and admins have access
2. ftp.x.org and www.x.org, - probably served from a common box this
box could be locked down, mirrored automatically from another primary
machine with developer access (again kernel.org does this, it works
mostly okay, the world then mirrors the mirror boxen.)
3. version control - do we want to bother moving from fd.o, I think
they do a great job and I'd rather not transfer it.
4. people.x.org service? like fd.o so x.org developers can have access
to publishing space, granted fd.o does a great job of this now.

Dave.



More information about the xorg mailing list