Am 25.06.2012 00:49, schrieb Dieter Plaetinck: > On Sat, 23 Jun 2012 21:14:23 +0200 > Pierre Schmitz <[email protected]> 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
