State of the archive

[Egbert Eich]

Stuart Anderson writes:
 > On Wed, 10 May 2006, Egbert Eich wrote:
 > 
 > > There was a cleanup process under way in the release directory on fd.o.
 > > With this pretty much completed we can start the mirroring process.
 > 
 > Maybe I missed something, but I haven't seen an email that states that it's
 > all complete to everyones satisfaction.

If I have followed this discussion correctly we have arrived at a state
where things are in place far enough to start the mirroring.

 > 
 > > This however is different from the 'who gets access to those machines?'
 > > question.
 > > The mirroring would remedy the problem of not having latest releases
 > > (especially security) available on the box - even without anyone needing
 > > to access the machines.
 > 
 > The security fixes were put in place at least a week ago.

OK.

 > 
 > > 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.

Right. The machine hosts the board and sponsors mailing lists, the members 
list and the master copies of some of our legal stuff.
Some of this stuff needs to be protected reasonably well:
- The board and sponsors mailing list may contain confidential information.
  While most messages exchanged don't fall under this cathegory it has
  always been assumed that this information isn't public, therefore it
  needs to be kept protected - even if the policy is changed in the future.
- The membership list and the master copies also need to be protected
  from manipulation. 
It is therefore reasonable to limit the number of people with 
administrative privileges. 
On the other hand someone who volunteers to do this job should know that 
he is accepting certain responsibilites. All the people who have shown 
interest in helping with this task seem to be responsible enough to 
understand this. Furthermore abusing these priviledges would not be
accepted by the community and may even have legal implications.

Therefore keeping a good balance may be the way to go.

Furthermore:
1. The new membership registration, renewal and voting infrastructure has
  not yet been put in place.
2. The board and sponsors mailing lists are really low volume.
It seems to be quite rediculous why we host this stuff on a huge server
like expo and let this keep us from utilizing the machine. 
If we feen that this material needs to have some very tight protection
it may not be a good idea to have it on a widely known machine that
provides web services.
It may be reasonable to think about either virtualizing the machine or 
hosting the confidential material elsewhere (on some low end system).

Stuart, we all appreciate the time you donate to the task of administrating
the machine. At least some of us are aware that you are quite busy after
all you have to feed a family - some responsibility a lot of our community 
members don't have yet. Furthermore being on the bylaws committee has 
certainly not helped reducing your workload.
Shoudln't we try to find a volunteer in our community to help out with 1.?
Although our election schedule doesn't create an immediate pressure 
the membership infrastructure has been defunct ever since we left TOG.

 > 
 > 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.
 > 

Yes, this is certainly true. Meanwhile these machines have been sent to 
Boston (although I don't know where). It now depends on the people with
access to MIT to set them up or make sure that volunteers whou would like
to help with this task are given physical access to the location.

 > 
 > 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.
Yes. Definitely. 

 > 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.

There were some ideas put on the table early on. However these ideas involved
hosting all of our repostiories on the x.org machines whidch would make x.org
independent of the freedesktop.org infrastructure.
Considering that the freedesktop.org infrastructure seems to be rather stable
now and is certainly running well and that changes to the SCM infrastructure
are under way it may not be a good idea to make this a short term goal.

 > 
 > 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?

Here is a list of possible services (a lot of them with questions attached)

1. Web service (should X.org have a web page at all or is a wiki sufficient?)
  If yes: we'd probably need a dedicated 'web master' even if we give access 
  to numerous people to add content.
2. Wiki: Do we want to move the Wiki from fd.o?
3. ftp: Hosting of the releases (this issue has been extensively discussed)
4. hosting (mirroring) the SCM (should this be the site where the general
  public should pull sources from?
5. mailing lists (should we migrate all the xorg@ related lists from fd.o?)
   We could start migrating the lists hosted at lists.x.org.
6. Should we host bugtracking?
7. Hosting Foundation material (board, members 
8. Membership registgration infrastructure (should we find a dedicated 
  maintainer for this?)
9. Voting infrastructure (does anyone have experience with this?)


Should we set up one machine as a backup (or master) of the content -
a machine that doesn't provide services to the general public?

1., 3, 7., 8., 9. would be the primary goals. They don't seem to be
too maintenance intensive.
We could also start with 5 if we have a dedicated maintainer. Currently
Mike is doing this on fd.o.
Some of the other tasks are well established on other machines. It may
not make much sense in migrating them thus duplicating the amount of
work. Still we could mirror/backup the content of these to one of the
machines. 

Since we will have 3 machines we can use one for public services
(pretty locked down), one for task forces (web, mailing lists?, login...)
and one for backup and mirroring.
 > 
 > Getting some of these things worked out before the other machines show up
 > would be a constructive use of time.
 > 
Yeah.

Cheers,
	Egbert.