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
