diff options
| -rw-r--r-- | examples/README.txt | 113 | ||||
| -rw-r--r-- | examples/livecd-stage1_template.spec.txt | 74 | ||||
| -rw-r--r-- | examples/livecd-stage2_template.spec.txt | 309 | ||||
| -rw-r--r-- | examples/packagecd_template.spec.txt | 100 | ||||
| -rw-r--r-- | meeting-logs/20080123_initial_2008.0.txt | 834 | ||||
| -rw-r--r-- | meeting-logs/20080123_initial_2008.0_summary.txt | 139 |
6 files changed, 1569 insertions, 0 deletions
diff --git a/examples/README.txt b/examples/README.txt new file mode 100644 index 0000000..0f052ff --- /dev/null +++ b/examples/README.txt @@ -0,0 +1,113 @@ + +This file lists the possible command line options that can be used to tweak +the boot process of this CD. This lists the Gentoo-specific options, along +with a few options that are built-in to the kernel, but that have been proven +very useful to our users. Also, all options that start with "do" have a "no" +inverse, that does the opposite. For example, "doscsi" enables SCSI support +in the initial ramdisk boot, while "noscsi" disables it. + +Hardware options: + +acpi=on This loads support for ACPI and also causes the acpid daemon to + be started by the CD on boot. This is only needed if your + system requires ACPI to function properly. This is not required + for Hyperthreading support. +acpi=off Completely disables ACPI. This is useful on some older systems, + and is also a requirement for using APM. This will disable any + Hyperthreading support of your processor. +console=X This sets up serial console access for the CD. The first + option is the device, usually ttyS0 on x86, followed by any + connection options, which are comma separated. The default + options are 9600,8,n,1. +dmraid=X This allows for passing options to the device-mapper RAID + subsystem. Options should be encapsulated in quotes. +doapm This loads APM driver support. This requires you to also use + acpi=off. +dopcmcia This loads support for PCMCIA and Cardbus hardware and also + causes the pcmcia cardmgr to be started by the CD on boot. + This is only required when booting from a PCMCIA/Cardbus device. +doscsi This loads support for most SCSI controllers. This is also a + requirement for booting most USB devices, as they use the SCSI + subsystem of the kernel. +hda=stroke This allows you to partition the whole hard disk even when your + BIOS is unable to handle large disks. This option is only used + on machines with an older BIOS. Replace hda with the device + that is requiring this option. +ide=nodma This forces the disabling of DMA in the kernel and is required + by some IDE chipsets and also by some CDROM drives. If your + system is having trouble reading from your IDE CDROM, try this + option. This also disables the default hdparm settings from + being executed. +noapic This disables the Advanced Programmable Interrupt Controller + that is present on newer motherboards. It has been known to + cause some problems on older hardware. +nodetect This disables all of the autodetection done by the CD, including + device autodetection and DHCP probing. This is useful for doing + debugging of a failing CD or driver. +nodhcp This disables DHCP probing on detected network cards. This is + useful on networks with only static addresses. +nodmraid Disables support for device-mapper RAID, such as that used for + on-board IDE/SATA RAID controllers. +nofirewire This disables the loading of Firewire modules. This should only + be necessary if your Firewire hardware is causing a problem with + booting the CD. +nogpm This diables gpm console mouse support. +nohotplug This disables the loading of the hotplug and coldplug init + scripts at boot. This is useful for doing debugging of a + failing CD or driver. +nokeymap This disables the keymap selection used to select non-US + keyboard layouts. +nolapic This disables the local APIC on Uniprocessor kernels. +nosata This disables the loading of Serial ATA modules. This is useful + if your system is having problems with the SATA subsystem. +nosmp This disables SMP, or Symmetric Multiprocessing, on SMP-enabled + kernels. This is useful for debugging SMP-related issues with + certain drivers and motherboards. +nosound This disables sound support and volume setting. This is useful + for systems where sound support causes problems. +nousb This disables the autoloading of USB modules. This is useful + for debugging USB issues. + +Volume/Device Management: + +dodevfs This enables the deprecated device filesystem on 2.6 systems. + You will also need to use noudev for this to take effect. + Since devfs is the only option with a 2.4 kernel, this option + has no effect if booting a 2.4 kernel. +doevms2 This enables support for IBM's pluggable EVMS, or Enterprise + Volume Management System. This is not safe to use with lvm2. +dolvm2 This enables support for Linux's Logical Volume Management. + This is not safe to use with evms2. +noudev This disables udev support on 2.6 kernels. This option requires + that dodevfs is used. Since udev is not an option for 2.4 + kernels, this options has no effect if booting a 2.4 kernel. +unionfs Enables support for Unionfs on supported CD images. This will + create a writable Unionfs overlay in a tmpfs, allowing you to + change any file on the CD. +unionfs=X Enables support for Unionfs on supported CD images. This will + create a writable Unionfs overlay on the device you specify. + The device must be formatted with a filesystem recognized and + writable by the kernel. + +Other options: + +debug Enables debugging code. This might get messy, as it displays + a lot of data to the screen. +docache This caches the entire runtime portion of the CD into RAM, which + allows you to umount /mnt/cdrom and mount another CDROM. This + option requires that you have at least twice as much available + RAM as the size of the CD. +noload=X This causes the initial ramdisk to skip the loading of a + specific driver that may be causing a problem. Replace X with + the driver name. Multiple drivers can be specified by a + comma-separated list. +nox This causes an X-enabled LiveCD to not automatically start X, + but rather, to drop to the command line instead. +scandelay This causes the CD to pause for 10 seconds during certain + portions the boot process to allow for devices that are slow to + initialize to be ready for use. +scandelay=X This allows you to specify a given delay, in seconds, to be + added to certain portions of the boot process to allow for + devices that are slow to initialize to be ready for use. + Replace X with the number of seconds to pause. + diff --git a/examples/livecd-stage1_template.spec.txt b/examples/livecd-stage1_template.spec.txt new file mode 100644 index 0000000..e09c1ea --- /dev/null +++ b/examples/livecd-stage1_template.spec.txt @@ -0,0 +1,74 @@ +# livecd-stage1 example specfile +# used to build a livecd-stage1 + +# The subarch can be any of the supported catalyst subarches (like athlon-xp). +# Refer to the catalyst reference manual for suppurted subarches. +# http://www.gentoo.org/proj/en/releng/catalyst/reference.xml +# example: +# subarch: athlon-xp +subarch: + +# The version stamp is an identifier for the build. It can be anything you wish# it to be, but it is usually a date. +# example: +# version_stamp: 2005.0 +version_stamp: + +# The target specifies what target we want catalyst to do. For building a CD, +# we start with livecd-stage1 as our target. +# example: +# target: livecd-stage1 +target: + +# The rel_type defines what kind of build we are doing. This is merely another +# identifier, but it useful for allowing multiple concurrent builds. Usually, +# default will suffice. +# example: +# rel_type: default +rel_type: + +# This is the system profile to be used by catalyst to build this target. It is# specified as a relative path from /usr/portage/profiles. +# example: +# profile: default-linux/x86/2005.0 +profile: + +# This specifies which snapshot to use for building this target. +# example: +# snapshot: 20050324 +snapshot: + +# This specifies where the seed stage comes from for this target, The path is +# relative to $clst_sharedir/builds. The rel_type is also used as a path prefix# for the seed. +# example: +# default/stage3-x86-2004.3 +source_subpath: + +# These are the hosts used as distcc slaves when distcc is enabled in your +# catalyst.conf. It follows the same syntax as distcc-config --set-hosts and +# is entirely optional. +# example: +# distcc_hosts: 127.0.0.1 192.168.0.1 +distcc_hosts: + +# This is an optional directory containing portage configuration files. It +# follows the same syntax as /etc/portage and should be consistent across all +# targets to minimize problems. +# example: +# portage_confdir: /etc/portage +portage_confdir: + +# The livecd-stage1 target is where you will build packages for your CD. These +# packages can be built with customized USE settings. The settings here are +# additive to the default USE configured by the profile. For building release +# media, the first thing we do is disable all default USE flags with -* and then +# begin to set our own. +# example: +# livecd/use: -* ipv6 socks5 livecd fbcon ncurses readline ssl +livecd/use: + +# This is the set of packages that we will merge into the CD's filesystem. They +# will be built with the USE flags configured above. These packages must not +# depend on a configured kernel. If the package requires a configured kernel, +# then it will be defined elsewhere. +# example: +# livecd/packages: livecd-tools dhcpcd acpid apmd gentoo-sources kudzu-knoppix hotplug coldplug fxload irssi gpm syslog-ng parted links raidtools dosfstools nfs-utils jfsutils xfsprogs e2fsprogs reiserfsprogs ntfsprogs pwgen rp-pppoe screen mirrorselect penggy iputils hwdata-knoppix hwsetup lvm2 evms vim pptpclient mdadm ethtool wireless-tools prism54-firmware wpa_supplicant +livecd/packages: diff --git a/examples/livecd-stage2_template.spec.txt b/examples/livecd-stage2_template.spec.txt new file mode 100644 index 0000000..719639f --- /dev/null +++ b/examples/livecd-stage2_template.spec.txt @@ -0,0 +1,309 @@ +# livecd-stage2 example specfile +# used to build a livecd-stage2 iso image + +# The subarch can be any of the supported catalyst subarches (like athlon-xp). +# Refer to the catalyst reference manual for suppurted subarches. +# http://www.gentoo.org/proj/en/releng/catalyst/reference.xml +# example: +# subarch: athlon-xp +subarch: + +# The version stamp is an identifier for the build. It can be anything you wish# it to be, but it is usually a date. +# example: +# version_stamp: 2005.0 +version_stamp: + +# The target specifies what target we want catalyst to do. For building a CD, +# we continue with livecd-stage2 as the target. +# example: +# target: livecd-stage2 +target: + +# The rel_type defines what kind of build we are doing. This is merely another +# identifier, but it useful for allowing multiple concurrent builds. Usually, +# default will suffice. +# example: +# rel_type: default +rel_type: + +# This is the system profile to be used by catalyst to build this target. It is# specified as a relative path from /usr/portage/profiles. +# example: +# profile: default-linux/x86/2005.0 +profile: + +# This specifies which snapshot to use for building this target. +# example: +# snapshot: 20050324 +snapshot: + +# This specifies where the seed stage comes from for this target, The path is +# relative to $clst_sharedir/builds. The rel_type is also used as a path prefix# for the seed. +# example: +# default/livecd-stage1-x86-2004.3 +source_subpath: + +# These are the hosts used as distcc slaves when distcc is enabled in your +# catalyst.conf. It follows the same syntax as distcc-config --set-hosts and +# is entirely optional. +# example: +# distcc_hosts: 127.0.0.1 192.168.0.1 +distcc_hosts: + +# This is an optional directory containing portage configuration files. It +# follows the same syntax as /etc/portage and should be consistent across all +# targets to minimize problems. +# example: +# portage_confdir: /etc/portage +portage_confdir: + +# The cdfstype is used to determine what sort of CD we should build. This is +# used to set the type of loopback filesystem that we will use on our CD. +# Possible options are as follows: +# squashfs - This gives the best compression, but requires a kernel patch. +# zisofs - This uses in-kernel compression and is supported on all platforms. +# normal - This creates a loop without compression. +# noloop - This copies the files to the CD directly, withuot using a loopback. +# example: +# livecd/cdfstype: squashfs +livecd/cdfstype: + +# The archscript is for architecture-dependent configuration. Not all Gentoo +# architectures use their own archscript. Some share with other architectures +# that are similar. +# example: +# livecd/archscript: /usr/lib/catalyst/livecd/runscript/x86-archscript.sh +livecd/archscript: + +# The runscript is the "brains" of the livecd-stage2 target and is designed to +# be architecturer agnostic. It is best not to change this. +# example: +# livecd/runscript: /usr/lib/catalyst/livecd/runscript/default-runscript.sh +livecd/runscript: + +# The cdtar is essentially the bootloader for the CD. It also holds the main +# configuration for the bootloader. On x86/amd64, it also can include a small +# memory testing application, called memtest86+. +# example: +# livecd/cdtar: /usr/lib/catalyst/livecd/cdtar/isolinux-2.13-memtest86+-cdtar.tar.bz2 +livecd/cdtar: + +# This is the full path and filename to the ISO image that the livecd-stage2 +# target will create. +# example: +# livecd/iso: /tmp/installcd-x86-minimal.iso +livecd/iso: + +# A fsscript is simply a shell script that is copied into the chroot of the CD +# after the kernel(s) and any external modules have been compiled and is +# executed within the chroot. It can contain any commands that are available +# via the packages installed by our stages or by the packages installed during +# the livecd-stage1 build. We do not use one for the official release media, so +# there will not be one listed below. The syntax is simply the full path and +# filename to the shell script that you wish to execute. The script is copied +# into the chroot by catalyst automatically. +# example: +# livecd/fsscript: +livecd/fsscript: + +# The splash type determines the automatic arguments for the bootloader on +# supported architectures. The possible options are gensplash and bootsplash. +# example: +# livecd/splash_type: gensplash +livecd/splash_type: + +# This is where you set the splash theme. This theme must be present in either +# /etc/splash or /etc/bootsplash, depending on your livecd/splash_type, before +# the kernel has completed building during the livecd-stage2 target. +# example: +# livecd/splash_theme: livecd-2005.0 +livecd/splash_theme: + +# This is a set of arguments that get passed to the bootloader for your CD. It +# is used on the x86/amd64 release media to enable keymap selection. +# example: +# livecd/bootargs: dokeymap +livecd/bootargs: + +# This is a set of arguments that will be passed to genkernel for all kernels +# defined in this target. It is useful for passing arguments to genkernel that +# are not otherwise available via the livecd-stage2 spec file. +# example: +# livecd/gk_mainargs: --lvm2 --dmraid +livecd/gk_mainargs: + +# This option allows you to specify your own linuxrc script for genkernel to use# when building your CD. This is not checked for functionality, so it is up to +# you to debug your own script. We do not use one for the official release +# media, so there will not be one listed below. +# example: +# livecd/linuxrc: +livecd/linuxrc: + +# This option controls quite a bit of catalyst internals and sets up several +# defaults. Each type behaves slightly differently and is explained below. +# gentoo-release-minimal - This creates an official minimal InstallCD. +# gentoo-release-universal - This creates an official universal InstallCD. +# gentoo-release-livecd - This creates an official LiveCD environment. +# gentoo-gamecd - This creates an official Gentoo GameCD. +# generic-livecd - This should be used for all non-official media. +# example: +# livecd/type: gentoo-release-minimal +livecd/type: + +# This is for the CD's message of the day. It is not required for official +# release media, as catalyst builds a default motd when the livecd/type is set +# to one of the gentoo-* options. This setting overrides the default motd even +# on official media. Since we do not use this for the official releases, it is +# left blank below. +# example: +# livecd/motd: +livecd/motd: + +# This is for blacklisting modules from being hotplugged that are known to cause +# problems. Putting a module name here will keep it from being auto-loaded, +# even if ti is detected by hotplug. +# example: +# livecd/modblacklist: 8139cp +livecd/modblacklist: + +# This is for adding init scripts to runlevels. The syntax for the init script +# is the script name, followed by a pipe, followed by the runlevel in which you +# want the script to run. It looks like spind|default and is space delimited. +# We do not use this on the official media, as catalyst sets up the runlevels +# correctly for us. Since we do not use this, it is left blank below. +# example: +# livecd/rcadd: +livecd/rcadd: + +# This is for removing init script from runlevels. It is executed after the +# defaults shipped with catalyst, so it is possible to remove the defaults using +# this option. It can follow the same syntax as livcd/rcadd, or you can leave +# the runlevel off to remove the script from any runlevels detected. We do not +# use this on the official media, so it is left blank. +# example: +# livecd/rcdel: +livecd/rcdel: + +# This overlay is dropped onto the CD filesystem and is outside any loop which +# has been configured. This is typically used for adding the documentation, +# distfiles, snapshots, and stages to the official media. These files will not +# be available if docache is enabled, as they are outside the loop. +# example: +# livecd/overlay: /tmp/overlay-minimal +livecd/overlay: + +# This overlay is dropped onto the filesystem within the loop. This can be used +# for such things as updating configuration files or adding anything else you +# would want within your CD filesystem. Files added here are available when +# docache is used. We do not use this on the official media, so we will leave +# it blank below. +# example: +# livecd/root_overlay: +livecd/root_overlay: + +# This is here to enable udev support in both catalyst and genkernel. This +# option requires genkernel >= 3.1.0, and is not needed with genkernel >=3.2.0, +# as udev is the default. +# example: +# livecd/devmanager: udev +livecd/devmanager: + +# This is used by catalyst to copy the specified file to /etc/X11/xinit/xinitrc +# and is used by the livecd/type gentoo-gamecd and generic-livecd. While the +# file will still be copied for any livecd/type, catalyst will only create the +# necessary /etc/startx for those types, so X will not be automatically started. +# This is useful also for setting up X on a CD where you do not wish X to start +# automatically. We do not use this on the release media, so it is left blank. +# example: +# livecd/xinitrc: +livecd/xinitrc: + +# This option is used to create non-root users on your CD. It takes a space +# separated list of user names. These users will be added to the following +# groups: users,wheel,audio,games,cdrom,usb +# If this is specified in your spec file, then the first user is also the user +# used to start X. Since this is not used on the release media, it is blank. +# example: +# livecd/users: +livecd/users: + +# This option sets the volume ID of the CD created. +# example: +# livecd/volid: Gentoo Linux 2005.0 X86 +livecd/volid: + +# This option is only used when creating a GameCD. This specifies the file that +# contains the definitions for GAME_NAME and GAME_EXECUTABLE, which are used by +# the GameCD scripts to set some specific options for the game. This is not +# used on the release media, and is therefore blank. +# example: +# gamecd/conf: +gamecd/conf: + +# This option is used to specify the number of kernels to build and also the +# labels that will be used by the CD bootloader to refer to each kernel image. +# example: +# boot/kernel: gentoo +boot/kernel: + +# This option tells catalyst which kernel sources to merge for this kernel +# label. This can use normal portage atoms to specify a specific version. +# example: +# boot/kernel/gentoo/sources: gentoo-sources +boot/kernel/gentoo/sources: + +# This option is the full path and filename to a kernel .config file that is +# used by genkernel to compile the kernel this label applies to. +# example: +# boot/kernel/gentoo/config: /tmp/2.6.11-smp.config +boot/kernel/gentoo/config: + +# This option sets genkernel parameters on a per-kernel basis and applies only +# to this kernel label. This can be used for building options into only a +# single kernel, where compatibility may be an issue. Since we do not use this +# on the official release media, it is left blank, but it follows the same +# syntax as livecd/gk_mainargs. +# example: +# boot/kernel/gentoo/gk_kernargs: +boot/kernel/gentoo/gk_kernargs: + +# This option sets the USE flags used to build the kernel and also any packages +# which are defined under this kernel label. These USE flags are additive from +# the default USE for the specified profile. +# example: +# boot/kernel/gentoo/use: pcmcia usb -X +boot/kernel/gentoo/use: + +# This option appends an extension to the name of your kernel, as viewed by a +# uname -r/ This also affects any modules built under this kernel label. This +# is useful for having two kernels using the same sources to keep the modules +# from overwriting each other. We do not use this on the official media, so it +# is left blank. +# example: +# boot/kernel/gentoo/extraversion: +boot/kernel/gentoo/extraversion: + +# This option is for merging kernel-dependent packages and external modules that +# are configured against this kernel label. +# example: +# boot/kernel/gentoo/packages: pcmcia-cs speedtouch slmodem globespan-adsl hostap-driver hostap-utils ipw2100 ipw2200 fritzcapi fcdsl cryptsetup +boot/kernel/gentoo/packages: + +# This is a list of packages that will be unmerged after all the kernels have +# been built. There are no checks on these packages, so be careful what you +# add here. They can potentially break your CD. +# example: +# livecd/unmerge: acl attr autoconf automake bin86 binutils libtool m4 bison ld.so make perl patch linux-headers man-pages sash bison flex gettext texinfo ccache distcc addpatches man groff lib-compat miscfiles rsync sysklogd bc lcms libmng genkernel diffutils libperl gnuconfig gcc-config gcc bin86 cpio cronbase ed expat grub lilo help2man libtool gentoo-sources +livecd/unmerge: + +# This option is used to empty the directories listed. It is useful for getting +# rid of files that don't belong to a particular package, or removing files from +# a package that you wish to keep, but won't need the full functionality. +# example: +# livecd/empty: /var/tmp /var/cache /var/db /var/empty /var/lock /var/log /var/run /var/spool /var/state /tmp /usr/portage /usr/share/man /usr/share/info /usr/share/unimaps /usr/include /usr/share/zoneinfo /usr/share/dict /usr/share/doc /usr/share/ss /usr/share/state /usr/share/texinfo /usr/lib/python2.2 /usr/lib/portage /usr/share/gettext /usr/share/i18n /usr/share/rfc /usr/lib/X11/config /usr/lib/X11/etc /usr/lib/X11/doc /usr/src /usr/share/doc /usr/share/man /root/.ccache /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /etc/logrotate.d /etc/rsync /usr/lib/awk /usr/lib/ccache /usr/lib/gcc-config /usr/lib/nfs /usr/local /usr/diet/include /usr/diet/man /usr/share/consolefonts/partialfonts /usr/share/consoletrans /usr/share/emacs /usr/share/gcc-data /usr/share/genkernel /etc/bootsplash/gentoo /etc/bootsplash/gentoo-highquality /etc/splash/gentoo /etc/splash/emergence /usr/share/gnuconfig /usr/share/lcms /usr/share/locale /etc/skel +livecd/empty: + +# This option tells catalyst to clean specific files from the filesystem and is +# very usefu in cleaning up stray files in /etc left over after livecd/unmerge. +# example: +# livecd/rm: /lib/*.a /usr/lib/*.a /usr/lib/gcc-lib/*/*/libgcj* /etc/dispatch-conf.conf /etc/etc-update.conf /etc/*- /etc/issue* /etc/make.conf /etc/man.conf /etc/*.old /root/.viminfo /usr/sbin/bootsplash* /usr/sbin/fb* /usr/sbin/fsck.cramfs /usr/sbin/fsck.minix /usr/sbin/mkfs.minix /usr/sbin/mkfs.bfs /usr/sbin/mkfs.cramfs /lib/security/pam_access.so /lib/security/pam_chroot.so /lib/security/pam_debug.so /lib/security/pam_ftp.so /lib/security/pam_issue.so /lib/security/pam_mail.so /lib/security/pam_motd.so /lib/security/pam_mkhomedir.so /lib/security/pam_postgresok.so /lib/security/pam_rhosts_auth.so /lib/security/pam_userdb.so /usr/share/consolefonts/1* /usr/share/consolefonts/7* /usr/share/consolefonts/8* /usr/share/consolefonts/9* /usr/share/consolefonts/A* /usr/share/consolefonts/C* /usr/share/consolefonts/E* /usr/share/consolefonts/G* /usr/share/consolefonts/L* /usr/share/consolefonts/M* /usr/share/consolefonts/R* /usr/share/consolefonts/a* /usr/share/consolefonts/c* /usr/share/consolefonts/dr* /usr/share/consolefonts/g* /usr/share/consolefonts/i* /usr/share/consolefonts/k* /usr/share/consolefonts/l* /usr/share/consolefonts/r* /usr/share/consolefonts/s* /usr/share/consolefonts/t* /usr/share/consolefonts/v* /etc/splash/livecd-2005.0/16* /etc/splash/livecd-2005.0/12* /etc/splash/livecd-2005.0/6* /etc/splash/livecd-2005.0/8* /etc/splash/livecd-2005.0/images/silent-16* /etc/splash/livecd-2005.0/images/silent-12* /etc/splash/livecd-2005.0/images/silent-6* /etc/splash/livecd-2005.0/images/silent-8* /etc/splash/livecd-2005.0/images/verbose-16* /etc/splash/livecd-2005.0/images/verbose-12* /etc/splash/livecd-2005.0/images/verbose-6* /etc/splash/livecd-2005.0/images/verbose-8* /etc/make.conf.example /etc/make.globals /etc/resolv.conf +livecd/rm: diff --git a/examples/packagecd_template.spec.txt b/examples/packagecd_template.spec.txt new file mode 100644 index 0000000..7aea887 --- /dev/null +++ b/examples/packagecd_template.spec.txt @@ -0,0 +1,100 @@ +# generic GRP (Gentoo Reference Platform) specfile +# used to build a GRP set + +# The subarch can be any of the supported catalyst subarches (like athlon-xp). +# Refer to the catalyst reference manual for suppurted subarches. +# http://www.gentoo.org/proj/en/releng/catalyst/reference.xml +# example: +# subarch: athlon-xp +subarch: + +# The version stamp is an identifier for the build. It can be anything you wish# it to be, but it is usually a date. +# example: +# version_stamp: 2005.0 +version_stamp: + +# The target specifies what target we want catalyst to do. For GRP, the +# supported targets are: grp +# example: +# target: grp +target: grp + +# The rel_type defines what kind of build we are doing. This is merely another +# identifier, but it useful for allowing multiple concurrent builds. Usually, +# default will suffice. +# example: +# rel_type: default +rel_type: + +# This is the system profile to be used by catalyst to build this target. It is# specified as a relative path from /usr/portage/profiles. +# example: +# profile: default-linux/x86/2005.0 +profile: + +# This specifies which snapshot to use for building this target. +# example: +# snapshot: 20050324 +snapshot: + +# This specifies where the seed stage comes from for this target, The path is +# relative to $clst_sharedir/builds. The rel_type is also used as a path prefix# for the seed. +# example: +# default/stage3-x86-2004.3 +source_subpath: + +# These are the hosts used as distcc slaves when distcc is enabled in your +# catalyst.conf. It follows the same syntax as distcc-config --set-hosts and +# is entirely optional. +# example: +# distcc_hosts: 127.0.0.1 192.168.0.1 +distcc_hosts: + +# This is an optional directory containing portage configuration files. It +# follows the same syntax as /etc/portage and should be consistent across all +# targets to minimize problems. +# example: +# portage_confdir: /etc/portage +portage_confdir: + +# Since GRP is capable of building packages/source sets for more than one CD, +# this defines the layout for the directories under $clst_sharedir/builds. +# example: +# grp: src cd2 +grp: src cd2 + +# GRP is also able to build packages with customized USE settings. However, it +# is very possible to cause quite a few problems with these, so be careful with +# whatever USE flags you add here. This is generally used for adding some +# functionality that we do not want on by default for all Gentoo users, but that +# we want on by default in our binaries. Some examples would be things like the +# socks5 USE flag. +# example: +# grp/use: gtk2 gnome kde qt bonobo cdr esd gtkhtml mozilla mysql perl ruby tcltk cups ldap ssl tcpd -svga +grp/use: + +# This tells catalyst what type of GRP set this list of packages will create. +# Valid options here are srcset or pkgset to either download the source, or to +# build packages, respectively. +# example: +# grp/src/type: srcset +grp/src/type: + +# Since this is a srcset, these ebuilds will have their distfiles fetched and +# the distfiles will be stored in the src directory under $clst_sharedir/builds. +# Packages will not be made out of this list. We use this for grabbing things +# that need a compiled kernel to build, or things listed in the Handbook that +# should be available before the first reboot during an install. +# example: +# grp/src/packages: gentoo-sources udev vanilla-sources rp-pppoe speedtouch fcdsl fritzcapi globespan-adsl pptpclient slmodem lvm2 evms iputils vixie-cron fcron dcron sysklogd metalog syslog-ng raidtools jfsutils xfsprogs reiserfsprogs dosfstools ntfsprogs lilo grub isdn4k-utils iproute2 wireless-tools wpa_supplicant pcmcia-cs hotplug coldplug dhcpcd slocate genkernel ipw2100 ipw2200 fxload logrotate +grp/src/packages: + +# This is mostly here for completeness. This is the pkgset definition. +# example: +# grp/cd2/type: pkgset +grp/cd2/type: + +# This is our list of packages that will comprise our package set. These are +# fetched, compiled, and the packages are stored under $clst_sharedir/builds. +# example: +# grp/cd2/packages: dante tsocks sys-apps/eject minicom links acpid apmd parted whois tcpdump cvs zip unzip netcat partimage app-admin/sudo app-cdr/cdrtools gnome emacs dev-lang/ruby enlightenment kde mozilla-firefox mozilla-thunderbird xfce4 openbox fluxbox sylpheed openoffice-bin gimp xemacs xmms abiword gaim xchat pan tetex xcdroast k3b samba nmap gradm ettercap ethereal mplayer +grp/cd2/packages: diff --git a/meeting-logs/20080123_initial_2008.0.txt b/meeting-logs/20080123_initial_2008.0.txt new file mode 100644 index 0000000..4bfe14c --- /dev/null +++ b/meeting-logs/20080123_initial_2008.0.txt @@ -0,0 +1,834 @@ +Jan 23 12:11:07 <wolf31o2|work> ok... I guess we've waited long enough... let's get this started... first off, for all of you developers in here that aren't releng... please try to refrain from comments until the end... if you've got a question or feel like you definitely need to say something, do so, but try to hold off, since this meeting will likely be long enough as it is... +Jan 23 12:11:33 <wolf31o2|work> so... let's get this rolling +Jan 23 12:11:51 <wolf31o2|work> the first topic is 2008.0's release... +Jan 23 12:13:12 <wolf31o2|work> I was thinking of doing the initial snapshot on Feb 1... that would give us an approximate release around mid-March... +Jan 23 12:13:30 <wolf31o2|work> does that work for everyone? +Jan 23 12:13:36 <nightmorph> your docs liaison sez: works for me. when you need the HB tarballs? :) +Jan 23 12:14:21 <rangerpb> wolf31o2|work, works for me +Jan 23 12:14:27 <wolf31o2|work> nightmorph: by Feb 29, I'd say +Jan 23 12:14:29 <phreak``> wolf31o2|work: well, I hoped to have gcc-4 finally, but I think I can bury that thought along with some other things. but either way, its fine by me. +Jan 23 12:14:52 <dertobi123> i'm away on most weekends starting in mid-february until mid-march ... plus several events (fosdem, chemnitz, open-expo bern) are taking place ... not sure if that timeframe will work for me +Jan 23 12:15:00 <nightmorph> wolf31o2|work: sooo much time. i'm already letting the rest of the GDP do the docs work as it is :) +Jan 23 12:15:14 <nightmorph> reso worksforme +Jan 23 12:15:40 <dberkholz> sorry to interrupt, but is anyone else keeping a meeting summary? +Jan 23 12:15:51 <phreak``> dberkholz: well, I'm keeping the log :) +Jan 23 12:16:02 <drac> wolf31o2|work: xfce has only one bug that shouldn't go into release, i'm backporting the fix from upstream _now_ so it can be marked stable now (or in few days) +Jan 23 12:16:04 <agaffney> summary can be created from the log post-meeting :P +Jan 23 12:16:05 <wolf31o2|work> dertobi123: hrrrmn... OK... we're talking about 6 weeks of time... do you think it will be a problem, or... ? +Jan 23 12:16:16 <wolf31o2|work> drac: thanks +Jan 23 12:16:52 <nightmorph> drac: xfce is bug free! whatchu talkin' 'bout, willis +Jan 23 12:17:02 <dertobi123> wolf31o2|work: depends on how many unforseen problems we encounter ... if things go the easy i see no big problem ... if things won't ... +Jan 23 12:17:14 <dertobi123> the easy way* +Jan 23 12:17:53 <dertobi123> given the fact that every little stage-rebuild takes around 24h for each hppa1.1 and hppa2.0 +Jan 23 12:18:11 <wolf31o2|work> dertobi123: understandable... seems to be the status quo for releases, anyway... what machine are you using? +Jan 23 12:18:33 <Blackb|rd> wolf31o2|work: The nightmare month will be over for me, so I should have some time to spare to build alpha releases. We still have a nasty showstopper bug with 2.6.23.* and 2.6.24*, but we'll figure it out, I guess. +Jan 23 12:18:46 <dertobi123> wolf31o2|work: depends ... mostly hake (dev box at osl) plus my c3700 at home which is somewhat faster ... +Jan 23 12:19:31 <wolf31o2|work> one thing I would like to try to do this release is to have us build on developer machines, rather than our personal machines... this way someone else can help out easily if there's a problem with time/etc... so if we don't have access to sufficient hardware (as a dev box) I'd like to know... +Jan 23 12:19:41 <Blackb|rd> dertobi123: there *might* be free hardware availble soon thorugh one of my coworkers, I'll get back to you on that once something materializes. +Jan 23 12:19:51 <wolf31o2|work> dertobi123: would access to a J5600 help? I have one sitting at home +Jan 23 12:20:21 <agaffney> I think hppa SMP support is actually "working" these days +Jan 23 12:20:36 <dertobi123> wolf31o2|work: not sure ... smp isn't that stable (if stable at all) ... might be worth a try +Jan 23 12:20:40 <wolf31o2|work> Blackb|rd: there's an alpha machine available as a dev box to the alpha team, right? +Jan 23 12:20:54 <dertobi123> another option might be to get hosting for my c3700 somewhere nearby +Jan 23 12:21:04 <wolf31o2|work> dertobi123: OK... I'll pull the machine out and try to get it loaded up for you in the next few days... +Jan 23 12:21:16 <Blackb|rd> wolf31o2|work: Yes +Jan 23 12:21:18 <wolf31o2|work> I can host my box with my company, if you need it... so that's an option +Jan 23 12:21:21 <wolf31o2|work> Blackb|rd: k... +Jan 23 12:21:28 <dertobi123> wolf31o2|work: :) +Jan 23 12:21:29 <Blackb|rd> wolf31o2|work: the ES40 we spoke of. +Jan 23 12:21:34 <wolf31o2|work> right +Jan 23 12:21:35 <phreak``> wolf31o2|work: something differently. whats gonna be part of 2008.0 ? are we talking about the new profile layout there, or "just" a fresh snapshot w/ security fixes and the usual things ? +Jan 23 12:22:02 * nightmorph wasn't aware 2008 profiles even existed yet +Jan 23 12:22:10 <phreak``> nightmorph: they don't :) +Jan 23 12:22:40 <wolf31o2|work> phreak``: was going to get to that in just a second... I am not sure that we'll have time to do the profile switching... but I'm going to try to come up with it... the plan will be to create "normal" 2008.0 profiles, and I'll work on making them multi-parent and such... there's even already a multi-parent SVN repo out there... I just haven't thrown anything in it, yet +Jan 23 12:22:54 <agaffney> can we ban that guy (Hz_SNaKE and BillGates)? +Jan 23 12:23:14 <wolf31o2|work> agaffney: why? he's not doing anything... it's +m +Jan 23 12:23:16 <phreak``> wolf31o2|work: sorry for being jumpy then :) +Jan 23 12:23:24 <wolf31o2|work> phreak``: np... +Jan 23 12:23:27 * agaffney shrugs +Jan 23 12:23:42 <nightmorph> there's always ignore joins parts quits... +Jan 23 12:23:43 <wolf31o2|work> armin76: you've got dolphin and another box, right? (ia64) +Jan 23 12:24:28 <phreak``> just dolphin iirc +Jan 23 12:24:40 <wolf31o2|work> rangerpb: you have timberdoodle and another box, too, right? plus luna, for G4... +Jan 23 12:24:44 <wolf31o2|work> phreak``: k... +Jan 23 12:24:52 <phreak``> wolf31o2|work: its rooster now ;) +Jan 23 12:24:58 <phreak``> wolf31o2|work: timberdoodle is history :S +Jan 23 12:25:13 <wolf31o2|work> heh... OK +Jan 23 12:25:35 <nightmorph> wolf31o2|work: mind if i fix a typo on the releng project page? +Jan 23 12:25:48 <wolf31o2|work> armin76: also, you've got bender for sparc, right? +Jan 23 12:25:52 <nightmorph> phreak``'s role: "Hardended Liason" +Jan 23 12:25:54 * phreak`` kicks over the rocks armin76 and rangerpb are hiding beneath. +Jan 23 12:26:03 <wolf31o2|work> nightmorph: ehh, I'm going to update it after the meeting, anyway... +Jan 23 12:26:15 <nightmorph> okay. s/liason/liaison for all instances too :) +Jan 23 12:26:18 <phreak``> wolf31o2|work: he has. (armin that is) +Jan 23 12:27:03 <wolf31o2|work> k +Jan 23 12:27:03 <phreak``> nightmorph: fix me instead ... :P +Jan 23 12:27:19 <armin76> woot? +Jan 23 12:27:20 <armin76> yeah +Jan 23 12:27:39 <wolf31o2|work> k... I'll get w/ the spankster later on his boxes... we can continue +Jan 23 12:27:42 <armin76> wolf31o2|work: yes, dolphin and beluga (ia64) and bender for sparc +Jan 23 12:27:56 <wolf31o2|work> so... 2008.0... what do you guys want to do with it... is there anything special you'd like to see us do? +Jan 23 12:27:57 <phreak``> jaervosz: still here ? +Jan 23 12:28:13 <Blackb|rd> wolf31o2|work: let's finally get rid of 2.4 ;) +Jan 23 12:28:18 <phreak``> wolf31o2|work: gcc4 for me :P +Jan 23 12:28:24 <phreak``> Blackb|rd: that too. +Jan 23 12:28:35 <phreak``> Blackb|rd: which means, I do have to restructure profiles :| +Jan 23 12:28:36 <nightmorph> yay, no 2.4! makes it easier to maintain the docs +Jan 23 12:28:38 <jaervosz> phreak``: yeah +Jan 23 12:28:42 <dertobi123> phreak``: gcc4 for hardened? :) +Jan 23 12:28:44 <nightmorph> also, gentoo-sources on all arches where possible +Jan 23 12:28:51 * jaervosz reads backlog +Jan 23 12:28:55 <wolf31o2|work> I was planning on making a new sub-profile type (if we do multi-parent)... "developer" which would inherit both desktop and profile and set all the pretty "developer" FEATURES by default... +Jan 23 12:29:01 <agaffney> nightmorph: which arches aren't on gentoo-sources? +Jan 23 12:29:09 <Blackb|rd> Is any arch still depending heavily on 2.4? +Jan 23 12:29:18 <agaffney> heavily? probably not +Jan 23 12:29:19 <welp> wolf31o2|work: developer profile sounds awesome to me +Jan 23 12:29:23 <agaffney> but a few machines here and there +Jan 23 12:29:26 <armin76> agaffney: mips +Jan 23 12:29:41 <dertobi123> Blackb|rd: sparc32 ... which isn't maintained for years :P +Jan 23 12:29:43 <phreak``> Blackb|rd: none at all, besides mips and maybe some sparc's +Jan 23 12:29:47 <Blackb|rd> wolf31o2|work: devel profile++ +Jan 23 12:29:55 <phreak``> wolf31o2|work: sounds like a plan :D +Jan 23 12:29:56 <wolf31o2|work> Blackb|rd: not anymore... I think alpha/sparc are the few that still have some machines that don't work as well under 2.6 as 2.4, but that number is dwindling +Jan 23 12:30:01 <nightmorph> agaffney: mips, hppa, and alpha either have a non-gentoo-sources kernel, or else support one equally with gentoo-sources +Jan 23 12:30:10 <agaffney> nightmorph: hppa is now on gentoo-sources +Jan 23 12:30:12 <armin76> nightmorph: alpha doesn't +Jan 23 12:30:13 <nightmorph> sparc at least has said sparc-sources is deprecated, though still available. not recommended though +Jan 23 12:30:16 <nightmorph> oh? +Jan 23 12:30:19 <nightmorph> cool! +Jan 23 12:30:24 <nightmorph> that's new. /me notes that in the handbook changes +Jan 23 12:30:25 <agaffney> nightmorph: that's recent +Jan 23 12:30:37 <Blackb|rd> wolf31o2|work: We've retired 2.4 completely recently and haven't and any complaints (but von report froma very happy user who's now using 2.6) +Jan 23 12:30:49 <armin76> arm,mips,m68k,s390,sh are the ones that don't have gentoo-sources keyworded +Jan 23 12:30:56 <dertobi123> agaffney: as long as no pa-patches are releases ... i recall a thread on the parisc list that pa-patches shall be revived (but that was some months ago) +Jan 23 12:30:59 <agaffney> nightmorph: yeah, sparc is gentoo-sources, but sparc-sources is still there for people wanting 2.4 (like the crazy people still running sparc32 boxes) +Jan 23 12:31:02 <dertobi123> released* +Jan 23 12:31:10 <armin76> s390 and arm have 2.6.20 only +Jan 23 12:31:11 <nightmorph> agaffney: fortunately, sparc32 is not supported ;) +Jan 23 12:31:17 <agaffney> nightmorph: indeed :P +Jan 23 12:32:21 <wolf31o2|work> OK... so I'd also like to change a couple ways we do things... for one, as soon as we finish up a release, I'd like to go ahead and create the new release stuff in the repos... so the releng repo, we'd create the specs... in the tree, we create a new dev profile... I'd *like* to do the same w/ the Handbook, but that's up to the docs guys... the idea is that by doing this, we can update the profiles and such immediately, and it's +Jan 23 12:32:21 <wolf31o2|work> also useful for the next topic (automated builds), so I'll hold off until then... +Jan 23 12:32:53 <nightmorph> hmm, a profile for the handbook? whatcha mean? +Jan 23 12:33:27 <wolf31o2|work> no no... sorry... I mean as soon as we finished up 2008.0, we'd break off the 2008.1 draft... so we can make changes as we go so you don't end up with all the changes at the end +Jan 23 12:33:52 <wolf31o2|work> of course, in your case, it likely means having to update multiple handbooks, so if you'd prefer we just bug everything along the way, that's fine, too +Jan 23 12:33:57 <nightmorph> well...many of the changes afterward get merged into the current handbook +Jan 23 12:33:59 <Blackb|rd> wolf31o2|work: that'd also facilitate early tweaking which makes it easier to try out new stuff. +Jan 23 12:34:07 <nightmorph> we also keep a section on errata and changes since release +Jan 23 12:34:20 <nightmorph> but i see what you're saying +Jan 23 12:34:38 <wolf31o2|work> nightmorph: OK... so you already have a decent process in place... if we don't need to change anything there, we won't... +Jan 23 12:34:52 <wolf31o2|work> Blackb|rd: exactly... we can try out really stupid stuff along the way... +Jan 23 12:34:54 <nightmorph> wolf31o2|work: *shrug* our process is open to change +Jan 23 12:34:55 <wolf31o2|work> hehe +Jan 23 12:35:11 <agaffney> we like trying out really stupid stuff +Jan 23 12:35:20 <nightmorph> actually, if that rapid rolling release thing we talked about ever gets going, we won't have to worry about creating separate 200*.* dirs. which would be nice. +Jan 23 12:35:25 <phreak``> wolf31o2|work: +1 from me on that matter :P +Jan 23 12:35:33 <wolf31o2|work> nightmorph: honestly, you tell me if anything needs to change... the only other docs-related change I see is trying to force the handbook updates prior to the last minute (as has been the case for a long time) +Jan 23 12:35:36 <phreak``> agaffney: yeah, we do. thats why opensource is sooo great :P +Jan 23 12:35:55 <wolf31o2|work> nightmorph: sure, but that would be a ways off, anyway... +Jan 23 12:36:04 <araujo> agaffney, hey, we are good at that +Jan 23 12:36:11 <Blackb|rd> wolf31o2|work: what do you think about a deadline for stuff that'd change the handbook? +Jan 23 12:36:25 <nightmorph> wolf31o2|work: well, assuming we don't have to worry about releases being changed (2007.1 to 2008.0), actually, i like your idea of just creating the new dir immediately +Jan 23 12:36:49 <phreak``> nightmorph: well, its a svn repo :P +Jan 23 12:36:54 <phreak``> nightmorph: svn mv ftw! +Jan 23 12:36:55 <agaffney> the dirs can always be renamed/moved +Jan 23 12:36:56 <wolf31o2|work> Blackb|rd: well, there's been one in the past and nobody met it... hehe... this time, we'll set one... and if you don't get your stuff in, it'd be bad +Jan 23 12:37:13 <agaffney> yes, you'll get a stern talking-to +Jan 23 12:37:14 <Blackb|rd> wolf31o2|work: i.e. "one week before release, nothing may be changed (except security yada yada) that'd affect docs" +Jan 23 12:37:27 <nightmorph> renaming dirs sucks. i still haven't come up with a migration plan. potential problem is that even with a separate next release handbook, double-commits would have to be made +Jan 23 12:37:30 <Blackb|rd> wolf31o2|work: splendid, I like that :) +Jan 23 12:37:32 <nightmorph> in some case +Jan 23 12:37:39 <nightmorph> phreak``: hah, the handbooks are in CVS, foo +Jan 23 12:37:48 <phreak``> nightmorph: well, ..... :P +Jan 23 12:37:59 <phreak``> nightmorph: though luck then :) +Jan 23 12:38:07 <agaffney> nightmorph: you can do the handbooks however is easiest for you +Jan 23 12:38:10 <agaffney> it's just a suggestion +Jan 23 12:38:17 <agaffney> don't let us tell you how to do your job :) +Jan 23 12:38:25 <nightmorph> agaffney: easiest for me is tracking what YOU guys are doing! +Jan 23 12:38:28 <Blackb|rd> RCS all the way. +Jan 23 12:38:29 <nightmorph> and then cursing CVS +Jan 23 12:39:02 <agaffney> we just need to move anything that's not gentoo-x86 over to SVN +Jan 23 12:39:11 <phreak``> all that reminds me yet again, I *really* need to kick vapier's rock +Jan 23 12:39:24 <agaffney> phreak``: careful...he might enjoy that +Jan 23 12:39:24 <Blackb|rd> phreak``: stomp his foot, too. +Jan 23 12:39:29 <wolf31o2|work> also, I'd like to try to release a 2008.0 beta... which is why we want the handbooks as soon as possible, so we can put them on the beta... the beta would essentially be an entire release... handbook and all... and I want to *force* a QA period after the beta... say, a week +Jan 23 12:39:35 <phreak``> agaffney: he actually does. ha. +Jan 23 12:39:55 <nightmorph> wolf31o2|work: how official would a beta be? how much in advance of the actual march-ish release? +Jan 23 12:39:57 <phreak``> wolf31o2|work: ain't a week a bit short ? +Jan 23 12:40:04 <Blackb|rd> wolf31o2|work: experience tells me to make that two weeks. or at least expect them. +Jan 23 12:40:23 <agaffney> I tend to agree with phreak`` and Blackb|rd +Jan 23 12:40:24 <rangerpb> I think the beta should probably be half the time of the release cycle frankly +Jan 23 12:40:32 <nightmorph> if i can just roll up the existing draft handbooks with the draft disclaimer on them (i.e. not make them replace the "live" toplevel dir), then i'm fine with that +Jan 23 12:40:33 <rangerpb> that gives them time to test and us time to fix whatever +Jan 23 12:40:42 <wolf31o2|work> nightmorph: ehh... it would be after the Feb 29 docs due date... +Jan 23 12:40:51 <nightmorph> k +Jan 23 12:41:04 <Blackb|rd> rangerpb: that might be too long: things start to linger once you don't have a tight schedule. +Jan 23 12:41:26 <wolf31o2|work> that's rather my fear... getting swamped by security bugs at the last minute again +Jan 23 12:41:28 <phreak``> rangerpb: uh, thats a bit much frankly :) sure, having the beta 2-4 weeks before release, ain't giving us much time, but doing the beta 3 months before release, puts stuff kinda outa the frame. +Jan 23 12:41:30 <dertobi123> two weeks beta time plus another two weeks for another (if needed) beta would make sense imho +Jan 23 12:41:37 <rangerpb> uh, it's a six week cycle, half would be 3, which is only 1 more than the suggested two +Jan 23 12:41:43 <dertobi123> if things go well with the second beta we could s/beta/release +Jan 23 12:41:56 <nightmorph> me and my handbooks wouldn't mind +Jan 23 12:42:09 <wolf31o2|work> well, my plan for betas is we release them as needed... so if beta1 is really good, we tweak the few things and release... if we need another beta, we do it and push the release date out +Jan 23 12:42:31 * nightmorph is all in favor of the idea +Jan 23 12:42:31 <wolf31o2|work> sound reasonable? +Jan 23 12:42:40 <phreak``> +1 +Jan 23 12:42:46 <Blackb|rd> wolf31o2|work: then I think a two week test period would be nice. You can always shorten the span with the consecutive beta(s) and rc(s) +Jan 23 12:43:01 <Blackb|rd> wolf31o2|work: so, ++ from me. +Jan 23 12:43:17 <wolf31o2|work> one thing I'll want all of you guys to come up with (on gentoo-releng list, please) is a list of things that you would like for us to have checked on the media... I want to come up with a comprehensive checklist... I'll start the threads after the meeting... +Jan 23 12:43:50 <dertobi123> wolf31o2|work: so when should the first beta be released? given the initial snapshot is done on february 1st - mid-february gives enough time for building and initial testing, plus enough time for bug-fixing and polishing the media? +Jan 23 12:43:56 <Blackb|rd> wolf31o2|work: arch specific stuff too? +Jan 23 12:44:03 <wolf31o2|work> Blackb|rd: yes +Jan 23 12:44:17 <phreak``> wolf31o2|work: mmmmmhmmm. +Jan 23 12:44:19 <nightmorph> i thought sometime after the 29th? +Jan 23 12:44:25 <Blackb|rd> wolf31o2|work: then the arch times will need to do some QA themselves, of course. Which is a-ok +Jan 23 12:44:26 <wolf31o2|work> dertobi123: one second... I've got a tentative schedule running as we discuss, and I'll propose the whole schedule once we've got our ideas down +Jan 23 12:44:37 <wolf31o2|work> nightmorph: ^^^ +Jan 23 12:44:41 <dertobi123> k +Jan 23 12:45:17 <wolf31o2|work> Blackb|rd: they're supposed to be doing that already... hehe... I've mailed the QA team, and (at least Halcy0n) they're willing to help out a bit... so we'll coordinate with them once we have these lists +Jan 23 12:45:33 <Blackb|rd> wolf31o2|work: splendid +Jan 23 12:45:37 * phreak`` giggles about QA & Halcy0n +Jan 23 12:45:52 <wolf31o2|work> also, we'll want a list of "stuff you want to know" from users about their machines/environments for the beta... things like chipsets/cpu/ram/etc... +Jan 23 12:46:20 <wolf31o2|work> basically, a text doc that people can grab along w/ the beta so they'll know what info we definitely want from them when they file bugs +Jan 23 12:46:26 * phreak`` goes subscribing to the gentoo-releng ml +Jan 23 12:46:32 <welp> didn't we use to have beta testing to some extent in the past? +Jan 23 12:46:34 <Blackb|rd> wolf31o2|work: yeah, getting a list of hardware that's *Worthwile* to care about would be nice. +Jan 23 12:46:49 <agaffney> welp: we had something like it for 2006.1 (or was it 2006.0?) +Jan 23 12:46:51 <phreak``> welp: private, yeah. but no public beta testing. +Jan 23 12:46:55 <Blackb|rd> wolf31o2|work: especieally for niche archs. +Jan 23 12:46:56 <welp> i seem to remember emailing someone, and then getting a location where i can download stages from +Jan 23 12:46:57 <wolf31o2|work> welp: not really... there were 1.4 release candidates, but that was because 1.4 had no schedule and dragged on and on forever +Jan 23 12:46:57 <dertobi123> welp: very limited and nothing "official" +Jan 23 12:47:00 <welp> phreak``: i don't think it was private +Jan 23 12:47:40 <wolf31o2|work> welp: we had a release tester program... and I want to reinstate that, actually... I'm going to try to solicit help from other teams in doing so, so I'm not trying to coordinate it all +Jan 23 12:47:52 <welp> wolf31o2|work: that must be what i'm thinking of.. +Jan 23 12:48:33 <wolf31o2|work> one thing I am definitely doing is trying to make it so that we don't rely so much on me for things to get done... people will be able to update things on their own more... like, we're converting the releng repo to SVN and I'm going to keep the release checklist in there, so everyone can update themselves as they get things done +Jan 23 12:48:39 <welp> roger55 was involved in it iirc +Jan 23 12:48:45 <wolf31o2|work> welp: yes, he was coordinating it +Jan 23 12:48:56 <wolf31o2|work> and it wasn't private +Jan 23 12:49:02 <welp> yeah +Jan 23 12:49:04 <wolf31o2|work> it just wasn't publicized well +Jan 23 12:49:12 <phreak``> wolf31o2|work: same for the snapshot, right (at least you mentioned it in the past) ? +Jan 23 12:49:22 <wolf31o2|work> phreak``: I'm going to try to, yes... +Jan 23 12:49:24 <welp> that was fun, would be cool if it was better publicized and possibly more arch-oriented? +Jan 23 12:49:40 <phreak``> wolf31o2|work: just yell if you need any help, please. +Jan 23 12:49:41 <agaffney> it didn't work out all that well. we fixed a few problems, but many people just wanted the media early and didn't report problems, or gave us worthless bug reports +Jan 23 12:49:46 <wolf31o2|work> welp: yeah, depends on what we can accomplish in a short time... but we'll have the beta, no matter what +Jan 23 12:49:52 <wolf31o2|work> right +Jan 23 12:49:53 <welp> wolf31o2|work: cool +Jan 23 12:50:03 <Blackb|rd> agaffney: that'll be the main problem: getting good reports. +Jan 23 12:50:07 <armin76> welp will do it +Jan 23 12:50:12 <wolf31o2|work> not having some kind of form or anything to let people know what we wanted to know was one of the major reasons it didn't work out so well +Jan 23 12:50:17 <agaffney> Blackb|rd: which is why wolf31o2|work asked for a list of things that people will want with a bug report +Jan 23 12:50:18 <wolf31o2|work> we never got good reports +Jan 23 12:50:24 <wolf31o2|work> right +Jan 23 12:50:32 <Blackb|rd> agaffney: half the rent, yes. +Jan 23 12:50:39 <wolf31o2|work> ok... so I've got a tentative schedule +Jan 23 12:50:54 <Opfer> What about a bug wrangler for release bugs? +Jan 23 12:51:09 <Opfer> So some are filtered beforehand +Jan 23 12:51:13 <dertobi123> Opfer: have one? +Jan 23 12:51:14 <dertobi123> *G* +Jan 23 12:51:22 <agaffney> we could use jakub! +Jan 23 12:51:23 * agaffney runs +Jan 23 12:51:24 <wolf31o2|work> Opfer: there really aren't that many of them to warrant it, I don't think... we'll have to see how much our bug reports explode when it comes time for the beta +Jan 23 12:51:32 <nightmorph> agaffney: i was just thinking that. but at least i didn't say it ;) +Jan 23 12:51:35 <Blackb|rd> agaffney: somehoe I expected that line :)) +Jan 23 12:51:49 <phreak``> agaffney: oh, save it. +Jan 23 12:51:50 <welp> buhwuh? +Jan 23 12:52:06 <Opfer> Some good bug reports are better than none...me out. go on. :) +Jan 23 12:52:11 <nightmorph> anyway, show us this proposed timeline. i've got a notepad all ready +Jan 23 12:52:23 <welp> nightmorph: windows notepad? :> +Jan 23 12:52:47 <phreak``> welp: yeah, exactly that! +Jan 23 12:52:59 * Blackb|rd uses EDLIN +Jan 23 12:53:07 * agaffney cringes +Jan 23 12:53:33 <wolf31o2|work> ok... schedule... Snapshot on Feb 1, Docs Due (Releng)/Snapshot frozen (pre-beta) on Feb 25, Docs Finalized/Due on Feb 29, Beta1 released on Mar 3, Final upload on Mar 14, Release on Mar 17... +Jan 23 12:54:02 <nightmorph> that's doable +Jan 23 12:54:04 <wolf31o2|work> basically, everything after Beta1 is *very* dependent on the quality of the beta... +Jan 23 12:54:14 <wolf31o2|work> so this assumes no major problems +Jan 23 12:54:22 <dertobi123> i'd like a beta *before* a snapshot freeze +Jan 23 12:54:32 <wolf31o2|work> umm... that's the beta snapshot freeze +Jan 23 12:54:40 <Blackb|rd> wolf31o2|work: how do you plan to avoid getting rear-ended by sec bugs? +Jan 23 12:54:51 <Blackb|rd> wolf31o2|work: (schedule is fine by me) +Jan 23 12:55:10 <wolf31o2|work> Blackb|rd: still working on that one, but coming up with a way for people to update the snapshot themselves will help out a lot +Jan 23 12:55:22 <angelos> hah, beta1 release one day before my birthday, good timing +Jan 23 12:55:23 <agaffney> Blackb|rd: part of the problem last time was that wolf31o2|work was trying to update the snapshot for *every* sec bug, isntead of just the ones that affected the media +Jan 23 12:55:24 <Blackb|rd> wolf31o2|work: *nod* +Jan 23 12:55:31 <phreak``> wolf31o2|work: was about to say that :) since it keeps you from doing all the work ;) +Jan 23 12:55:35 <welp> angelos will be too drunk to do anything! +Jan 23 12:55:36 <Blackb|rd> agaffney: I kinda noticed. +Jan 23 12:55:41 <phreak``> bah, even andew is faster :P +Jan 23 12:55:49 <wolf31o2|work> right... I was definitely the single point of failure on that one... heh +Jan 23 12:56:11 <wolf31o2|work> ok... so schedule looks alright (it can be adjusted as we go, of course...) +Jan 23 12:56:19 <nixnut> tinderbox and make binpkgs available for the security updates? +Jan 23 12:56:28 <welp> i think the arch releng coordinator definitely needs to keep in touch with the arch security liaison here +Jan 23 12:56:36 <agaffney> nixnut: won't help us all that much +Jan 23 12:56:39 <Blackb|rd> the 29/2 mark for b1 should be the point where stuff hinges on. +Jan 23 12:56:52 <nixnut> agaffney: beats rebuilding all the stages I reckon +Jan 23 12:56:58 <wolf31o2|work> Blackb|rd: pretty much, yes +Jan 23 12:57:05 <agaffney> nixnut: you'd still have to rebuild the stages +Jan 23 12:57:08 <phreak``> welp: they have to, still amd64 keeps falling behind ;) +Jan 23 12:57:14 <agaffney> after updating the snapshot and pushing a new one out +Jan 23 12:57:14 <nixnut> agaffney: why? +Jan 23 12:57:16 <wolf31o2|work> nixnut: we have lots of caching in catalyst... +Jan 23 12:57:34 <welp> phreak``: well, i'm the new security liaison, so hopefully things will improve :P +Jan 23 12:57:40 <nixnut> wolf31o2|work: ah, ok. Not that much work as I thought then +Jan 23 12:57:40 <agaffney> nixnut: subsequent runs use binpkgs from previous runs +Jan 23 12:57:45 <nixnut> nod +Jan 23 12:57:50 <phreak``> agaffney: that ain't much of a problem (rebuilding the stage) when you have the binpkg handy ;) +Jan 23 12:57:53 <agaffney> nixnut: only the sec bumped package would need to be rebuilt +Jan 23 12:57:59 <wolf31o2|work> k... so let's move on (this is taking longer than I hoped) +Jan 23 12:58:09 <phreak``> ha. then move on :) +Jan 23 12:59:17 <wolf31o2|work> automated regular internal release builds... this is basically extending andrew's stage-building script to include *everything* for a particular arch (though only necessary sub-arches for functionality)... +Jan 23 12:59:55 <wolf31o2|work> the reason for us splitting off the new release as soon as the old is done is for these auto-builds... they'll check out the SVN for the new release and use the new dev profile... so we find problems and fix them, year-round... instead of just during the release cycle... +Jan 23 13:00:15 <agaffney> wolf31o2|work: the problem with doing anything more than stages is that you need a per-arch template for livecd-stage[12].spec +Jan 23 13:00:19 <Blackb|rd> wolf31o2|work: we had thought about internally doing continous building for alpha (since we got shiny new disk space). I think it's a good idea. +Jan 23 13:00:23 <dertobi123> how "internal" do you want this builds to be? +Jan 23 13:00:48 <wolf31o2|work> agaffney: that's fine... we're going to be pulling the specs from SVN and using them directly... so it really be the same as what we do for releases +Jan 23 13:00:49 <agaffney> dertobi123: run on a dev box and not distributed to mirrors +Jan 23 13:01:15 <Blackb|rd> wolf31o2|work: Of course, this will help with 2008.1 earliest, not 2008.0. +Jan 23 13:01:27 <wolf31o2|work> dertobi123: what andrew said... you could distribute them to people you wanted to test them and such... but they won't hit the main mirrors +Jan 23 13:01:42 <wolf31o2|work> Blackb|rd: right... since 2008.0 starts $soon +Jan 23 13:01:53 <phreak``> wolf31o2|work: ok, I think I'd like some clarification on the auto-build. Like do you want it refreshing every time someone updates the specs, once a day, once a week ... ? +Jan 23 13:01:56 <Blackb|rd> wolf31o2|work: and we'd need to get the process to run smoothly, too. +Jan 23 13:01:56 <phreak``> :) +Jan 23 13:02:01 <dertobi123> ok, let me propose to manually distribute a selected subset of automated builds to /experimental "if necessary". i.e. new kernel with extended hardware support has been released and the latest "release" install media doesn't work for a number of users +Jan 23 13:02:18 <agaffney> phreak``: we were running weekly automated builds from the live portage tree on poseidon for x86/amd64 +Jan 23 13:02:26 <phreak``> agaffney: I know :) +Jan 23 13:02:37 <wolf31o2|work> phreak``: well, we've been doing once a week... I think that works... we can adjust the schedule if we find that we need to do so... +Jan 23 13:02:44 <Blackb|rd> agaffney: keep in mind that a too tight schedule might pose a problem for the less-endowed archs +Jan 23 13:02:46 <phreak``> wolf31o2|work: aight. +Jan 23 13:02:57 <agaffney> the "best" way would be to re-pull the specs from CVS/SVN once a week and create a new snapshot from the live tree at that time +Jan 23 13:03:00 <wolf31o2|work> dertobi123: that's totally up to the individual arch team... releng doesn't control /experimental +Jan 23 13:03:05 <agaffney> similar to what we were already doing +Jan 23 13:03:15 <wolf31o2|work> that was the plan +Jan 23 13:03:35 <agaffney> I guess it gets a +1 from me, then :P +Jan 23 13:03:38 <dertobi123> wolf31o2|work: k ... +Jan 23 13:03:43 <Blackb|rd> same 'ere +Jan 23 13:03:44 <wolf31o2|work> dertobi123: I mainly meant that they're not going to go to the mirrors automatically or anything +Jan 23 13:03:59 <phreak``> agaffney: only if you add hardened foo to your buildlist ;) +Jan 23 13:04:08 <agaffney> phreak``: use miranda :P +Jan 23 13:04:11 <Halcy0n> wolf31o2|work: yea, I'll help you come up with some checklists and crap to give testers. Currently I'm the only active QA members really (maybe one or two others, so expect some slight latency in replies :) ) +Jan 23 13:04:21 <wolf31o2|work> phreak``: I'll get with you on that... but yes, I was planning on including hardened, of course +Jan 23 13:04:38 <dertobi123> wolf31o2|work: no need to push them out automatically, but having a x86 install-media which works on "current" hardware somewhere would be nice ;) +Jan 23 13:04:45 <phreak``> agaffney: *grmpf* fix my issues building x86 stages on a amd64 host :P +Jan 23 13:04:56 <wolf31o2|work> Halcy0n: no problem... just join the gentoo-releng list and participate in the discussion (once we start it) +Jan 23 13:04:59 <agaffney> phreak``: WFM +Jan 23 13:05:10 <phreak``> agaffney: you ain't using gcc-3.4.6 :P +Jan 23 13:05:21 <agaffney> phreak``: I'm not insane :P +Jan 23 13:05:24 <Blackb|rd> x86 and amd64 are moving very wuickly currently, so I think it's a good idea to have "quickfix" images in /exp +Jan 23 13:05:31 <phreak``> agaffney: damn, just shutup :P +Jan 23 13:05:48 <dertobi123> Blackb|rd: yeah, that's what i meant to say :P +Jan 23 13:06:10 <Blackb|rd> dertobi123: I got bitten by that with our amd64 machines at work :/ +Jan 23 13:06:19 <wolf31o2|work> Blackb|rd: dertobi123: again, that's up to the individual arch team... anybody can do an interim release now (in /experimental)... that won't change... +Jan 23 13:06:25 <dertobi123> Blackb|rd: use ting :P *cough* +Jan 23 13:06:32 <agaffney> Blackb|rd: I'd certainly have no problem doing a quick minimal CD rebuild with a new kernel +Jan 23 13:06:35 <agaffney> for x86 +Jan 23 13:07:09 <Blackb|rd> agaffney: So do I. Many user don't have the expertise. +Jan 23 13:07:14 <ColdWind> do we will have access to internal stages on dev boxes or is it closed to arch teams and releng? +Jan 23 13:07:30 <agaffney> ColdWind: I'm sure something can be arranged +Jan 23 13:07:33 <wolf31o2|work> ok... so my long-term goal for the automatic builds is for us to be able to use them as our initial beta... we pick one that's as close to release quality as possible, release it as beta, *then* start the release cycle (snapshot/qa/another beta/possible rc/release) +Jan 23 13:07:49 <agaffney> there's no reason for us to "hide" them, especially if someone needs something +Jan 23 13:07:51 <wolf31o2|work> ColdWind: it'll all be open to devs... it is now +Jan 23 13:07:56 <Blackb|rd> wolf31o2|work: Yep. +Jan 23 13:08:05 <ColdWind> wolf31o2|work: ok +Jan 23 13:08:10 <dertobi123> wolf31o2|work: sure, but this problem affects releng (and imho this problem is somewhat essential for us) +Jan 23 13:08:23 <wolf31o2|work> dertobi123: huh? +Jan 23 13:08:33 * agaffney senses a delayed reply +Jan 23 13:08:46 <Blackb|rd> A disturbance in the laf. +Jan 23 13:08:48 <Blackb|rd> lag* +Jan 23 13:08:58 <agaffney> fail +Jan 23 13:08:59 <rangerpb> wolf31o2|work, although I would suggest most of our problems with releases are not so much the stages as media right? +Jan 23 13:09:06 <dertobi123> wolf31o2|work: wrt experimental stuff ... whatever +Jan 23 13:09:08 <rangerpb> least it is for my archs +Jan 23 13:09:09 <Blackb|rd> agaffney: I always ruin the good lines :( +Jan 23 13:09:20 <dertobi123> keeping it up the arch teams only didn't work in the past +Jan 23 13:09:25 <wolf31o2|work> dertobi123: if you want to build a new CD for your arch right now... you can... the *only* things I ask is you don't name it a "release" name, like 2008.0... and it goes to /experimental... +Jan 23 13:09:48 <agaffney> rangerpb: I'd agree. the most common problem is outdated kernel for new hardware +Jan 23 13:09:54 <Blackb|rd> wolf31o2|work: maybe that needs to be stated more explicitly +Jan 23 13:10:00 <agaffney> that's of course usually only a problem on "main" arches like x86/amd64 +Jan 23 13:10:17 <agaffney> at least, more of a problem on those arches +Jan 23 13:10:19 <wolf31o2|work> dertobi123: I'm not sure I'm following... both the arch teams and releng can so interim stuff now... we just generally don't... +Jan 23 13:10:25 <Blackb|rd> wolf31o2|work: one thing wrt the openness of releng and the build process is that people know they can burn wtf they want +Jan 23 13:10:46 <dertobi123> wolf31o2|work: and that "we don't" is exactly the problem +Jan 23 13:11:08 <rangerpb> agaffney, I have some ideas around that if we get to a "feature" part of this meeting +Jan 23 13:11:10 <agaffney> dertobi123: releng doesn't because most of us don't want to look at another stage tarball for a few months after a release cycle +Jan 23 13:11:10 <Blackb|rd> dertobi123: you're thinking of an explicit interim release? +Jan 23 13:11:12 <wolf31o2|work> dertobi123: ok... this has nothing to do with the automated builds... can we hold it off until later +Jan 23 13:11:30 <dertobi123> dunno how some interim is stuff is called, but we need such interim stuff on a somewhat "official" base for x86/amd64 +Jan 23 13:11:40 <dertobi123> Blackb|rd: somewhat, yeah +Jan 23 13:11:43 <dertobi123> wolf31o2|work: k +Jan 23 13:12:56 <wolf31o2|work> ok.. so on the subject of the regular builds... everybody seems in agreement? +Jan 23 13:13:02 <agaffney> seems so +Jan 23 13:13:06 * Blackb|rd is all for it. +Jan 23 13:13:13 <tgall_foo> yup +Jan 23 13:13:13 <wolf31o2|work> I'd like to run these on dev boxes, of course... +Jan 23 13:13:21 <wolf31o2|work> cool... then to the next point... +Jan 23 13:13:30 <wolf31o2|work> how do we involve the community more? +Jan 23 13:13:37 <wolf31o2|work> betas will *definitely* help a lot +Jan 23 13:13:43 <Blackb|rd> wolf31o2|work: QA testing is one area +Jan 23 13:13:53 <phreak``> wolf31o2|work: well, for starters, the beta cycle. (you already mentioned it) +Jan 23 13:13:57 <Blackb|rd> wolf31o2|work: I.e. public betas and explicitly asking for feedback +Jan 23 13:14:14 <Blackb|rd> I think the latter is more important than the former. +Jan 23 13:14:31 <Blackb|rd> Usually, you have to pull quality feedback out of people's noses. +Jan 23 13:14:41 <wolf31o2|work> Blackb|rd: right... we're definitely going to spend more time on QA throughout the entire process +Jan 23 13:14:46 <agaffney> wolf31o2|work: not having to go through an intermediary (like we did with roger55) will probably help +Jan 23 13:15:05 <tgall_foo> sadly you almost want a beta that phones home as to what it was successfully run on +Jan 23 13:15:13 <wolf31o2|work> agaffney: for release testers, agreed... and for the betas, we'll ask people to file bugs, like normal... +Jan 23 13:15:18 <ColdWind> users testing betas will want a list of thing they're expected to test +Jan 23 13:15:24 <Blackb|rd> Also, it might be nice to get feature requests/wishes earlier, for example directly after a release. +Jan 23 13:15:25 <wolf31o2|work> ColdWind: we already discussed that +Jan 23 13:15:39 <wolf31o2|work> Blackb|rd: indeed... that would help, for sure... +Jan 23 13:16:03 <Blackb|rd> When people think 2008.0 sucked for some reason, they will have forgotten until 2008.1 beta time. +Jan 23 13:16:09 <ColdWind> yep, I mean it should be clear what they should *test* not just the info they should report with bugs +Jan 23 13:16:32 <dsd_> did i miss the meeting? +Jan 23 13:16:38 <wolf31o2|work> ColdWind: right... it'll have both +Jan 23 13:16:41 <welp> dsd_: still ongoing +Jan 23 13:16:42 <wolf31o2|work> dsd_: nope +Jan 23 13:16:43 <Blackb|rd> wolf31o2|work: also, the hardware survey is a good idea. Especially for the more obscure arches. +Jan 23 13:16:46 <agaffney> Blackb|rd: there was a thread on -releng after 2007.0 asking for features people wanted...hardly any response +Jan 23 13:16:57 <ColdWind> good ;) +Jan 23 13:17:16 <Opfer> May I throw in app-admin/hwreport for hardware survey? +Jan 23 13:17:17 <Blackb|rd> agaffney: yeah. Maybe involving the forum peole might be a good idea. Have a poll citing ten things we might include. +Jan 23 13:17:18 <wolf31o2|work> Blackb|rd: I find it more important for the least obscure arches... since there's only so many alpha boxes out there... but literally thousands of combinations of x86/amd64 stuff... +Jan 23 13:17:22 <dberkholz> dsd_: my very rough, still in-progress summary: http://dev.gentoo.org/~dberkholz/20080123_releng_summary.txt +Jan 23 13:17:26 <phreak``> agaffney: most likely because people don't watch releng +Jan 23 13:17:26 <dsd_> thanks +Jan 23 13:17:34 <phreak``> (as in the mailinglist) +Jan 23 13:17:40 <wolf31o2|work> Opfer: interesting... let's discuss that after the meeting... +Jan 23 13:17:41 <Blackb|rd> agaffney: if people just ahve to click to vote, they do so more freely than when they have to type up a mail +Jan 23 13:17:58 <Blackb|rd> wolf31o2|work: good point. +Jan 23 13:18:17 <rane> drop a news item to the front page that you need feedback on what users need for next release +Jan 23 13:18:41 <wolf31o2|work> rane: good idea +Jan 23 13:18:50 <rane> dberkholz can help you with that +Jan 23 13:18:55 <rane> :-) +Jan 23 13:19:01 <dberkholz> robbat2's been talking about getting his survey framework up for the user survey. use the same setup. +Jan 23 13:19:08 <Blackb|rd> rane: providing feedback should be as easy as possible without encouraging spamming +Jan 23 13:19:19 <Blackb|rd> dberkholz: I was about to suggest the same. +Jan 23 13:19:21 <wolf31o2|work> sure... until that's up and running, we'll use the list +Jan 23 13:19:25 <Halcy0n> Yea, I think the more we try to actually involve our users with the entire releng and development process will go a long way in improving developer<->user relationships. +Jan 23 13:19:37 <wolf31o2|work> I'll just announce to -user and -dev-announce when I start the threads +Jan 23 13:19:52 <wolf31o2|work> Halcy0n: indeed... *and* it'll improve our quality as a side-effect +Jan 23 13:20:28 <Blackb|rd> wolf31o2|work: Also, it might be a nice occasion to point out resources releng needs direly. Like arch teams without build machines. +Jan 23 13:20:34 <wolf31o2|work> cool... I think we've got a few good ideas on this... let's move on +Jan 23 13:20:41 <wolf31o2|work> Blackb|rd: that's on the agenda +Jan 23 13:20:42 <Blackb|rd> wolf31o2|work: and of course the ever popular manpower. +Jan 23 13:20:54 <armin76> just have to see how a lot of ppl are joining and leaving :P +Jan 23 13:21:02 <wolf31o2|work> so... basically the same question, but for developers... +Jan 23 13:21:08 <wolf31o2|work> how do we involve the other devs more? +Jan 23 13:21:37 <wolf31o2|work> I know they'll be involved a bit more just with the betas... and I'm hoping that they'll test things with the automated builds, since they will be available to them... +Jan 23 13:21:41 <codeman> wolf31o2|work: announce betas to the mailing lists? +Jan 23 13:21:53 <wolf31o2|work> codeman: we will be doing that... and the front page and everywhere else... +Jan 23 13:22:09 <Blackb|rd> wolf31o2|work: it's tricky. On one hand you want them to schedule their major releases around the media release. On the other hand you don't want all major releases two days before media release. +Jan 23 13:22:17 <dberkholz> appeal to their motivations for being a developer in the first place. ask them to test their own packages on the release, if applicable. +Jan 23 13:22:20 <rbu> phreak``: wolf31o2|work++ on announcing betas and public tests +Jan 23 13:22:31 <wolf31o2|work> dberkholz: right +Jan 23 13:22:56 <agaffney> dberkholz: I like that...guilt trip them :P +Jan 23 13:23:10 <codeman> dberkholz: i agree. the more you can convince devs that they are responsible for their packages working on each release, the better. +Jan 23 13:23:13 <wolf31o2|work> dberkholz: well, I'm thinking more of things that we could do to involve people more... rather than the devs just being "consumers' +Jan 23 13:23:55 <wolf31o2|work> one thing I would like to propose is for "release" bugs to maybe be a higher priority... +Jan 23 13:24:04 <nightmorph> wolf31o2|work: will you be wanting a beta handbook tarball then for every beta? i'm wondering because this means that, in effect, the GDP will be perpetually having to update 3 separate handbooks +Jan 23 13:24:09 <nightmorph> instead of the 2 we have now +Jan 23 13:24:17 <phreak``> wolf31o2|work: well, educate them like dberkholz said. that the release is one of the show-offs for their packages, or something along the lines +Jan 23 13:24:20 <nightmorph> well, 4 i guess +Jan 23 13:24:21 <dberkholz> i've got plenty of ideas, but they might be better discussed later. +Jan 23 13:25:11 <wolf31o2|work> right now, there's really no determination (for arch teams and others) of what priority they should work on release bugs... we could have it something like: security -> release -> stable -> other... now it's security -> stable -> other (with us falling into other) +Jan 23 13:25:31 <agaffney> we do tend to get back-burnered +Jan 23 13:25:33 <wolf31o2|work> nightmorph: unless there's a docs bug and you feel the need to do so, no... +Jan 23 13:25:34 <rbu> wolf31o2|work: add a RELEASE keyword in bugz? +Jan 23 13:25:42 <nightmorph> wolf31o2|work: k +Jan 23 13:25:51 <wolf31o2|work> rbu: that could definitely help +Jan 23 13:25:54 <dberkholz> should be easy enough to just search for bugs with a releng CC. +Jan 23 13:26:05 <wolf31o2|work> release CC, but yes +Jan 23 13:26:23 <wolf31o2|work> also, I'd like help from you guys with the release@ bugs, specifically the ones that are media-related... +Jan 23 13:26:35 <wolf31o2|work> I often feel that I'm one of the only ones looking at them +Jan 23 13:27:06 <rangerpb> can we put a tinurl for the query in /topic? +Jan 23 13:27:12 <wolf31o2|work> (yes, all of you have helped, I'm not saying you haven't) +Jan 23 13:27:15 <wolf31o2|work> rangerpb: sure +Jan 23 13:27:15 <rangerpb> er tinyurl +Jan 23 13:27:44 <wolf31o2|work> ok... that's a good start for that... again, we can continue on -releng list +Jan 23 13:27:45 <codeman> wolf31o2|work: i'd also like to re-propose using dotproject to keep the releases organized. +Jan 23 13:27:54 <rangerpb> wolf31o2|work, probably want to add a release bugs squashed in your schedule +Jan 23 13:28:05 <codeman> wolf31o2|work: it'll allow releng + devs to see what's going on easily. +Jan 23 13:28:15 <wolf31o2|work> codeman: ehh... I've considered it... I'll look at it again... but it was *way* too much work to set everything up last time... I got frustrated doing it +Jan 23 13:28:34 <Blackb|rd> wolf31o2|work, codeman: it's also *another* tool to learn +Jan 23 13:29:01 <Blackb|rd> And already some people need to be whipped to use Bugzilla +Jan 23 13:29:16 <wolf31o2|work> well, we don't track progress in bugzilla +Jan 23 13:29:18 <Blackb|rd> (with the exception of armin76 who always enjoys a good whipping) +Jan 23 13:29:29 <armin76> a what :P +Jan 23 13:29:43 <codeman> Blackb|rd: it would be mainly used by releng to see who's made tarballs and which arches are slacking. +Jan 23 13:29:47 <Blackb|rd> wolf31o2|work: that's right, but it might be easier to coax bugz into doing that. +Jan 23 13:29:47 <wolf31o2|work> I'd done it several ways in the past... probably the most successful (IMO) was when I kept junk in a spreadsheet and just exported it to html in my dev space +Jan 23 13:29:57 <wolf31o2|work> but I want something everyone can update, so we'll find something better +Jan 23 13:30:08 <codeman> wolf31o2|work: google docs spreadsheet? :) +Jan 23 13:30:16 <wolf31o2|work> codeman: maybe... heh +Jan 23 13:30:27 <nightmorph> aaaaand on that note, i have to head off to work. thanks for the meeting gents; the handbook tarball date of 2-29 works for me. any other changes that come up that might relate to docs, email me. +Jan 23 13:30:50 <wolf31o2|work> nightmorph: will do +Jan 23 13:30:57 <nightmorph> thanks ya'll! see you around ;) +Jan 23 13:31:00 <wolf31o2|work> heh... nick complete sucks in here right now with all these other people... +Jan 23 13:31:27 <wolf31o2|work> ok... the store... I'm looking into alternatives to cafepress... as they don't do DVD media... +Jan 23 13:31:41 <wolf31o2|work> dberkholz gave me a nice link to look into... +Jan 23 13:32:09 <wolf31o2|work> one thing I would like to do is to try to find some place in europe to essentially do the same thing... so people don't have to pay outrageous shipping... +Jan 23 13:32:35 <Blackb|rd> wolf31o2|work: I was saying. Keep the Europeans in mind. And not everybody can/wants to use Paypal. +Jan 23 13:32:38 <agaffney> wolf31o2|work: did you read that URL that someone gave you in #-infra yesterday? +Jan 23 13:32:38 <wolf31o2|work> so my question about what to do with the store is really... what do we want on our store? (release-wise) +Jan 23 13:32:57 <agaffney> that compared cafepress to a few other services +Jan 23 13:33:09 <wolf31o2|work> agaffney: read 3 comments ago... I looked at it... I need to spend more time on it, though +Jan 23 13:33:12 <ColdWind> wolf31o2|work: wrt Europe, what about Gentoo e.V.? +Jan 23 13:33:13 <agaffney> http://www.squidoo.com/cafepress_alternative +Jan 23 13:33:18 <Blackb|rd> wolf31o2|work: well, release media is kinda obvious (is it?), but there might be a market for release-specific t-shirts/clothing. +Jan 23 13:33:24 <agaffney> ah :P +Jan 23 13:33:27 <armin76> a wiki +Jan 23 13:33:37 <wolf31o2|work> ColdWind: gentoo e.v. has nothing to do with a store, unless they decided to become an online merchant and nobody told me +Jan 23 13:33:43 <agaffney> armin76: we want a wiki on our store? :P +Jan 23 13:33:49 <armin76> rofl, no +Jan 23 13:34:04 <armin76> i was talking about the other thing we were talking +Jan 23 13:34:09 <armin76> my connection dropped :) +Jan 23 13:34:19 <wolf31o2|work> Blackb|rd: well, I meant more what media should we offer... in the past, we did the universal/grp and livecd... should we stick with that? +Jan 23 13:34:32 <ColdWind> wolf31o2|work: I thought they were selling Gentoo merchandising +Jan 23 13:34:46 <ColdWind> anyway, nothing to do with releng +Jan 23 13:34:50 <wolf31o2|work> ColdWind: they are not producing it, so it doesn't have any bearing here +Jan 23 13:35:06 <ColdWind> ok +Jan 23 13:35:09 <wolf31o2|work> we're talking about what we'd be producing... I'm not talking about t-shirts +Jan 23 13:35:47 <tgall_foo> unless we did release t-shirts for some reason ... +Jan 23 13:35:58 <wolf31o2|work> so... do we stick w/ uni/grp and livecd/dvd (if I can find a vendor to sell them) ? +Jan 23 13:36:02 <Blackb|rd> wolf31o2|work: I think anything smaller than 650M is kinda moot. People have broadband these days. +Jan 23 13:36:13 <dertobi123> wolf31o2|work: any numbers on which media has been bought at cafepress how much? +Jan 23 13:36:21 <agaffney> wolf31o2|work: I don't see much need for anything other than those you listed +Jan 23 13:36:37 <wolf31o2|work> dertobi123: I've sent out several such numbers in the past to -nfp... I can give you estimates, though... +Jan 23 13:36:38 <tgall_foo> rangerpb, do you want to bring up the ps3 stage4s ? +Jan 23 13:37:09 <wolf31o2|work> amd64 sells the most, x86 second, but close... alpha/ppc sell a few... nobody else sells anything... +Jan 23 13:37:26 <dertobi123> wolf31o2|work: from what i recall there weren't that many release media sold via cafepress, so i'd say stick it to dvd media +Jan 23 13:37:32 <agaffney> nobody wants a hppa GRP CD? :/ +Jan 23 13:37:32 <wolf31o2|work> amd64 and x86 were around 40 sold in the time between 2006.0 and 2006.1 +Jan 23 13:37:37 <Blackb|rd> wolf31o2|work: I guess most of alpha/ppc is memorabilia :) +Jan 23 13:37:42 <dertobi123> anything else ... everyone as broadband access somewhere +Jan 23 13:37:58 <rangerpb> tgall_foo, nope until Sony gets PS3 in mainline, "ferget about it" +Jan 23 13:38:08 <dertobi123> agaffney: the last time we had a hppa grp cd ... was ... err ... more then 3 years ago or so :P +Jan 23 13:38:14 <tgall_foo> rangerpb, k ... least the upstream kernel sources is getting there +Jan 23 13:38:14 <agaffney> ah :P +Jan 23 13:38:15 <wolf31o2|work> that was kinda what I was thinking... making the store media the more rich media... so dvd where possible... and maybe even a DVD Universal+GRP for the others? +Jan 23 13:38:26 <dertobi123> than* even +Jan 23 13:38:38 <wolf31o2|work> also, do we even want to put up all the arches? +Jan 23 13:38:41 <Blackb|rd> Is there anything we could add that *isn't* easily available besides volume? +Jan 23 13:39:06 <agaffney> wolf31o2|work: I think it only makes sense to put up the ones that sell +Jan 23 13:39:11 <agaffney> x86/amd64 +Jan 23 13:39:17 <dertobi123> and dvd only +Jan 23 13:39:18 <Blackb|rd> agaffney: ++ +Jan 23 13:39:22 <agaffney> not that I'm discriminating against the other arches :P +Jan 23 13:39:23 <wolf31o2|work> Blackb|rd: well, DVD media would be nice, as not everyone has a burner (still... sad...) +Jan 23 13:39:47 <wolf31o2|work> ok... so we limit the store to the stuff that actually sells and provides a decent value... sounds good to me... agreed? +Jan 23 13:39:51 <Blackb|rd> wolf31o2|work: that's a good point. but what to put on it? GRP packages get old quickly. +Jan 23 13:40:02 <tgall_foo> course the downside is there are major amounts of ppc64 hardware without dvd drives ... but given no sales ... I'm not sure it matters +Jan 23 13:40:08 <araujo> it'd still be nice to sell GRP packages +Jan 23 13:40:16 <araujo> I think people would buy them too +Jan 23 13:40:26 <Blackb|rd> wolf31o2|work: I was thinking "artwork" - but what artwork exactly. Not to mention the copyright status +Jan 23 13:40:33 <wolf31o2|work> araujo: well, nobody has really in the past +Jan 23 13:41:03 <araujo> wolf31o2|work, really?, I even didn't know we have them ... :-P +Jan 23 13:41:10 <Blackb|rd> araujo: would you buy a DVD with GRP packages that are 3 months old? +Jan 23 13:41:23 <codeman> Blackb|rd: for someone on dialup, sure. +Jan 23 13:41:31 <araujo> Blackb|rd, I can think on many reasons to do it +Jan 23 13:41:42 <Blackb|rd> Maybe I'm just too rich :) +Jan 23 13:41:44 <agaffney> yes, but if the GRP has been put up in the past and not sold... +Jan 23 13:41:44 <wolf31o2|work> Blackb|rd: well, even then, it would *also* be the Universal... so it's still a usable bootable media... +Jan 23 13:41:46 <armin76> lol +Jan 23 13:42:00 <wolf31o2|work> but yes, nearly no one has bought GRP disks... ever +Jan 23 13:42:10 <Blackb|rd> I can see it work for slow-moving stuff like OOo. +Jan 23 13:42:53 <Blackb|rd> But then OOo is alsoa available as a -bin for the very same reason +Jan 23 13:43:00 <wolf31o2|work> Nysander brought up creating some kind of release bundle... something like: DVD + Gentoo Poster + Gentoo Mouse Pad (or something)... +Jan 23 13:43:16 <Blackb|rd> wolf31o2|work: that's what I meant by addons, too. +Jan 23 13:43:19 <agaffney> that's an interesting idea +Jan 23 13:43:26 <dberkholz> limited-edition merchandise is often more popular +Jan 23 13:43:31 <wolf31o2|work> cafepress doesn't let us really create bundles like that... but if it were something we were interested in doing, I could investigate it along with the new vendors +Jan 23 13:43:36 <wolf31o2|work> right +Jan 23 13:43:52 <Blackb|rd> wolf31o2|work: maybe release-specific poster and DVD. OpenBSD does that, IIRC. +Jan 23 13:44:35 <wolf31o2|work> I've also considered the idea of running our own store website, and calling out to CP (or wherever) to place the actual order... so we *could* create a bundle, it just wouldn't be bundled on their end... +Jan 23 13:44:46 <wolf31o2|work> but that would require someone to code the site... heh... and I definitely can't do that +Jan 23 13:44:55 <agaffney> I could +Jan 23 13:45:00 <agaffney> I do that at work all damn day :P +Jan 23 13:45:09 <agaffney> I've got e-commerce sites out the wazoo +Jan 23 13:45:30 <agaffney> however, I'm not sure if it's worth the effort +Jan 23 13:45:39 <wolf31o2|work> ok... we'll discuss that later, then... since we'd need to involve trustees and such in that discussion +Jan 23 13:45:44 <agaffney> I'll do it for a percent of the profits ;) +Jan 23 13:45:46 <wolf31o2|work> heh +Jan 23 13:45:48 <Blackb|rd> We'd get the store in Gentoo look&feel. +Jan 23 13:46:03 <wolf31o2|work> Blackb|rd: it already is, a bit... they let us use our own CSS +Jan 23 13:46:05 <Blackb|rd> Not sure if that's a pro or a con ;)) +Jan 23 13:46:09 <rbu> Blackb|rd: is that a good thing? +Jan 23 13:46:14 <agaffney> heh +Jan 23 13:46:17 * Blackb|rd high-5-s rbu +Jan 23 13:46:25 <wolf31o2|work> hehe... ok... moving on +Jan 23 13:46:44 <wolf31o2|work> what financial needs do we have? do we need hardware? +Jan 23 13:46:57 <agaffney> "need" or *need* ? :P +Jan 23 13:47:06 <wolf31o2|work> ok... how about "want" +Jan 23 13:47:22 <Blackb|rd> wolf31o2|work: Alpha could use dev machines, shipping is the main problem. +Jan 23 13:47:32 <Blackb|rd> wolf31o2|work: amchines for devs, that is. +Jan 23 13:47:37 <wolf31o2|work> Blackb|rd: and hosting, no? +Jan 23 13:47:39 <wolf31o2|work> ahh... ok... +Jan 23 13:47:51 * phreak`` heads of for some sleep +Jan 23 13:47:51 <wolf31o2|work> all your devs are in EU, pretty much, right? +Jan 23 13:47:55 <wolf31o2|work> phreak``: night, man +Jan 23 13:48:01 <phreak``> Sorry guys, but its getting rather late ;) +Jan 23 13:48:01 <Blackb|rd> wolf31o2|work: yeah. +Jan 23 13:48:38 <wolf31o2|work> well, machines for the alpha devs isn't really releng's concern... I was thinking more along the lines of releng stuff... like, if you needed a dev box hosted +Jan 23 13:48:53 <Blackb|rd> wolf31o2|work: we're content there. +Jan 23 13:49:23 <wolf31o2|work> I'm wanting some new drives for poseidon... something a bit faster... the machine seems snappy enough for what we're doing... but that might change with the automated builds... so we'll see... +Jan 23 13:49:24 <Blackb|rd> wolf31o2|work: I talked off-channel with dertobi123 about his hppa machine needing hosting. I might be able to work something out (he lives not far from where I do). +Jan 23 13:49:24 <dertobi123> Blackb|rd: hrm i've got a 433mhz alpha standing around here ... if you could use that box ... +Jan 23 13:49:40 <Blackb|rd> dertobi123: I already have two alphas :) +Jan 23 13:49:42 <wolf31o2|work> but we've got nothing pressing? +Jan 23 13:49:57 <Blackb|rd> wolf31o2|work: what kind of hw is poseidon? +Jan 23 13:50:02 <agaffney> wolf31o2|work: get a couple of those RAM cards that taco got +Jan 23 13:50:07 <agaffney> Blackb|rd: amd64 +Jan 23 13:50:16 <wolf31o2|work> Blackb|rd: dual opteron, 4g, scsi... decent, but nothing special +Jan 23 13:50:20 <Blackb|rd> agaffney: I meant chassis-wise. +Jan 23 13:50:30 <Blackb|rd> I.e. SCA? +Jan 23 13:50:31 <agaffney> Blackb|rd: you mean for the scsi? +Jan 23 13:50:33 <agaffney> ah +Jan 23 13:50:34 <wolf31o2|work> Blackb|rd: umm... white box +Jan 23 13:50:54 <wolf31o2|work> the disks are SCA, but the disk array really just needs to be replaced +Jan 23 13:50:56 <Blackb|rd> Depending on the needs I can get at cheap HP/Compaq universal drives. +Jan 23 13:50:57 <wolf31o2|work> it's only UW +Jan 23 13:51:17 <wolf31o2|work> internal (boot), it's sata... +Jan 23 13:51:26 <Blackb|rd> We're switching from SCA to SAS, so we have some drives to spare every now and then. +Jan 23 13:51:41 <dsd_> wolf31o2|work: i have an item to raise once this discussion is over (also have to leave in 5 mins) +Jan 23 13:51:41 <wolf31o2|work> agaffney: my only concern with those is they don't give us much space... they're 16GB max +Jan 23 13:51:50 <wolf31o2|work> dsd_: go ahead, then... +Jan 23 13:52:03 <agaffney> wolf31o2|work: that'll certainly do for a few concurrent catalyst builds +Jan 23 13:52:08 <agaffney> even for livecd +Jan 23 13:52:15 <dsd_> wolf31o2|work: saw the approx dates on dberkholz's summary, how do you feel about fitting 2.6.24 in there? (it'll be released any day now) +Jan 23 13:52:40 <wolf31o2|work> (as for the last item, what failed w/ 2007.1, I think we've got *most* covered already in this meeting, so we'll skip that one... meeting's been long enough) +Jan 23 13:52:44 <dsd_> hm actually, not so sure we can stable it in time +Jan 23 13:52:55 <wolf31o2|work> dsd_: not by the Mar 17th date? +Jan 23 13:52:59 <dsd_> usually like to have about 6 weeks +Jan 23 13:53:22 <wolf31o2|work> dsd_: we'll discuss that OOB... but we'll do the usual... you say it's ready, and we'll use it +Jan 23 13:53:23 <agaffney> dsd_: we'd stable in the snapshot if it would be stable by release time +Jan 23 13:53:24 <dsd_> ok, doable if you can cut it close again +Jan 23 13:53:44 <dsd_> (and assuming the release isnt horribly broken) +Jan 23 13:53:46 <Blackb|rd> Alpha doesn't care (much) the nast glibc futex bug affects everything since something in .21 and the non-bootyness of the ES40 is 2.6.23.* and 2.6.24* anyway. +Jan 23 13:53:55 <wolf31o2|work> dsd_: somewhat... I don't want to make any real last-minute changes anymore, though... so it might have to wait +Jan 23 13:54:01 <dsd_> ok +Jan 23 13:54:10 <dsd_> will talk about it in a few weeks then +Jan 23 13:54:17 <wolf31o2|work> we'll just take it as it comes... +Jan 23 13:54:18 <wolf31o2|work> yeah +Jan 23 13:55:20 <wolf31o2|work> ok... so about 2007.1... what failed? well... for one, I did... I simply didn't have the kind of time that I had with previous releases... also, the security team was awesome and were pumping out bugs at a very fast rate, which I couldn't keep up with... I think some mechanism for any releng to update the snapshot would help... anything else? +Jan 23 13:55:34 <wolf31o2|work> (that we haven't discussed) +Jan 23 13:56:08 <dsd_> if it's been discussed then ignore me, have we discussed date secrecy w.r.t 2008.0 to avoid that particular problem again? +Jan 23 13:56:09 <Blackb|rd> I think a changelog of some kind for the snapshots would be nice. +Jan 23 13:56:24 <Blackb|rd> but that'd come for free with a repo. +Jan 23 13:56:36 <wolf31o2|work> dsd_: considering we discussed the dates openly in here, I don't think there's any secrecy, but everything is going to be announced from now on +Jan 23 13:56:39 <agaffney> dsd_: tentative dates have been thrown around in this meeting, and the log will be public +Jan 23 13:56:51 <dberkholz> could you coordinate more closely with the security team IRT looking into publication times in advance +Jan 23 13:56:53 <dsd_> wolf31o2|work: ok, good solution :) +Jan 23 13:56:58 <wolf31o2|work> Blackb|rd: I was thinking a repo, actually... +Jan 23 13:57:04 <dberkholz> and possible doing security bugs en masse around release cycles +Jan 23 13:57:20 <dsd_> nice to see releng opening up a bit like that, and this meeting +Jan 23 13:57:26 <dsd_> gotta run, byebye +Jan 23 13:57:26 <wolf31o2|work> dberkholz: I actually already do that... the main problem is really brow-beating the arch teams into submission so I can update the snapshot +Jan 23 13:57:32 <wolf31o2|work> dsd_: bye +Jan 23 13:58:18 <wolf31o2|work> so, anything aside from better handling of the snapshot (security and other fixes) ? +Jan 23 13:58:41 <wolf31o2|work> if not, I'm going to open the floor to questions/comments... +Jan 23 13:58:42 <Blackb|rd> wolf31o2|work: would it be feasible/worthwhile to set a kinda deadline: "If you don't object to this snapshot within X days, you accept everything that's in it." +Jan 23 13:59:04 <agaffney> Blackb|rd: who is that deadline for? +Jan 23 13:59:17 <wolf31o2|work> Blackb|rd: that's already rather implicit, but we could explicitly state it... not sure what it would change, though... and what andrew said... heh +Jan 23 13:59:21 <Blackb|rd> agaffney: arch teams/whoever needs to test +Jan 23 13:59:27 <rangerpb> wolf31o2|work, features/functions requests? Do via email or hold a priv meeting? +Jan 23 13:59:58 <agaffney> Blackb|rd: well, if something's broken, we'll fix it +Jan 23 14:00:05 <agaffney> if it's a late stabilization, fsck 'em :P +Jan 23 14:00:29 <Blackb|rd> 'k +Jan 23 14:00:58 <wolf31o2|work> rangerpb: wait for the email on -releng, you missed it when I asked (a couple times, even) early in the meeting +Jan 23 14:01:09 <wolf31o2|work> rangerpb: or just wait for open floor, actually +Jan 23 14:01:32 <wolf31o2|work> ok... I'm opening the floor +Jan 23 14:01:36 <rangerpb> minor comment wolf31o2|work we're working hard to merge ppc and ppc64 teams to powerpc, as we have discussed. We'll continue to work this and it will be reflected in the profiles and specs. I'll make sure JoseJX completes this before first snap +Jan 23 14:01:37 <armin76> gtg, if something is broken, blame Blackb|rd +Jan 23 14:01:56 <wolf31o2|work> rangerpb: no problem... let me know if you need help +Jan 23 14:02:01 * wolf31o2|work sets mode -m #gentoo-releng +Jan 23 14:02:04 <wolf31o2|work> bleh +Jan 23 14:02:06 <armin76> pwned +Jan 23 14:02:08 <wolf31o2|work> stupid chanserv +Jan 23 14:02:09 <rangerpb> I think we're cool. it's largely a reorg thing +Jan 23 14:02:19 <agaffney> heh, I guess the channel mode is locked +Jan 23 14:02:49 <wolf31o2|work> yeah +Jan 23 14:02:54 <wolf31o2|work> one second... +Jan 23 14:04:19 <wolf31o2|work> that works +Jan 23 14:04:21 <wolf31o2|work> heh +Jan 23 14:04:25 <fisinen> Any changes for sparc dev? +Jan 23 14:04:28 <m4rku5> First of all I'd like to thank the releng team for making this meeting in the public and giving the interrested user some more insight. I definitely see some decent progress here and am looking forward to testing the 2008.0 beta since I'll have lots of free time in march :) (Oh and I'd love to get a limited Edition 2008.0 DVD) +Jan 23 14:04:29 * wolf31o2|work sets mode +t #gentoo-releng +Jan 23 14:04:29 * wolf31o2|work sets mode +c #gentoo-releng +Jan 23 14:04:29 * wolf31o2|work sets mode +n #gentoo-releng +Jan 23 14:04:59 <wolf31o2|work> fisinen: ? +Jan 23 14:05:00 <cryptix> m4rku5: ++ :D +Jan 23 14:05:02 <agaffney> fisinen: what do you mean? +Jan 23 14:05:17 <armin76> he means if agaffney will stop slacking! +Jan 23 14:05:24 * agaffney stabs armin76 +Jan 23 14:05:34 <Nysander> it was probably discussed few times before i went to track developement of gentoo, but i want to ask if it is possible to make release media contain grub patch for hires and prettylook from suse? +Jan 23 14:05:47 <agaffney> Nysander: that has nothing to do with releng +Jan 23 14:05:57 <agaffney> Nysander: file a bug in our bugzilla +Jan 23 14:05:59 <wolf31o2|work> Nysander: that would be a request for the grub maintainers... we don't maintain many packages, at all +Jan 23 14:06:02 <fisinen> no no, we'd just like to see a wider support sparc platform +Jan 23 14:06:13 <ryker> I really like the store bundle idea. People will buy it if it's something special. +Jan 23 14:06:17 <wolf31o2|work> Nysander: as Andrew said, file a bug and see what happens... +Jan 23 14:06:19 <agaffney> fisinen: wider how? this is probably a question for #gentoo-sparc +Jan 23 14:06:24 <Nysander> this bug is filed for long time now +Jan 23 14:06:36 <Nysander> and ebuild is ready +Jan 23 14:06:58 <wolf31o2|work> fisinen: if a sparc platform isn't supported, it's an issue with the kernel/libc/etc that the sparc team will need to fix... we simply package things +Jan 23 14:07:06 <Nysander> but i see this as making release media looking better +Jan 23 14:07:08 <rullzer_> Wow great timing. I got home at 22:30 so just finsihed reading when. I to would like to thank you for making this meeting public. Really appriciated. +Jan 23 14:07:13 * rullzer_ is now known as rullzer +Jan 23 14:07:13 <RedThunderNL> @m4rku5 Posters packed with the DVD would be awesome too!! I'd love to have one :) +Jan 23 14:07:15 <wolf31o2|work> Nysander: send me the bug number and I'll watch it +Jan 23 14:07:24 <Nysander> wolf31o2|work: one moment +Jan 23 14:07:24 <angelos> ok, I take it that the most important stuff is discussed? getting kinda tired heh +Jan 23 14:07:59 <wolf31o2|work> (can we keep the comments to a minimum if they're not questions or adding to the conversation... I *really* appreciate the thanks, but I'm also taking time out of work for this, so need to make it as quick as possible) +Jan 23 14:08:03 <agaffney> angelos: it's open floor, so yes :P +Jan 23 14:08:05 <fisinen> wolf31o2|work: ok i will check out #gentoo-sparc +Jan 23 14:08:13 * angelos leaves then, nn +Jan 23 14:08:16 <agaffney> same here...questions only, please +Jan 23 14:08:19 <agaffney> I'm at work +Jan 23 14:08:19 <dberkholz> regarding the automated building thing. what relationship does this have to solar's tinderbox? could we start distributing "unofficial" binpkgs based on this? +Jan 23 14:08:21 <wolf31o2|work> fisinen: they'll definitely be able to help you and discuss it further than we can +Jan 23 14:08:38 <rullzer> about selling dvd's. I think you do not need to bother that in western europe. You could just try to find some nice gentoo users willing to burn 4 dvd's a year +Jan 23 14:08:39 <agaffney> dberkholz: no proposed relationship, atm +Jan 23 14:08:45 <infinity_d> as far as feedback from users on releases, what type of feedback are you looking for besides features people want? things like "this livecd isn't loading the proper video drivers for me, so i can't use X during install" (i've actually had that problem before)? +Jan 23 14:08:50 <dberkholz> agaffney: is it obsoleting, replacing functionality, etc? +Jan 23 14:08:53 <wolf31o2|work> dberkholz: it has no relationship, at all... I've been talking with him, and we'll see where we can help each other, but other than that... +Jan 23 14:09:02 <agaffney> dberkholz: none of the above +Jan 23 14:09:16 <agaffney> dberkholz: the automated builds are only for QA...not to distribute +Jan 23 14:09:35 <m4rku5> what kind of ios will be released with 2008.0 ? only installcd-minimal and the livecd ? +Jan 23 14:09:37 <dberkholz> not by releng anyway =) +Jan 23 14:09:44 <wolf31o2|work> infinity_d: something like that, yes... we're planning on having a little checklist for people to run through, that can be used for both the betas and also for releases... so we'll get the best info we can get +Jan 23 14:09:44 <agaffney> infinity_d: we definitely want feedback about bugs, and I bet you have an ATI card :P +Jan 23 14:09:52 <agaffney> m4rku5: probably the same as 2007.0 +Jan 23 14:10:05 <m4rku5> ok +Jan 23 14:10:08 <agaffney> m4rku5: minimal/livecd/livedvd for x86/amd64 and minimal/universal/GRP for most others +Jan 23 14:10:09 <infinity_d> agaffney: correct, ATI mobility radeon x700 +Jan 23 14:10:21 <NeddySeagoon> Are there any plans to make it easy to install from a USB memory stick with this release. It comes up on the forums more and more frequently ? +Jan 23 14:10:23 <agaffney> infinity_d: the ATI drivers were missing from the 2007.0 livecd due to a problem with the profile +Jan 23 14:10:35 <fisinen> one more question. How do I go about becoming a dev? I've sent emails but no response +Jan 23 14:10:42 <agaffney> NeddySeagoon: test it with the betas, and if it's a quick fix, we'll take care of it +Jan 23 14:10:42 <m4rku5> agaffney any chance users can build their own amd64 universal ? ;P +Jan 23 14:10:51 <wolf31o2|work> NeddySeagoon: I am planning on making sure the USB guide is correct and works... +Jan 23 14:11:05 <Nysander> wolf31o2|work: this feature bug id is 103272 +Jan 23 14:11:05 <NeddySeagoon> wolf31o2|work, agaffney thanks +Jan 23 14:11:09 <wolf31o2|work> m4rku5: you can do that now... emerge catalyst +Jan 23 14:11:14 <agaffney> m4rku5: they've always been able to. you just need dev-util/catalyst and the specs from CVS +Jan 23 14:11:29 <ColdWind> fisinen: write to recruiters@gentoo.org (or maybe ask in #gentoo-dev-help?) +Jan 23 14:11:34 <m4rku5> so the specs are ready and the universal amd64 is just not distributed ? +Jan 23 14:11:50 <wolf31o2|work> fisinen: send an email to recruiters@gentoo.org... if you don't hear from someone in a couple days, let me know... +Jan 23 14:11:51 <Nysander> i use this for quite long time with different builds of kernel 2.6.23 and 2.6.24-rc +Jan 23 14:11:55 <agaffney> m4rku5: well, there aren't specs for x86/amd64 universal, but it's easily adapted from the minimal +Jan 23 14:12:11 <agaffney> m4rku5: universal is just minimal with the stages and portage snapshot overlayed +Jan 23 14:12:17 <m4rku5> ok i guess i gotta read up the catalyst docs +Jan 23 14:12:25 <fisinen> ColdWind; wolf31o2|work: thank you +Jan 23 14:12:28 <wolf31o2|work> m4rku5: no, you have to make your own specs... we dropped the universal a long time ago and won't be going back... the universal is identical to the minimal, except it has distfiles and stages on it, via an overlay... so it isn't hard +Jan 23 14:13:20 <m4rku5> ok ty :) +Jan 23 14:13:27 <Opfer> fisinen: -> Query +Jan 23 14:13:48 <wolf31o2|work> ok... thanks everyone +Jan 23 14:13:57 <agaffney> no more questions? +Jan 23 14:14:01 <rbu> one thing +Jan 23 14:14:06 <calculus> m4rku5: also watch for the catalyst 1.x versus 2.x and the corresponding docs +Jan 23 14:14:23 <rbu> wolf31o2|work: you said the last release majorly suffered from security merges. is there anything we can do to improve process this time? +Jan 23 14:14:25 <wolf31o2|work> don't use the online docs... they've never been updated for 2.x +Jan 23 14:14:31 * vorlon078_ is now known as vorlon078 +Jan 23 14:14:40 <wolf31o2|work> I'm going to update that $soon +Jan 23 14:14:50 <m4rku5> ah good to know ;D +Jan 23 14:15:07 <agaffney> rbu: don't do a slew of security bumps during the release cycle :P +Jan 23 14:15:07 <wolf31o2|work> rbu: well, the main issue wasn't your team, it is pestering the arch teams, especially some of the non-security-supported ones... +Jan 23 14:15:39 <wolf31o2|work> rbu: for 2007.0/2007.1's release cycles, I updated *every* security update in the snapshot, not just the ones we ship +Jan 23 14:15:49 <wolf31o2|work> it worked fine for 7.0, but was too much for 7.1 +Jan 23 14:15:55 <rbu> wolf31o2|work: ok, one thing: let us know when time approaches you (or who) wants to be in CC for all embargoed bugs +Jan 23 14:16:18 <agaffney> rbu: release@g.o, or is that too public? +Jan 23 14:16:34 <rbu> agaffney: can't add aliases to restricted bugs +Jan 23 14:16:46 <agaffney> fail +Jan 23 14:16:46 <wolf31o2|work> there's 2 possible "solutions" but I don't really like either... one is to go back to only updating the packages we ship... a second is to ignore the security-unsupported arches and only worry about the supported ones... that's how we used to do things... but I switched away from that long ago... +Jan 23 14:16:47 <rbu> since you'll have to be logged into bugz with that alias +Jan 23 14:16:52 <wolf31o2|work> rbu: ehh... me +Jan 23 14:16:53 <rbu> to view/reply +Jan 23 14:17:12 <agaffney> rbu: true, but we'd still get the bugmail +Jan 23 14:17:53 <m4rku5> btw is there any thing (as in testing stuff / reporting bugs) users could do to help before beta1 to improove 2008.0 ? +Jan 23 14:17:57 <dberkholz> rbu: can you do something like post just the dates and not the names of the affected packages, just that they're on the release media? +Jan 23 14:18:06 <agaffney> m4rku5: before beta1? not really +Jan 23 14:18:07 <wolf31o2|work> m4rku5: just normal bug filing +Jan 23 14:18:07 <rbu> agaffney: but you could not see the initial comment if you weren't cc'ed from the start +Jan 23 14:18:12 <m4rku5> ok +Jan 23 14:18:16 <rbu> wolf31o2|work: don't worry about unsupported arches, really. +Jan 23 14:18:53 <wolf31o2|work> rbu: well, our policy was pretty much that we updated anything that went under /releases (which is nearly everything) +Jan 23 14:19:08 <wolf31o2|work> rbu: where is there a list of security-supported arches? +Jan 23 14:19:28 <rbu> dberkholz: what do you mean by date? +Jan 23 14:19:36 <rbu> wolf31o2|work: http://www.gentoo.org/security/en/vulnerability-policy.xml +Jan 23 14:19:37 <dberkholz> rbu: embargo date +Jan 23 14:19:52 <dberkholz> like "there will be a security bug released on 2008/02/25 and it affects the livecd" +Jan 23 14:20:38 <wolf31o2|work> dberkholz: well, I've already been getting added to CC on them before they go public... it's been working fine enough... it's more the ones that already are public that have been an issue +Jan 23 14:20:44 <rbu> dberkholz: usually wolf would know about that by being cc'ed -- where else should it be posted? +Jan 23 14:20:59 <dberkholz> is he allowed to share that information with anyone else on releng? +Jan 23 14:22:00 <rbu> dberkholz: usually yes, if it is being communicated through private channels and it's not like 10 people, and people obey the "keep quiet" rule +Jan 23 14:23:09 <welp> bed, gnight +Jan 23 14:23:14 <rbu> if the bug is semi-private (that is, we have a public update in the tree, just the details are not public), there's no harm in saying "update this package, you know why" +Jan 23 14:23:17 <rbu> dberkholz: ^ +Jan 23 14:23:21 <wolf31o2|work> rbu: would you guys welcome me recruiting someone as "security liaison" for releng? that might mitigate some of the issues... they'd be the main contact, just like with the arches +Jan 23 14:23:51 <rbu> wolf31o2|work: which packages would do you want to get updates in for, just those inside a stage? +Jan 23 14:24:03 <wolf31o2|work> usually, I just update the snapshot and don't really say why... but yeah, I pull from the rsync tree for snapshot updates... so everything is public by the time it gets in our snapshots, anyway +Jan 23 14:25:05 <wolf31o2|work> rbu: umm... the package list would be huge... I mean, it'd be stages + kernel + gnome/kde/xfce/X/etc + GRP packages... might be best to just have a security guy for the team and include releng as if we were just another arch +Jan 23 14:25:20 <wolf31o2|work> we can take care of removing ourselves if it doesn't apply to us +Jan 23 14:25:55 <rbu> all packages on GRP = all major packages +Jan 23 14:26:04 <wolf31o2|work> pretty much +Jan 23 14:26:57 <wolf31o2|work> I can get you a fairly comprehensive list of the packages we explicitly merge, if you like... but it changes fairly frequently... +Jan 23 14:27:16 <rbu> no need, i just assume "all" ;-) +Jan 23 14:27:24 <wolf31o2|work> rbu: probably easiest that way +Jan 23 14:27:39 <l33tlinuxh4x0r> hi all +Jan 23 14:27:41 <rbu> will you guys be watching security@ or do you need a cc? +Jan 23 14:27:57 <agaffney> l33tlinuxh4x0r: you're a little late, and you nick makes my eyes bleed +Jan 23 14:28:09 <wolf31o2|work> rbu: for the private stuff, it'l go to the coordinator... for public stuff, CC please +Jan 23 14:28:13 <l33tlinuxh4x0r> Yeah I guessed that I just missed the meeting +Jan 23 14:28:26 <agaffney> l33tlinuxh4x0r: it started 2.5 hours ago +Jan 23 14:28:31 <agaffney> ended ~30 minutes ago +Jan 23 14:28:34 <rbu> one personal comment: if in question, just get a release with some extra vulnerabilities out. you'll never fix 100%, and before cancelling, just release. +Jan 23 14:28:41 <wolf31o2|work> rbu: and since our release times will be announced, you'll know when our snapshot is, so you'll know when to start adding us... but I can be sure to remind you guys when we snapshot +Jan 23 14:28:45 <l33tlinuxh4x0r> did they discuss a release date? +Jan 23 14:28:54 <rbu> because compared to status quo, which is 2007.0, even a "vulnerable" release would be _less_ vulnerable +Jan 23 14:29:05 <wolf31o2|work> rbu: true +Jan 23 14:29:10 <agaffney> l33tlinuxh4x0r: you can read the meeting log once it's posted +Jan 23 14:29:12 <l33tlinuxh4x0r> what did I miss about 2008.0 +Jan 23 14:29:17 <l33tlinuxh4x0r> cool +Jan 23 14:29:20 <agaffney> we're not going to summarize it for you +Jan 23 14:29:25 <superfranky> rofl +Jan 23 14:29:27 <l33tlinuxh4x0r> will it be posted on gentoo.org homepage? +Jan 23 14:29:36 <rane> hopefully +Jan 23 14:29:37 <wolf31o2|work> no shit... I just spent 3 hours of my life, I'm not summarizing it +Jan 23 14:29:39 <wolf31o2|work> heh +Jan 23 14:29:41 <agaffney> heh +Jan 23 14:29:44 <l33tlinuxh4x0r> lil +Jan 23 14:29:46 <l33tlinuxh4x0r> lol +Jan 23 14:29:56 <wolf31o2|work> yes, it'll be posted... now, do you have a question or are you just being social? +Jan 23 14:30:04 <rbu> wolf31o2|work: just cc us in your "we took snapshots today" mail if you send that +Jan 23 14:30:06 <l33tlinuxh4x0r> I was/am working and couldnt "listen" to the meeting +Jan 23 14:30:09 <wolf31o2|work> rbu: k +Jan 23 14:30:13 l33tlinuxh4x0r leio lenaic likewhoa loki_val lonex lu_zero +Jan 23 14:30:23 <agaffney> if you don't have an actual question, please be quiet so we can finish the open floor section of the meeting +Jan 23 14:30:40 <wolf31o2|work> actually, I think we're done... +Jan 23 14:30:44 <dberkholz> i'm summarizing it, actually. +Jan 23 14:30:53 <rbu> wolf31o2|work: about release<->security liaison. i guess since you'll keep oversight over things, that would be you anyway, no? +Jan 23 14:30:56 <dberkholz> i'll post here for review in a while +Jan 23 14:31:02 <wolf31o2|work> dberkholz: nice... did you log it, too? +Jan 23 14:31:05 <agaffney> then...do we want to put the +m back? +Jan 23 14:31:14 <agaffney> wolf31o2|work: phreak`` said he was logging +Jan 23 14:31:22 <agaffney> and I can always extract it from my logs +Jan 23 14:31:24 <agaffney> I always log +Jan 23 14:31:26 <wolf31o2|work> rbu: for now, it's me... I'm hoping to find someone else to do it, though, so I can spend time working on the other issues and such +Jan 23 14:31:41 <dberkholz> wolf31o2|work: looks like it logged, yeah. +Jan 23 14:31:59 <dberkholz> sometimes irssi gets confused, but it got this one. +Jan 23 14:32:01 <rbu> dberkholz: this is not part of the meeting anymore? have to write a summary for security team myself then +Jan 23 14:32:01 <wolf31o2|work> heh... nevermind, I logged it, too +Jan 23 14:32:09 * rangerpb is now known as rangerhomezzz +Jan 23 14:32:19 <agaffney> we've probably got ~20 different logs +Jan 23 14:32:25 <wolf31o2|work> rbu: this was the open floor... so kinda part of the meeting... hehe... +Jan 23 14:32:34 <wolf31o2|work> dberkholz: were you going to summarize the open floor, too? +Jan 23 14:32:34 <dberkholz> rbu: perhaps you could summarize for me what you got out of the security talk. +Jan 23 14:32:39 <wolf31o2|work> there we go +Jan 23 14:32:40 <wolf31o2|work> heh +Jan 23 14:32:48 <rbu> wolf31o2|work: it's ok. but i guess having an official goto guy would be good, as like for arches. then we would have docs on who to CC +Jan 23 14:33:01 * agaffney calls "not it" +Jan 23 14:33:03 <dberkholz> wolf31o2|work: last 3 things i have are a few lines each about release organization, store options, and hardware issues +Jan 23 14:33:10 <wolf31o2|work> rbu: right, like I said, for now, that guy is me... +Jan 23 14:33:23 <wolf31o2|work> dberkholz: k... can you send it to me or whatever once you've got it done? +Jan 23 14:33:31 <dberkholz> 22:30 < dberkholz+> i'll post here for review in a while +Jan 23 14:33:38 <wolf31o2|work> thanks diff --git a/meeting-logs/20080123_initial_2008.0_summary.txt b/meeting-logs/20080123_initial_2008.0_summary.txt new file mode 100644 index 0000000..9d1b26f --- /dev/null +++ b/meeting-logs/20080123_initial_2008.0_summary.txt @@ -0,0 +1,139 @@ +2008.0 release +-------------- + +Tentative schedule (dates may change): + Feb. 1 Snapshot of the tree taken + Feb. 25 Docs due to GDP from release coordinators + Feb. 25 Snapshot frozen for beta + Feb. 29 Docs finalized + Mar. 3 Beta1 released + Mar. 14 Final upload + Mar. 17 Release + +To make it easier for the release engineering team to collaborate, +releng lead Chris Gianelloni (wolf31o2) wants all architectures to build +their releases on public developer machines. This also means that if an +architecture's release coordinator can't finish the release, anyone else +can pick up the work and continue. + +The releng team plans a few changes to profiles. Moving to multiparent +profiles will significantly reduce the profiles' maintenance effort and +code. It may happen for 2008.0; Chris said, "I am not sure that we'll +have time to do the profile switching, but I'm going to try to come up +with it. The plan will be to create 'normal' 2008.0 profiles, and I'll +work on making them multi-parent." Another suggested change to profiles +is the creation of an all-new multiparent subprofile, optimized for +Gentoo development. The 'developer' profile would be based on the +desktop profile with an additional set of FEATURES useful to developers. + +Chris also proposed changes to the release process, including when +profiles are created for future releases. "As soon as we finish up a +release," he said, "I'd like to go ahead and create the new release +stuff in the repos." That includes new catalyst spec files in the releng +repository, a new development profile, and possible changes to the +handbook. Making this change means work can immediately start instead of +waiting until the next release cycle, and it's also useful for automated +builds. + +Public beta releases make up a major component of the new plans. Chris +hopes beta releases will increase community participation as well as the +quality of the final release. These feature-complete public betas will +require the earlier development of release materials. To ensure +sufficient time exists for testers to take advantage of the beta, a +mandatory 2-week testing period will follow the beta release. + +A comprehensive testing checklist will be developed on the gentoo-releng +mailing list, as will a list of which details of testers' machines and +environments they should turn in to developers. Since in the past, +testers often provided insufficient information to releng developers +because their instructions weren't specific enough, a new form will +include all of the required questions and details. "Sadly you almost +want a beta that phones home as to what it was successfully run on," +said Tom Gall (tgall). Christian Faulhammer (opfer) suggested using a +hardware reporting tool such as app-admin/hwreport. + +Finally, Chris wants to make himself less of a single point of failure. +Conversion of the releng repository to SVN and maintenance of a shared +release checklist there will help, he said, so everyone can make updates +as they get things done. + +A question about security came from Tobias Klausmann (Blackb|rd), who +asked how to avoid the same problem that hit 2007.1. "Part of the +problem last time was that Chris was trying to update the snapshot for +*every* security bug," said x86 release coordinator Andrew Gaffney +(agaffney), "instead of just the ones that affected the media." + + +Automated builds +---------------- + +Branching profiles and specs for the next release early will enable the +releng team to begin automated and regular internal release builds. +"They'll check out the SVN for the new release and use the new dev +profile," Chris said, "so we find problems and fix them year-round +instead of just during the release cycle." + +Making these internal release builds publicly accessible can be done by +individual architecture teams, but Chris said the releng team won't +distribute them automatically. This could help people with architectures +that require hardware support nonexistent in the last release. + +"My long-term goal for the automatic builds is for us to be able to use +them as our initial beta," Chris said. "We pick one that's as close to +release quality as possible, release it as beta, *then* start the +release cycle." + + + +How do we involve the community more? +------------------------------------- + + +Some of the most popular suggestions--addition of the public beta, +letting users help with beta testing, and explicitly asking for +feedback--were already proposed for other goals like improving release +quality. They may also help involve the community. + +Another popular idea was creating a survey to ask users for the top +features they want in the next release. This might happen with simple +infrastructure like email or the forums, since Gentoo doesn't yet have +anything better. + +The last idea for getting users involved is to simply do a good job of +announcing the beta. Gentoo users have many places to get information +(GMN, forums, website, planet, many mailing lists), so getting news +about the beta to anywhere more users see it will require wide +dissemination of the announcement. + +In addition to users, the releng team wants to get more developers +involved. Donnie Berkholz (dberkholz) suggested appealing to their +motivations for being a developer in the first place by doing things +like testing their own packages on the LiveCD. And Chris also wants to +get developers more actively involved rather than just being consumers. + + +Other topics +------------ + +Using full-fledged project-management software like dotproject was +proposed by developer Preston Cody (codeman). Chris said he just used a +spreadsheet but wanted something more collaborative, so Preston +suggested Google Docs. For now, the release checklist will live in SVN. + +Switching away from the Cafepress store was also brought up. Cafepress +doesn't produce DVDs, but the releng team wants to encourage LiveDVD use +because they have so much more content. Chris is researching some +alternate stores. + +Regarding hardware, most architectures have working, hosted development +machines. The main amd64 dev box, poseidon, could use some faster hard +drives for the automated builds. + +Since constant security vulnerabilities forcibly canceled the 2007.1 +release, improving how the releng team deals with them was a concern. +The main change will be a closer collaboration between the security team +and the releng team. "Releng is going to be treated just like an arch, +with a security liaison and everything," Chris said, "and we'll be added +to CC just like any other architecture. Before, I just found out about +stuff when either someone told me or when it hit the arch aliases I was +on ... neither of which was very good for planning." |