As I've said many times, last week we celebrated a CDD Development Camp in Castelló (Spain); this entry is to summarize my impressions about the event and to start some discussions on the mailing lists. I hope that others will also send their summaries and talk about their impressions, as I was busy the last evening and probably missed something else during Friday morning and the first day.
Fist I have to say that all the people listed on the Wiki was able to come, and all of them were very nice, I like to meet people interested in Debian because usually I see that, despite being all different, we have always something else in common that is not simply related to Software, or at least that is my impression.
During the first morning we were all together on a room of the third floor, it was a lot better than last year's place (not really difficult) and once we set up the network connectivity (again, much better than last year, as the WiFI just worked for the almost everybody and the ones without direct connection were able to get it through an Ethernet hub that was connected to a laptop), we started to talk about the current status of things.
Of course we missed some people to explain some of the tools (i.e. nobody was familiar with FAI, so there was no explanation of it's features), but a lot of issues were discussed and we saw that there were agreement on some points:
A Live CD system that uses the installer hardware detection and mounts the CD as a writable file system using a technologies like the device mapper or unionfs is the way to go, as allows to do real tests of custom installation (a CD like this was presented on the debian-edu meeting in Greece, it can be downloaded from http://).
We want predictable releases, right now nobody has big problems because everybody sees the end of the tunnel for Sarge, but (and that's my opinion) the etch release will be the really important point: if we manage to release it in a reasonable period (12/18 months) the release management for CDD can be easily synchronized with Debian, if not we will have to do something to be able to be based on Debian and still do our own releases.
A simpler system to generate debian-cd's would be great, as the current script is too centered on the official CD set and that's not usually what a CDD needs.
My cddtk proposal had been read only by some of the attendants, but for almost all the points I mentioned we all agreed (and some of the points not discussed will be revisited in the near future, as I found I had some miss understandings about debconf).
In any case I 'll try to continue developing the cddtk ASAP, probably with the help of some of other developers that were on the room (in fact that was my main interest on the DevCamp, ;).
Ah, and I'll try to write a short summary of the proposal at the beginning of the document, that way maybe someone will at least will read that.
After lunch we had a lot of round tables and Conferences, the one that interested me most was the one given by Bart Cornelis about desktop customization; besides explaining clearly how we can customize the most popular desktops he also talked about a package to help us on the definition of profiles that will be uploaded soon to Debian... I'm sure I'll try it.
After the last round table (that was being celebrated at the same time as the talk about Debian-Edu) there was an extra talk by Richard Stallman, that appeared in the Congress by surprise (at least for me).
Some of the people attending the DevCamp went to see the Stallman's talk against patents, but most of us stayed on our room talking with Mark Shuttleworth about Ubuntu, Debian and Custom Distributions.
One idea that was clear to all of us is that, if Ubuntu keeps it's compatibility with Debian, at least on the package level, the CDD tools would be useful for both systems, so there is room for cooperation.
In fact Mark assured us that they will keep resynchronizing with Debian Sid, because other ways they won't be able to maintain such a big number of packages (that is, they know they have to maintain a delta against Debian to be able to provide some things that are key for them, but they don't want to change everything, because in this case they will need too much manpower to handle the differences). I'm skeptical, but who knows, maybe in a couple of years Ubuntu and Debian still coexist and cooperate, we will see.
After that we went back to the hotel to go to the conference dinner, that was quite long (I was told that some of the people left it at 3 a.m., I went away earlier, as I was really tired).
The second day started at the same room, about 10:00 a.m., but I had to introduce someone on the ground floor.
When I arrived to the room there was Petter talking about multi-level configuration; the basic idea is that, to be really configurable, programs should be able to read it's configuration from multiple files, allowing them to override each other when needed (i.e., a program has it's standard configuration on /usr/share/, but it also reads administrator overrides on /etc/ and on the user's home directory).
If the programs worked that way none of the Debian packages should need to provide an /etc file (unless when it is generated by debconf, and in that case it generates a really simple file) and upgrades should replace standard configurations automatically (the ones on /usr/share, never modified by the user) and take care of converting the administrator's files on /etc files to newer formats on upgrades (only if needed, of course).
Using this model the complexity of upgrades goes to upstream and/or the package maintainers, but we have a system that can be customized and upgraded better than now. The proposal has it's problems (i.e. this does not generally allows package downgrading), but all of us agreed on it being a good idea that we should try to propose to upstream maintainers and to other distributors (that way they'll also ask for this kind of support to upstream authors).
Another thing we talked about was debconf preseeding, and I have to admit I was totally wrong about how it has to be handled (none of my packages is using debconf now, but I they did they would all be buggy, as I was treating debconf as a registry, despite knowing it is not one).
My main miss conception is related at how already seen questions are handled, now I know that, once a configuration file exists, if a package is reconfigured the values shown to the user have to be taken from the configuration file, not from the debconf database, because that is the only way to keep user changes when reconfiguring, as he or she can modify things without using debconf.
Having that clear, presseding only makes sense when first installing a system, because if you reapply a presseeding and reconfigure without user interaction the system is going to take the /etc file values, not the ones included on the preseeding.
Now that I now that I believe we should use preseeding for installers, but to have full control over customized systems and be able to upgrade them we need another mechanism, which is probably the scripts system I describe on my proposal.
Well, after the morning session I had to be on the main congress room to talk about Debian and LliureX, and was not able to follow the discussions, but I'm sure someone else will be able to send a summary to the debian-custom list.
After the Congress ended I said goodbye to everyone and went to Valencia, but that is another story I've already blogged about.
