[arch-releng] Things beyond 2009.01/02

[Thayer Williams]

On Sun, Feb 1, 2009 at 8:52 AM, Gerhard Brauer <gerbra at 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.