We have an internal meeting every few weeks called "dist meeting" that discusses major technical changes in our distribution. Since it's not possible for most of you to attend it, I'd like to try an experiment and share the agenda before the meeting - and the meeting minutes afterwards with you. I'm asking for your feedback on the agenda and any comments that you have and will bring those comments into the meeting and raise the points you've made. Will this work? The planned topics for tomorrow's meeting are: * D-Bus 0.91 and PolicyKit/resmgr We just switched to D-Bus 0.91 and the question arises whether to continue to use resmgr or switch to PolicyKit. * Move to GNOME 2.16 The packagers have started already with the first packages, we want to discuss the timeframe for the move and the move of GNOME to /usr (from /opt/gnome). * SuSEconfig removal SuSEconfig is currently run after each package installation by YaST and is a huge bottleneck. Some scripts have already been removed and we have to discuss how to move on. * update messages general/conditional (e.g. bind) During update of packages they could notify users about changes via email and/or the SuSEplugger (until 10.0, this is not anymore in 10.1). Most of these are outdated and not really usefull anymore and should be removed. The question is how to handle situations like bind where config files get rewritten and the user should be informed if this fails. * Dropping UP Kernel on i386/x86-64 The proposal by the kernel team is to use only SMP kernels and no UP kernel. It's already this way on Xen - there is no Xen UP kernel. Advantages: One less kernel rpm. On 64bit there will be only two kernel rpms then, kernel-default and kernel-xen; and with some luck if paravirt ops works out as designed we can then later drop kernel-xen too and only ship a single 64bit kernel. 32bit could go down to two. Less QA. Less space on ftp servers. Less build time. Avoids a lot of problems with install kernel being different from final kernel. The i386 UP kernel e.g. doesn't support advanced APIC modes, which broke i386 installation of SLES10 on some systems. We've had quite a lot of bugs in this area over the years. Disadvantages: Will be slightly slower and bigger on UP systems. Most of the performance difference is fixed up by kraxel's LOCK prefix runtime patch. Memory usage will be up a bit on UP systems We would lose a few drivers which are BROKEN_ON_SMP. Usually these are long unmaintained drivers which are broken for other reasons anyways so it's not a big loss. Also we never had them in the SMP kernel and most modern systems run SMP kernels. There might be other bugs caused by this, but Fedora has done this before us and they didn't seem to have regretted it so far. * Linker Options and Optimizations We plan to use the recently developed linker optimizations for the GNU hashstyle and use the readonly relocations: LDFLAGS="-Wl,-O1 -Wl,--hash-style=both" (http://lwn.net/Articles/192082/ ) LDFLAGS="-Wl,-z relro" (see http://people.redhat.com/drepper/nonselsec.pdf) Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126