Am 25.06.2012 00:49, schrieb Dieter Plaetinck:
On Sat, 23 Jun 2012 21:14:23 +0200 Pierre Schmitz <pierre@archlinux.de> wrote:
Overall I would suggest this: * Decouple aif, install-scripts, archiso and actuall iso releases. This means have tags for those and provide packages in our repos.
what exactly do you mean with this? these things are already "decoupled" in the sense that they are separate projects with separate releases. However, sometimes changes in one project require changes in another for example sometimes aif needs to be adjusted to work with archiso changes, the same will hold true for install-scripts I don't see how you can "decouple the projects" any more. (of course if we don't include aif on the iso, we don't need to care so much about updating aif after archiso changes, but I don't think that's what you're referring to here?)
Atm these projects at least look as they are tied together. I think we should still keep pushing out new isos even if there is no new aif or installer.
* It's not a bad thing to start off with an iso that does not include aif a first. This should actually speed up development and hopefully get us more help from the community.
I don't think including a broken aif per se is a bad thing, we should just be clear in the documentation and release announcement about its status, and be clear to our users about what we recommend and support. a few years ago we had the old installer on the iso + aif as beta/unsupported. If you want to attract more people to help out on archiso or install-scripts, that's all fine by me, but I doubt you'll get more help by merely not having aif on the iso. I would keep it on there, but mark it as outdated/unsupported as long as it's not properly maintained.
btw aif doesn't need much work to become non-broken, but there's not enough interest in it at the moment.
Depends on how broken aif is; I didn't really check that myself. If it just has some bugs in some use cases it is perfectly fine shipping it. If it is impossible to isntall a working system we should not put it on the iso. But we can put it on a month later once it is fixed for example. But even without aif a iso release could be very useful to find and fix bugs in archiso.
* archiso should be changed in a way that would allow anyone to easily create official isos with one command. It should result in the same iso no matter how the host is configured.
big +1; this would probably simplify http://projects.archlinux.org/users/dieter/releng.git/ as well. I've never felt entirely comfortable dealing with the whole iso building process, precisely because it's depending on "hidden" factors of the host OS. (probably only pacman.conf but what do I know)
Good thing is we already solved some of these issues in devtools, so we should be able to adapt those. The influences of the host system are mostly fixed now.
* We should treat the iso more like our other package and not aim for the most perfect product. Instead let's release new isos regularly; e.g. every month.
this is nothing new. this has always been the idea, but some level of testing is *always* needed, we should never publish broken images. better to have images that are a bit older than images that have bugs that prevent installation on a specific architecture, installation medium, etc. a user should never have to download an iso, only to find out something is broken during the installation process.
Old images are quite problematic. We often require user interaction on updates; which can be really annoying if the pile up over a year. And more important: you might just need a new kernel to support your hardware. As I already said above, we should regular release new images with the same version of the installer if there is no newer available. These images wont need a lot of testing. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com