On Mon, 03 Jan 2011 16:39:21 +0100 Thomas Bächler <thomas@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.