[arch-releng] Things beyond 2009.01/02

[Dieter Plaetinck]

On Sun, 1 Feb 2009 11:43:55 -0800
Thayer Williams <thayerw at gmail.com> wrote:

> 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.
> 

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