This is a list of issues for discussion for CentOS-4. Most of it is based on my experience from building/maintaining CentOS-2 and observing CentOS-3. I have not seen the CentOS-4 beta yet so I don't know if any of this is already done. If these have been discussed on IRC then perhaps someone could produce a shot summary of the outcomes....? * Just call it CentOS-4 not 4.1 etc. Too confusing and serves no real purpose * All modified rpm should use mezzanine or equiv. This makes it easier to track changes, build updates and generate a report on what has changed. * Modified rpm should have .c4.n added to the release - c4 = centos 4. (works well once the 4.1 is dropped) - .n = a number starting at 1. The spec only 0 does not scale if you need to make another spec only change. The changelog will tell you what has changed. * Mission: To stay as close to RedHat as possible Issues: some things need to be modified to support this. For example the cpu/memory restrictions will be removed(like in CentOS-3). Given that we are doing this, should we also lift other artificial constraints like installing on i386? If we start making changes, where do we draw the line? In CentOS-2 I have fixed some small 1 line bugs (mostly packaging issues) but this might be a contentious issue. What about a CentOS+ repo. for enhanced versions? * Issue: should the distro be self hosting? I think as long as the requirements are available from the addon/extras repos. then I don't think this is needed out of the box. Obviously the build environment needs to be well documented and reproducible. * Mission: Remove RedHat trademarks. Issues: should we replace all rh logos/icons or just the ones required by RedHat? I think if the file/words can be replaced then yes, but package names etc. should be left alone. * Issue: yum Don't ever auto-modify yum.conf. Too confusing. Invent a system for selecting/allocating a mirror. Users should always use a 3rd party mirror and not the main caosity mirrors. Issue: every mirror has different paths. We need to clean up all the symlinks and multi versions on the mirrors. (We need someone in change of the mirrors) * Issue: gpg key. This should be installed by default so the user does not have to find & import it. At a minimum it should be in /usr/share/doc/centos-release and work like a RedHat box. * Issue: release QA Before public release, a QA procedure should make sure that there are no obvious problems (like the comps issue of 3.3). * Idea: automatic patch building. It should be possible to build most patches without intervention. I don't know what the current systems in place are but if there were autobuilt unsigned patches available it would allow - testing of patches before they are 'officially' released - checking the progress if a patch Using an automatic system to apply CentOS specific modifications means that in some cases, the CentOS specific changes can also be autoapplied and the package build. Obviously before a package is officially released, someone needs to check that it is correct and works etc. John. -- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin