Johannes Winkelmann wrote:
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.
Well, who is in charge of the systems now? I've never even had an account on any of these. I know this is cliche, but maybe there is some kind of web management software that can automate this.
- 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.
Those of you that know my rants on IRC surely know my support of democratic processes. However, democracy is not a cure for all ills. I really think with Per not being a benevolent tyrant, we need to select another benevolent tyrant and maybe a group of "elders" to bounce ideas off, but that one or two people having the veto decision. I know it always sucks to have ones ideas rejected, and such, but I think for the good of the project, it's better to have someone in charge, instead of a big voting booth on every issue, where a decision cannot be made until everyone weighs in, and slackers like me take a long time. Just my opinion. I've long wanted to get prt-get as president, so Johannes, to me, is a reasonable candidate. :) I think we should vote in a dictator who can propose policy and decide it, and have a group of people who can debate the alternatives.
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.
This is tricky, since this always ends up in "power vs simplicity". I think RPM and DEB systems are so far away from the goals of crux, that they're rendered useless for our purposes. What other solutions are out there? What about the pkg system that NetBSD has created? pkgsrc, I think. Are there systems out there we could adopt that do what we need without having crux maintain them? Also, I think (and this was my vote from the beginning, that Per and some other people did not like, but I'd like to bring up anyway) we need to thin out core. Core is the base of crux, and by having it really really slim, we reduce the amount of work that needs to be done to update version to version, and reduce testing. We can leave the other packages in opt and let those update on an independent timeline. Just and idea. I also wouldn't be opposed into combining some ports into on distro port, like what bsds do, so multiple source packages are install ad one core port. That is, we could combine: binutils, util-linux, etc into one core-bins port. Again, just an idea. Victor The Long Lost one...