[Grml-devel] how about supported and unsupported grml flavors

[Michael Prokop]

* 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-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://ml.grml.org/pipermail/grml-devel/attachments/20120107/6c139715/attachment.pgp>