[arch-releng] from now on: automatic testbuilds + heads-up on changes

[Dieter Plaetinck]

On Mon, 03 Jan 2011 16:39:21 +0100
Thomas Bächler <thomas at archlinux.org> wrote:

> Am 03.01.2011 16:31, schrieb Dieter Plaetinck:
> > Known issues:
> > - some kind of kernel/vbox bug wrt virtual memory:
> > http://mailman.archlinux.org/pipermail/arch-general/2011-January/017713.html
> 
> Vbox always did weird and unexplainable things that I could never work
> around, other than upgrading either Linux or Vbox.. You will probably
> notice that KVM works fine.

I don't have virtualisation extensions on my cpu.  last time i tried
qemu it was much buggier then vbox ;)

> > - btrfs-progs, nilfs-utils and dosfstools packages cannot be
> > installed to the target system (although you should be able to use
> > those FS'es fine)
> 
> That reminds me, I was going to reply to the whole core-repo
> definition discussion. Anyway, those need to go to core if you want
> to install them upon installation.

please tell the responsible package maintainers.
 
> I am confused about dosfstools, there is no fsck tool that does
> anything useful, so installing them is not really a requirement.

> > 2) automatic builds: from now on, there will be automatic builds
> > available @ http://releng.archlinux.org/isos/
> > i'm still playing around with the parameters, probably the builds
> > will be daily or weekly.
> 
> In the long run, I'd say weekly.
> 
> > - some kind of web app /wiki page where users can mark things in the
> >   checklist as "working with testbuild $version" ?  that would give
> > a good indication of when we can promote testbuilds to official
> > releases
> 
> Official releases? I thought we'd be rolling (=snapshotting) releases
> from now on.

It is very easy to break an image, be it a change (~git commit) in the
releng env, in archiso or in aif.  I think this is fine (it allows me
to develop quickly), but this also means there can be big differences
in quality between builds. I only want selected high-quality releases
as default download option for the large audience, because
$random_build might be buggy or not even boot.
there needs to be a way to separate crappy builds from good ones.
call it staging vs production, or testing vs main, or autobuilds vs
releases, but there needs to be a way to separate them.  this approach
would allow that in a non-intrusive and relatively elegant way, I think.
It's basically the same as we did before (send mails where you say
"please test these builds and check item foo and bar" and people reply),
but improved because
1)you can see the current state of things more clearly
2)if feature X worked 2 builds ago, and only unrelated things have
changed, that's still valid as a "signoff".

Last time I spoke with Aaron, he also said there should be a way to
promote images when they deserve it, and offer those as official images.

> 
> > - some way to give these more visibility (post to al.org frontpage?
> >   can we mirror first?..?)
> 
> Following what I said above, revamp the download page to point to
> releng.al.org for ISO downloads.
>