[arch-releng] Things beyond 2009.01/02
I have some points we could/should discuss after the upcoming ISO is finally released. So this are things which affect eventually 2009.04. a) Number of different ISOs/Images: We have currently 10 different mediums to install Arch Linux. I like to reduce them for better and easier building and maintenance. Archiso based mediums are both installation and Live-CD mediums. IMHO a user who will install the system uses such a ISO/Img only once, for the installation and maybe to correct errors during installations. These users like small ISOs/Images. For users who would use the mediums for ex. as Live-CD/Maintenance we offer to few tools and programs on this ISO. Another point is the ISO bootloader. We have add already isolinux cause grub has boot problems on a not so few count of PCs. My suggestion on this is: For the core/ftp CD-ISOs we use only isolinux as bootloader. This will boot on all PCs and these mediums a mostly used only for system installation. So we also could keep them small. The USB-Images still should have grub as bootloader (I currently don't know if iso/syslinux work on them and we never have a reported problem about USB images and grub). Also i like to see a combined i686/x86_64 medium, as we produced one for the FrosCon-ISO. The necessary framework is already available for archiso. This ISO/Image has naturally a bigger size. My idea is now to full-fill the remaining space on a cd with programs which are usefully to use this mediums as a base maintenance ISO - for both architectures. And on this we should use grub as ISO bootloader cause we need/benefit here from grub's flexibility above isolinux. Doing this (and using isolinux for core/ftp-ISOs) we would end in a medium count of 9 different mediums (4 x CD-ISOs, 4 x USB-Images, 1 combined). That is still a big count... Other think-games: - Kicking core or ftp. Both alternatives have disadvantages: ftp is small and offers a up to date system during/after install. Core gives a bootable systems also when no internet access during installation. But we will end in a medium count of 5. - Also offer combined mediums (i686 and x86_64) for each core/ftp ISO and USB image. Disadvantage: the download size for each medium is greater, so one who would only install Arch Linux have to download many Megabytes he probably not and never need. But this would reduce medium count also to 5 but we could have separate core and ftp installs. 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. Release naming is "neet", but are we able/willing to think about nice names? Document the release versions in splash screens/shell overview is quiet easy, but we have to automate this by a script. Otherwise these changes will be surely forgotten sometimes.... 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. 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. 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. And improve our (pre)testing procedures to avoid such things like grub-gfx error on x86_64 in the future. This have to be found on our side before public testing! But i think we all have learned much during the process of releasing 2009.01/02 what crude things could get broken. And that Murphy is still alive ;-) OK, these are the things I mean which await us next releases, we should mention about. Of course we/you will found more... Gerhard
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.
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
Am Sun, 1 Feb 2009 21:42:02 +0100 schrieb Dieter Plaetinck <dieter@plaetinck.be>:
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:
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.
You're right, i don't mean to get these release numbers/names into the installed system - only a way to identify the ISO what the user currently is using. So Thayer's idea having the current iso version/name as a text file is good IMHO. Placing it in the iso9660 structure (where the sqfs files live) and in the booted LiveCD /setup directory is IMHO enough to identify the ISO release - either if the medium is only mounted or booted.
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.
We could try it - getting around 4 names in a year shouldn't be a big problem for us. Otherside this could probably be a good point were the users could come into game, they could make proposals about the next names. Gerhard
Am Mon, 2 Feb 2009 11:44:30 +0100 schrieb Gerhard Brauer <gerbra@archlinux.de>:
We could try it - getting around 4 names in a year shouldn't be a big problem for us. Otherside this could probably be a good point were the users could come into game, they could make proposals about the next names.
And doing a little joking (I'm happy cause my new PC arrives tomorrow!): To "honor" Debian a bit we could "name" our upcoming release 2009.01-½ (so we have the .01 even when releasing in .02)... <SCNR> ;-) Gerhard
Gerhard Brauer wrote:
Am Sun, 1 Feb 2009 21:42:02 +0100 schrieb Dieter Plaetinck <dieter@plaetinck.be>:
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:
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.
You're right, i don't mean to get these release numbers/names into the installed system - only a way to identify the ISO what the user currently is using. So Thayer's idea having the current iso version/name as a text file is good IMHO. Placing it in the iso9660 structure (where the sqfs files live) and in the booted LiveCD /setup directory is IMHO enough to identify the ISO release - either if the medium is only mounted or booted.
Some random thoughts: if you do `uname -r` you know the kernel release. eg 2.6.28-ARCH: not the arch release version/name, but close. Maybe we could version our releases like the kernel. eg 2.6.28 instead of 2009.01 that what we can show the "release version" at many places (inside installer, in /etc/rc.sysinit etc) in a bit easier way. also, it wouldn't cause so much stress when we change months, eg no stress about us being late, the need to change version numbers etc (eg right now we have 2009.01-beta and alpha, but the release is 2009.02, we need to update all references such as versions in flyspray, etc) Dieter
Hi, folks! why don't we put "Arch Linux 2009.01" on /etc/arch-release and /etc/issue, and update it only when the filesystem is updated or when a new ISO is released? Leandro "skate_forever" Inácio Arch Linux User Arch Linux http://www.archlinux.org Arch Linux Brasil http://www.archlinux-br.org 2009/2/2 Dieter Plaetinck <dieter@plaetinck.be>
Gerhard Brauer wrote:
Am Sun, 1 Feb 2009 21:42:02 +0100 schrieb Dieter Plaetinck <dieter@plaetinck.be>:
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:
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.
You're right, i don't mean to get these release numbers/names into the installed system - only a way to identify the ISO what the user currently is using. So Thayer's idea having the current iso version/name as a text file is good IMHO. Placing it in the iso9660 structure (where the sqfs files live) and in the booted LiveCD /setup directory is IMHO enough to identify the ISO release - either if the medium is only mounted or booted.
Some random thoughts: if you do `uname -r` you know the kernel release. eg 2.6.28-ARCH: not the arch release version/name, but close. Maybe we could version our releases like the kernel. eg 2.6.28 instead of 2009.01 that what we can show the "release version" at many places (inside installer, in /etc/rc.sysinit etc) in a bit easier way. also, it wouldn't cause so much stress when we change months, eg no stress about us being late, the need to change version numbers etc (eg right now we have 2009.01-beta and alpha, but the release is 2009.02, we need to update all references such as versions in flyspray, etc) Dieter
On Mon, Feb 2, 2009 at 7:34 AM, Leandro Inacio <carvalho.inacio@gmail.com> wrote:
Hi, folks!
why don't we put "Arch Linux 2009.01" on /etc/arch-release and /etc/issue, and update it only when the filesystem is updated or when a new ISO is released?
Because we used to do this and people start taking version numbers seriously. You get bug reports that say "I'm running ArchLinux 2008.10" or something insanely stupid. I can't stress how much I _do not_ want to get back to that. That's the sole reason I didn't want to put a version on the ISO really, because people would say things like "I installed 2008.06, do I need to reinstall?"
On Wed, Feb 4, 2009 at 3:18 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Feb 2, 2009 at 7:34 AM, Leandro Inacio <carvalho.inacio@gmail.com> wrote:
Hi, folks!
why don't we put "Arch Linux 2009.01" on /etc/arch-release and /etc/issue, and update it only when the filesystem is updated or when a new ISO is released?
Because we used to do this and people start taking version numbers seriously. You get bug reports that say "I'm running ArchLinux 2008.10" or something insanely stupid. I can't stress how much I _do not_ want to get back to that.
That's the sole reason I didn't want to put a version on the ISO really, because people would say things like "I installed 2008.06, do I need to reinstall?"
LOL that's sad, but I can totally see that happening! Oy but I do hate code names too...
On Wed, 4 Feb 2009 17:18:31 -0800 Thayer Williams <thayerw@gmail.com> wrote:
On Wed, Feb 4, 2009 at 3:18 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Feb 2, 2009 at 7:34 AM, Leandro Inacio <carvalho.inacio@gmail.com> wrote:
Hi, folks!
why don't we put "Arch Linux 2009.01" on /etc/arch-release and /etc/issue, and update it only when the filesystem is updated or when a new ISO is released?
Because we used to do this and people start taking version numbers seriously. You get bug reports that say "I'm running ArchLinux 2008.10" or something insanely stupid. I can't stress how much I _do not_ want to get back to that.
That's the sole reason I didn't want to put a version on the ISO really, because people would say things like "I installed 2008.06, do I need to reinstall?"
LOL that's sad, but I can totally see that happening! Oy but I do hate code names too...
So many things have been mixed up in the mails recently... 1) arch VERSION scheme eg 2009.01, 2009-2.6.28 etc. My personal view is we should stick to the current scheme but _not_ be too pedantic (eg if you're a bit late you don't need to change names, like which was the case now. I would just keep calling the release 2009.01 even if we release it in february, because that keeps things easier and no-one should care too much anyway) I do not think a version belongs in the target system at all, because Arch just doesn't work like that. (but install cd's are "snapshots" so I think they make sense there) 2) codenames (like "Don't panic") : * on the livecd * on the target system Imho they may be a nice addition to the livecd (not target system), although I also don't think they are very important. If it's easy doable to put it in /etc/release, /etc/rc.sysinit and in the installer menu on the livecd I would do it. If it makes things too complicated let's not bother at all. 3) "marketing"
b) Release "branding" I don't like branding each release. It's a focus on marketing and not on technical pursuits. If we're telling people to use the new ISO because it has a better name, and not because it was actually improved, then we've failed.
I agree, release naming/branding should never be about marketing. Until now I never even thought about it in a marketing-way. (as I think so do most people) Dieter
On Sun, Feb 1, 2009 at 10:52 AM, Gerhard Brauer <gerbra@archlinux.de> wrote:
a) Number of different ISOs/Images:
While you are pro-isolinux, I am pro-grub. I think isolinux is crap and is very inflexible, whereas grub allows us to do much more. For the record, there is hardware that isolinux images fail on too. Regarding our sheer number of ISOs, I would prefer reducing it by providing only ONE iso (the current 'ftp' ISO) and providing additional images that just contain packages. We'd need some functionality in the installer to swap out disks, though. That cuts our images in half. Even if that's the only change we make, it's huge. 1 usb image, 1 iso image, for each arch = 4 images 2 isolinux images = 6 basic images 1 package iso image, 1 package iso = 2 package sets --- 8 images Additionally, releasing dual arch ISOs would be a good idea, but it effectively doubles the size of the images. I would prefer releasing only an i686 ISO, and giving it the ability to install an x86_64 system *if* the hardware supports it. I've been thinking about this a little and have some ideas going forward. This would shrink the above down to 3 basic images, and 2 images that contain packages.
b) Release "branding" I don't like branding each release. It's a focus on marketing and not on technical pursuits. If we're telling people to use the new ISO because it has a better name, and not because it was actually improved, then we've failed.
c) Installer switch Yes, after this is out, we should officially deprecate the archlinux-installer in favor of AIF.
d) Accessibility support on install mediums I would love to be able to support this on our normal install mediums, but I wonder if adding additional features that require things enabled is going to make it difficult. i.e. if a grub param needs to be added to start espeakup (or whatever it's called), is this going to be HARDER for a blind user?
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.
I plan on adding information of this sort to the archiso docs, and including that in the git repo. Keep in mind that I will be releasing an archiso 1.0 package once we get this ISO out the door.
participants (5)
-
Aaron Griffin
-
Dieter Plaetinck
-
Gerhard Brauer
-
Leandro Inacio
-
Thayer Williams