On Sun, 1 Feb 2009 11:43:55 -0800 Thayer Williams <thayerw@gmail.com> wrote:
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.
It's cool to have the release name show up at some places of the *iso* (/etc/issue, /etc/rc.sysinit and in the installation program itself for example) I don't think it should show up at all in the installed system. I don't see the use: rolling releases, keeping things simple et al. release names: I don't care about them, but I believe enough other people do, so sure let's use them. but let's not waste too much time thinking of/discussion names.
c) Installer switch IMHO we are common to try aif as the next installer. So testing should begin closely after 2009.01/02 release. That's also a reason why i would not fix each minor thing or add features to current archlinux-installer for 2009.01/02 if we maybe kick it next months.
First a note about AIF's current state: Quite usable: it produces working arch installations just like /arch/setup, most of the stuff "just works". also lvm/dm_crypt seems to work fine which is imho a big advantage. However, it's not as polished as /arch/setup: there are some rough edges like in some menu's if you press cancel it will continue. You can for example create a new lvm logical volume, press cancel, and it will continue and later on it will fail because the lvm LV entry was not good. So there are a few (known) bugs. Also, there are the bugs which we've been fixing in the last 2 weeks or so in archlinux-installer which I still need to port into AIF. Also, it looks quite good in vbox but I personally have never run aif outside of vbox yet. So the size of the menu's etc may be a bit awkward I don't know, because I designed for virtualbox. Bottom line is: I think if some people help out with testing, we can make aif a worthy replacement for /arch/setup in the course of a few months. But we must start testing aif early on and not wait for 2009.04-alpha iso's. aif is on 2009.02 so go ahead and play with it. The alternative is we keep working with archlinux-installer but I don't see the use to needlessly prolong it's life. Especially because afaik no one really maintains it, and it's cumbersome that we need to fix new bugs in both archlinux-installer and aif.
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.
2nd
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.
Of course. that's what we have http://wiki.archlinux.org/index.php/DeveloperWiki#Release_Engineering for. Let's just not document too much. Our docs should say what's needed, but not more. it must be maintainable. Other then "internal" documentation, we should also think about documentation aimed towards the community. Eg http://wiki.archlinux.org/index.php/Official_Arch_Linux_Install_Guide needs/will need a lot of work, there are also 2 txt documents in archlinux-installer (not the most correct place for them imho). There is also a request ( http://bugs.archlinux.org/task/9902 ) for a package with various documents, which I think is a good idea, but this goes way beyond arch-releng. We should have a dedicated documentation team and/or documentation should be a well-maintained collaborative effort. (not just arch-releng) Dieter