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-----