ROCK @ 19C3

The 19C3 BOF

Note to the confused
19C3 is the 19th annual hacker conference organized by the Chaos Communications Club in Berlin, Germany, from 27-29 December 2002. A BOF is an informal grouping of people with a similar specific interest (e.g. at a conference). It is usual for a ROCK BOF to take place at any large gathering of ROCK developers.

The 19C3 ROCK BOF took place, officially, at 1600 hours on 28/12/2002 in the dark and sweltering ROCK Linux cave in the Hackcenter. In the normal chaotic fashion, not everyone who wanted to attend was present, and not everyone who was present wanted to attend; the BOF was stopped at 1700 hours as several people wanted to attend a talk, and there was never an official continuation because people were always disappearing, though there were various sporadic discussions between smaller groups of people until around 2000 hours on 29/12/2002.

Pictures from the event are available here and here. Thanks to Dagmar and niko. The pictures are also mirrored here along with more pictures from FAKE.

Guide to nicknames used in this summary
clifford = Clifford Wolf
chris = Chris Hamilton
esden = Piotr Esden-Tempski
jocelyn = Jocelyn Yeo
huebi = Andreas Huebner
niko = Nikolaus Filus
praenti = Michael Obster
pjotr = Pjotr Prins
rxr = René Rebe
ripclaw = Stefan Koerner
SMP = Stefan Paletta

Not everyone who was at 19C3 is listed. For a complete list of people who were there, look here. Information about developers can be found here.

Summary of 19C3 BOF discussions

Prepared by jocelyn.
Version 0.1 uploaded 02/01/2003.
Send corrections and comments to the mailing list with subject: 19C3 BOF Summary.

1. Use of English
Raised by: pjotr (on mailing list), chris
Discussion: It is quite common for German to be heard/seen on IRC where most of the people are German speakers. Non-German speakers request that all communications regarding ROCK on the IRC channel be conducted in English, which is the official language of ROCK. This is to allow non-German speakers to benefit from the discussion, to allow the IRC logs to be read and searched by the search engine, and to avoid alienating non-German speakers who may wish to contribute to ROCK.
Action: Everyone is to speak English as far as possible when discussing anything related to ROCK on IRC.

2a. Improvement of website search engine
Raised by: esden, praenti
Discussion: The mailing-list archive and IRC logs should be searchable (separately from the whole ROCK website), so that a particular discussion can be more easily found.
Action: clifford believes the new version of the search engine will allow searches restricted to the mailing-list archive and IRC logs. If so, this will be implemented.

2b. The organization of the website
Raised by: praenti
Discussion:praenti stated that many people have told him they cannot find what they want on the website (it is unclear what these people were looking for). There was then some discussion, generally rather defensive in nature, about the quality of organization of other distributions' websites.
Action: Although no specific solution for the problem was suggested, this issue is related to item 4 (see below).

3. Writing articles
Raised by: clifford
Discussion: There are not enough people writing articles about ROCK. These articles are needed not only for our Rolling Rock magazine but also for external magazines/websites which will help publicize ROCK. clifford pointed out (yet again) that it does not take much effort to write a short article, which can be on any subject related to ROCK. chris also pointed out that many magazines (e.g. SysAdmin, Linux Journal) will publish almost anything and pay you for it. clifford stated that he wants an article from the 1.6 stable team for every issue of Rolling Rock. He also reminded esden that he is waiting for esden's article.
Action: esden will write his promised article. huebi (or someone from the 1.6 stable team appointed by huebi) will write an article for every issue of Rolling Rock. Everyone else is encouraged to write something, anything at all. Particularly useful would be articles targeted towards new users (see item 4 below).

4a. Insufficient resources for new users
Raised by: rxr
Discussion: New users may find it difficult or intimidating to start using ROCK, especially if they are coming from a MS Windows background. There should be some short instructions and FAQs on the website (not only in the ROCK guide and source). Some progress has already been made to help new users. huebi pointed out that in 1.6, there are instructions on-screen at every step of the installation process. clifford also pointed out that in 1.7, the user can choose the dialog-based install, which has explanations for each step, or even the automatic install. niko described his work on a guide to what programs are available for each function (e.g. mail). It was generally agreed that more simple and easily-accessible information on the website would not be a bad thing. huebi called for a non-developer who could see things from a new user's poin of view to write such documentation.
Action: niko will continue with his program guide. jocelyn, who knows a hint when she hears it, will write some basic docs for new users. Anyone else who would like to help with writing FAQs or new-user documentation is welcome.

4b. Lack of 1.6 webpages
Raised by: rxr
Discussion: There is not enough overview information about 1.6 on the website. It would be good to have some pages similar to the dROCK overview, and not just changelogs. huebi again called for a non-developer who could write such documentation.
Action: huebi (or someone from the 1.6 stable team appointed by huebi) will write the webpages. jocelyn will help if required.

4c. General information about ROCK not up to date
Raised by: clifford
Discussion: Part of the problem for new users is that the information about ROCK on the website does not accurately reflect ROCK's status as a "distribution build kit". This concept is quite difficult to explain but should be made clear so that new users have a good idea what ROCK is.
Action: No apparent action was decided upon. Presumably clifford will rewrite the relevant pages?

5. ROCK Linux Guide
Raised by: rxr
Discussion: The Guide should be opened up so that others can help pjotr work on it. Also, some version of the Guide should always be accessible from the website.
Action: To be discussed with pjotr, who was not present.

6a. How to choose the new stable tree maintainer
Raised by: clifford
Discussion: How should a stable tree maintainer be chosen (election, volunteer, appointed by clifford, etc)? No one seemed to have any opinion on this question. However, rxr said that he would be willing to be the stable maintainer if he has time, and will give up some of his packages to make more time. chris also mentioned that he would like to do it if he had experience. According to clifford, the fork of 1.7-dev to 2.0-stable is expected in about 3 months.
Action: Unknown. Further discussion on mailing list?

6b. The stable branch
Raised by: chris
Discussion: chris suggested that in the future (2.0), the development and stable trees should be unified in a versioning system so that the stable maintainer would be able to use the development tree's packages if desired. This would reduce the duplication of effort between the development and stable trees, and allow shorter release times for the stable branch (currently 12-18 months). clifford pointed out that this would not be possible if there were major changes in the package system or core packages which affect many other packages. clifford stated that the stable branch should be forked as late as possible and should only handle security and bug fixes. rxr and huebi commented that some new feature updates must be included in stable releases because of the users' desires (e.g. KDE 3). clifford replied that such users should use a development snapshot instead, which can be still quite stable. There was some later discussion about exploring the capabilities of CVS for the unified versioning system, subject to clifford's willingness to allow this. SMP commented that any discussion about the stable tree is pointless until a new stable maintainer is found, as this new maintainer would then use whatever method he prefers. ripclaw pointed out that in OSS projects there is a high developer turnover, so current developers must lay down rules for future developers to follow, and make it easier for their successors to continue their work.
Action: clifford's view of stable as "security and bugfixes only" is generally accepted. No other decisions were made.