Hi there, [ this is rather long. my apologies ] With Per's retirement, I think it's important to take the time and discuss a couple of issues to keep CRUX in shape, and morale up :-). This mail contains a non-exclusive list of things I consider important. I'd like to propose that in the close future (first step), we focus mainly on three things (more on the individual point later in this mail): 1. getting 2.2 out, and having it working well 2. addressing issues we had even with Per on board 3. redistribute Per's work In a second step, let's have CRUXCon 2006 in autumn with as many CRUX devs as possible, and define a common vision for the future. This gives us half a year time to collect ideas and work on prototypes (i.e. for the 3.0 package management as discussed at the former two CRUXCon's). Also, I'd like to propose having weekly or bi-weekly IRC meetings on a defined weekday (i.e. wednesday), to allow slightly more focused discussion and allowing those with less interest to constantly idle on IRC to take part in IRC discussions. Simone suggested to list the dates on a wiki pages, which whould also allow to attach notes like agenda or results; However those meetings are supposed to me non-formal, and attendance is purely optional. ----- Notes on the items from the list: 1. Getting 2.2 out 2.2 is getting close, and we should make sure we have opt tested when we release it. I'm not sure how many of us have a 2.2 test install yet, but I plan to write some notes on how to install it in a chroot to make testing as simple as possible for everyone. We'll also need to update the handbook, and find out where to host the releases (the main file server up to now was fukt, to which no one besides Per has access). 2. Addressing current issues In no particular order: - Add more content to the wiki (howto's etc); we've been discussing this a couple of times already, there seem to be users interested in helping, we need to define some basic structures though to make it usable. This is not critical in general, but frustrating for those who'd like to contribute - write a port validator to detect potentially malicious or dangerous commands in Pkgfiles; run on contrib nightly or so; suggest its use on the relevant wiki pages - move the mailing lists (depends mainly on getting the subscriber lists and archives; I requested those, so as soon as we get them we can do the move). We'll also need list administrators for them - find a maintainer for prtsync (Jay originally wrote it but lacked time/interest, I added a number of quick fixes to address problems appearing during the test runs); there are a number of annoyances, missing features, and things to clean up; nothing too urgent though - define contact persons for certain subsystems; examples for this are: server maintenance, subversion, bug tracking, website accounts, prtsync, mailing list admin, release engineering, user account management and access control. A lot of this stuff currently ends up in my (and probably others') private inbox, which is slightly tiresome. - define a more democratic way do take decisions. Things like the core/opt separation or WiFi kernel module inclusion are typical examples for this, both were basically decided ad hoc on IRC by those online at that point in time. 3. Redistribute Per's work This includes - Per's ports - Handbook maintenance - Release engineering - pkgutils and ports(8) As for pkgutils and ports, there's nothing fundamentally wrong with the two (I know some of the community members tend to have different opinions :-)). However, during CRUXCon 04 and 05, we discussed a lot of ideas which pretty much imply a rewrite of large parts of pkgutils (which was Per's plan initially BTW, however I guess we'll have to take over here). This might be a good moment to collect the quite large number of ideas implemented in the various forks and rewrites, and define a subset of them we want to support in our package management utilities (either directly or by allowing extensions), also considering the various utilities on top of it (pkg-get/pkgsync, prt-utils, prt-get etc.). Obviously, this is a very crucial part of CRUX, and I feel that we should plan that carefully, to get both a powerful and PER/CRUX-like solution. Okay, so much for now, and sorry again for the length. Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Zurich, Switzerland http://jw.tks6.net