* Walter Haidinger [Sat Jan 07, 2012 at 01:32:41PM +0100]:
Just something for the grml developers to think about: How about splitting grml into supported and unsupported flavors?
The supported flavor would be the current one (grml-medium). This would let the grml developers focus on the grml core and lift them from the burden of testing all the packages (the main reason for dropping former grml-full, right?).
The unsupported flavor would be the former 700MB grml-full, built from grml-live for convenient download but without further time-consuming testing by the grml devel team, i.e. grml-medium with lots of subsequent apt-get installs.
It still needs someone feeling responsible for the unsupported flavour(s). As I already wrote in 'Statement regarding the Grml "reset" with 2011.12 release' [http://ml.grml.org/pipermail/grml-devel/2011-December/000219.html]:
| But it's NOT as simple as just maintaining a software list in a | textfile inside grml-live.git. It's *also* about testing (some kind | of regularly for the daily ISOs and more extensive testing of | release candidates), fixing failing builds (daily ISOs as well as | Git-triggered ones), integration in Grml tools (grml-quickconfig, | grml-x,...) as well as providing sane default configurations and | giving user support ("why doesn't foo work?").
And we just won't have an "unsupported GRML_XL" if no one takes care of according (daily) builds. Work that nobody really notices in the public is taking care of build errors that happen in daily builds every now and then but which prevent us from releasing. And as long as nobody steps up to work on that it just won't happen.
Bug reports would be only accepted for supported grml, like OpenBSD that only accepts reports for GENERIC kernels or Linux for untainted.
I'm not saying it's not worth thinking about it, but: even though it's declared as unsupported it has the risk that people complain about "why does this foo not work? fsck Grml!" (similar to the situation of tainted drivers in the Linux kernel). People still might show up with bugreports which we'd have to answer with "unsupported/won't fix" or don't answer at all and as a result consuming time on both sides of the party without solving our *current* manpower issue (see below).
Yes, I know there is grml-live, but if people would just silently build their ISOs themselves instead of looking for downloads, the mailing-lists would have been quiet after the 2011.12 release, right?
Hehe. :) But our goal is not having traffic on the mailing lists but having happy users *and* developers. ;)
Now, what I'm certainly missing here is the amount of work required for the package selection of the larger grml flavors.
Well, if a few interested and motivated people show up it's definitely do-able in a reasonable fashion.
We owe Brad Cable an answer regarding his mail [http://ml.grml.org/pipermail/grml-devel/2011-December/000216.html] and plan to discuss it as part of our next IRC developer meeting (scheduled for 11th of january, starting at 22:15 CET on #grml). Are you interested in working on a GRML_XL (~700MB) flavour?
I think that the supported/unsupported flavor approach would satisfy both the developers (less package testing, more time to work on grml internals) and the users (have a well-tested grml core as well as a rich package set by default).
Users that aren't happy about the current state should get involved in the project and contribute. IMO providing a have-baked solution doesn't really solve our problem. An open source project can't be consumers-only but also depends on producers. Our "project reset" is not about attracting more consumers or make them happy, but about finding producers so the project can continue to exist.
So if you're interested in contributing to Grml in whatever way, this is your chance. Speak to us, let us know what you're interested in.
regards, -mika-