[Fedora-legacy-list] System

[Ingo T. Storm]

Hello,

I am new to the list and new to the project's approach, so please forgive
any stupid remarks or questions - just point me to TFM or correct me. I am
not too sensitive;-) I have browsed the list archive in order not to
duplicate anything and now I'd like to share my few cents:

- project goal and scope: As most others I have a bunch of RH7.2 and RH7.3
systems I'd like to keep alive and secure at least for a while. To add some
spice: besides a bunch of ia32 boxes of which most will be converted to RHEL
ES/WS/PW, I have sparc and alpha boxes that need errata, too. The sparc
machines are running Aurora (http://auroralinux.org) which is based on Red
Hat Linux 7.3. The alpha machines (Ruffian, Avanti, Miata) run RH7.2AXP.
Bottom line: _I run servers. I want security updates to core services. No
new drivers, new kernel features, no desktop functionality whatsoever._

- I agree with most "initial notes" compiled on
http://www.fedora.us/wiki/FedoraLegacy, esp. David J. Bianco's post.

- package maintainership: I share the view that there won't be that many
packages that need errata. A quick scan over the last 6 months of errata to
RH7.3 revealed: little over 1 weekly erratum that touches the kernel, core
OS functionality (e.g. fileutils, unzip) or crucial network services (squid,
openssh, apache). So it's no use assigning maintainers to the 800+ SRPMS
RH7.3 is built of. I'd rather have pairs or triples of people with certain
dutys and/or skills so that vacations or job burdens don't let a high
profile exploit be unnoticed by the project for too long. Two/three people
should be on vendor-sec. In addition two/three people should monitor mailing
lists of each "functionality group" like e.g. "apache/php/mysql/postgresql",
"openssl/openssh", "core utilities", "kernel/netfilter".  If and ONLY if you
have too many volunteers, add mozilla, evolution, xfree86, gnome, kde... The
potential backporters need not be identical with the monitors. I'd rather
favor that all the "backporters" maintain a personal wiki page with their
skills/experiences, "last job done", current and expected spare time, so
that the "monitors" have a pool to chose from. QA and possibly porting to my
two extra arches would be the third stage. This does not mean that monitors
should not be backporters and that I don't expect that certain people will
always be asked first when a certain package needs fixing. As far as the
"monitoring" is concerned: This is the area I know the least about, since it
was just dead easy for Aurora. Using Red Hat's experience and processes
should be the smartest possible move.

- my possible contribution: I honestly can't code to save my life. But as an
errata builder for Aurora I know how to build RPMS, sneak in the odd patch
and identify problems. So I can do some of the boring work and thus save
some valuable time of the folks that should spend their time hacking away
instead of maintaining a stupid %changelog. Additionally I will try and port
ia32 patches to the sparc and alpha architectures (and maybe get some people
into the boat who can do that a lot better).

- my most important question: has any thought been given yet to include
sparc and alpha at all?

I hope I did not bore you too much.

Ingo