On Sun, Feb 1, 2009 at 8:52 AM, Gerhard Brauer <gerbra@archlinux.de> wrote:
I have some points we could/should discuss after the upcoming ISO is finally released. So this are things which affect eventually 2009.04.
These are all good idea/suggests...my own two cents follows: I agree the number of options is too large for sensible maintenance among our ranks, but it's a tough call... FWIW, I don't use my install ISO to troubleshoot/repair after the setup, I have other tools for that. When I need to do a setup I simply dd one of many spare thumb drives lying about and as soon as the setup is finished the thumb drive gets tossed back into the drawer. Neither ISO formats have caused me trouble, but my experience is generally limited to 2 notebooks and a workstation. If we can't use a single ISO format (isolinux/whatever) to successfully boot 99.9% of machines out there, then that's a significant hindrance. Is there nothing we can do to eliminate this redundancy? Ideally, here's what I'd like to see... * 686/x86_64 multi-arch (combined) * FTP installation only (kill core) * CD ISO and USB IMG That would essentially give us two images (four if we must do the whole isolinux/bootloader duality stuff). I just don't see the need to offer Core setups and this would cut the workload in half--if the user doesn't have Internet access there's really no sense in running Arch. If they have limited access, they should be able to use the FTP setup when time permits. An FTP-only multi-arch setup would allow us to keep the image small and cut the work by half again.
b) Release "branding" Should we have release names? Should we have the release versions (ex. 2009.02) in the splash screens (grub, isolinux) and maybe in /etc/issue? Background is: User should be able to identify which ISO release he currently uses. Having the release version only on ISO/Img-File is sometimes not enough.
I'm not crazy about branding the releases, particularly with codenames and especially in multiple places. If we brand at all then I think a single instance of a datestamp, preferably near the initial setup, would be appropriate.
d) Accessibility support on install mediums There were a discussion on arch-general about that (and the needed tools and modifications sounds not a big work), Aaron brought up an idea with additional speak output, so this supports not only braille reader users. We must see if we could at this support smoothly into the current mediums or if maybe a separate ISO is needed.
Sounds great, but I have no idea how complex this is going to be whether that's going to bump our ISO count again.
e) Testing and documentation IMHO we should document such things as archiso's work-flow, HowTo for ISO/image building and releasing steps. Also things like torrent setup etc.
Woohoo! Someone who actually wants documentation...I'm all for it.