22C3 BOF Wrapup

Benjamin Schieder <blindcoder-1k+CIuW/[email protected]>
Newsgroups gmane.linux.distributions.rock.devel
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi list.

First, let me welcome you to the new year. One day late, but hey, I've had a
hard time setting the Windows machine up to allow my laptop to share its ISDN
internet connection.

Anyway, here's a longer explanation of the stuff we decided on at 22C3.
Clifford, Daniel, Hannes and I were there and discussed the topics on the
ROCKDoc TopicsCCC2005 page. Here's what we decided on:

Website stuff
	We decided to replace {www,doc}.rocklinux.org with one WediaWiki installation.
Clifford will set up the installation and move the www stuff there and I'll work
the doc pages in. This will then replace www and doc will die.

Patch commiting
	A security team will be formed (currently consisting of daja who is responsible
for paving the way things will be handled) with the target of getting subscribed
to vendor-sec. The security team will have write acces to subversion for getting
security stuff in with as little delay as possible. A new mailing-list
rocklinux-security will be formed for our advisories.

New release model
	There will no longer be any "ROCK Linux" releases. There will only be "Crystal
based on ROCK revision foobar" releases. For example:
	2006-02-01: Release of Crystal 3.0 based on ROCK revision 7625
	2006-04-01: Release of Crystal 3.1 based on ROCK revision 9582
	2006-08-01: Release of Crystal 3.2 based on ROCK revision 12549
	2006-12-24: Release of Crystal 3.3-23C3 based on ROCK revision 14692
	2007-02-01: Release of Crystal 4.0 based on ROCK revision 15723
		Discontinuation of Crystal 3.x series.

Infrastructure for new release model
	We need binary repositories for gems. The idea is to create a "portal" site for
all ROCK based distributions. This should include links to the distributions,
information about them, access to the distributions gems (if applicable),
torrents as needed and other things we didn't think of now.
	What we currently also need is computing power and architecture maintainers.
Clifford will maintain crystal/x86. We would like to have support for
crystal/powerpc and crystal/x86-64, too. So if you have the hardware to sponsor
or want to maintain them yourself, please step up.

Adjusting the shipped crystal config
	Currently, /etc/ROCK-CONFIG contains whatever configuration choice one makes in
scripts/Config. This is bad for example if you happen to use MythTV output,
cluster builds or other such things. This needs to be sanitized. The suggestion
here was to use a sysfiles-hook.

Dealing with a massively outdated trunk
	The CheckVersion script is to be replaced with cliffords webbased 'checkver'.
Blindcoder will create a console interface to it.

Enforcing justifications for package modifications
	This was delayed due to netrunners absence.

hotplug/rockplug/udev and system startup

Rockplug will die. /etc/rc.d/rc.local will be created and be empty after
installation. After installation, the system administrator can place commands
here which should be run at system startup.

Splitting up system.init
	system.init should be divided into small parts which will be placed into rcS.d.

Adjusting the people that can vote on dead repositories
	Dead repositories will be identified using the subversion logs and the packages
be put into public/ and after an acceptable timeframe dropped if necessary.
Creation of the [M] maintainer flag will be automated.

Customisation of Crystal builds
	Should be done in one way or another.

Old or obsolete packages
	apmd, pcmcia-cs and modutils and maybe others will be stashed away in a legacy/
repository and disabled in crystal.

dietlibc
	We need a maintainer for the dietlibc package. If noone steps up, it will die.

Xorg X11R7
	blindcoder will handle it.

autopch
	clifford will handle it. autopch is a tool to create a pre-compiled header file
for all source files of a package. This gives a considerable compilation speed
improvement because usually a lot of source files include the same headers.
These are then processed once for each source file. Using autopch they are
processed once and once only.


So, this is it. If i've screwed up somewhere here, clifford and daja are allowed
to blame it on me being bad at remembering such stuff.


Greetings,
	Benjamin
- --
 _  _     _   _            _
| \| |___| |_| |_  __ _ __| |__
| .` / -_)  _| ' \/ _` / _| / /
|_|\_\___|\__|_||_\__,_\__|_\_\
| |  (_)_ _ _  ___ __
| |__| | ' \ || \ \ /
|____|_|_||_\_,_/_\_\
Play Nethack anywhere with an x86 computer:
	http://www.crash-override.net/?nethacklinux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDuQEXr0OTeImXvg8RAn4qAKCkSaAt4fOmVcoeW4NkGbaPVAwNRACfc5b2
zA7KDbDtMt95ZLEwR45GBTw=
=N9Pk
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.