FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 06-23-2012, 07:32 PM
Tom Gundersen
 
Default New install iso - proof of concept

On Sat, Jun 23, 2012 at 9:14 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
> it being discussed o IRC for some time now but I guess it's a good idea
> to sum our current progress up. I'll also add a few suggestions about
> how we might improve our iso releases.
>
> I created a testing iso which can be found at:
> http://pkgbuild.com/~pierre/ Besides the patches I had sent to the
> releng list it includes pacman-key from Allans working repo and Dave's
> arch-install-scripts. In addition to an updated set of packages another
> noticeable change is that signature verification is now supported and
> works out of the box. The keyring is initialized on boot and so you can
> install new packages within the live system as well.

Nice stuff. I have been testing Dave's arch-install-scripts and used
it for my latest install. Very convenient stuff, so having this on an
install medium would be great.

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

+1. I agree that this would speed up development, and hopefully also
lower the bar for contributing.

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

+1. Creating iso's with aif before it is ready will not do much good.
Provided that it is easy to "roll your own iso" it should still be
easy for people to test out the aif and contribute to it.

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

This sounds very useful.

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

Absolutely. iso's should be pushed out very frequently. We don't want
to worry about the most recent iso having bugs that have been fixed in
the repos, and (in case of core iso's, which I oppose anyway) we don't
want any user interaction to be required on the first update after
install (i.e. we should push a new iso whenever user interaction is
required).

-t
 
Old 06-24-2012, 01:39 AM
Gaetan Bisson
 
Default New install iso - proof of concept

[2012-06-23 21:14:23 +0200] Pierre Schmitz:
> * Decouple aif, install-scripts, archiso and actuall iso releases. This
> means have tags for those and provide packages in our repos.
> * 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.

That sounds great.

I would suggest that we hold off Dieter's call for help for now, and
wait until we can announce this ISO in the same news post. This should
give potential contributors a much clearer idea of where archiso and
friends are going, what parts of them need contributing, etc.

Cheers.

--
Gaetan
 
Old 06-24-2012, 10:49 PM
Dieter Plaetinck
 
Default New install iso - proof of concept

On Sat, 23 Jun 2012 21:14:23 +0200
Pierre Schmitz <pierre@archlinux.de> wrote:

> Hi all,
>
> it being discussed o IRC for some time now but I guess it's a good idea
> to sum our current progress up. I'll also add a few suggestions about
> how we might improve our iso releases.
>
> I created a testing iso which can be found at:
> http://pkgbuild.com/~pierre/ Besides the patches I had sent to the
> releng list it includes pacman-key from Allans working repo and Dave's
> arch-install-scripts. In addition to an updated set of packages another
> noticeable change is that signature verification is now supported and
> works out of the box. The keyring is initialized on boot and so you can
> install new packages within the live system as well.
>
> 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?)

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

> * 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)

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

http://www.archlinux.org/releng/feedback/ is a good tool to track that.

we've failed to achieve frequent releases basically because I can't keep up.


> I'll stop here to not make it too long and boring. What do you think?

I think this is all releng related and should go on the releng mailing list.

Dieter
 
Old 06-24-2012, 11:33 PM
Pierre Schmitz
 
Default New install iso - proof of concept

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
 
Old 06-25-2012, 08:30 AM
Thomas Bächler
 
Default New install iso - proof of concept

Am 23.06.2012 21:14, schrieb Pierre Schmitz:
> * 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.

I've been saying that for a long time, but Dieter always wanted to test
more thoroughly. ArchISO is a solid base for a live system and can be
booted in numerous different ways, which is all I personally care about.

All it takes is to move one of the automatic test builds
(https://releng.archlinux.org/isos/) to the mirrors and let them sync
(test builds stopped working, no idea why, this needs to be fixed -
Pierre, as you have started testing out stuff, I could give you
permissions on the releng machine so you can analyze the logs and fix
whatever is broken).

On another note: Once we have a recent build on the mirrors, we can
finally support netbooting the ISO properly (it works now, but the
download is too slow).
 
Old 06-25-2012, 10:14 AM
Dieter Plaetinck
 
Default New install iso - proof of concept

On Mon, 25 Jun 2012 10:30:47 +0200
Thomas Bächler <thomas@archlinux.org> wrote:

> Am 23.06.2012 21:14, schrieb Pierre Schmitz:
> > * 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.
>
> I've been saying that for a long time, but Dieter always wanted to test
> more thoroughly. ArchISO is a solid base for a live system and can be
> booted in numerous different ways, which is all I personally care about.
>
> All it takes is to move one of the automatic test builds
> (https://releng.archlinux.org/isos/) to the mirrors and let them sync

I just think that we should test all features that we officially support.
That's basically all it comes down to.
If we support any installer (whether it is aif or Dave's scripts), than we should make sure that
it works for every release.
Booting an installation medium and finding out that a feature is broken is much more painful than
using an outdated iso which gives you a system that needs manual intervention on update.

If we don't have the manpower to be able to do that (as is the case now),
we can just support less things (like, don't officially support aif as long as there's no manpower to maintain and test it)
that will allow us to release more often and with less testing.
 

Thread Tools




All times are GMT. The time now is 09:28 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org