[Grml-devel] About the new grml direction

[Ulrich Dangel]

* Christoph Biedl wrote [27.12.11 21:54]:
> So why not dropping -medium, and also the 650 Mbyte limit for -full? 

JFTR the limit was 700MB as we weren't able to put it into 700MB anyway.

grml-xl (the old one thing for all) is a lot more of work than the
current grml-full. We needed to make a cut to do the release. 

> > For me personally it was always unclear what the purpose of Grml was,
> > what's its vision, what belongs on the CD, what does not.
> 
> That's what you do user survey for. And you actually did.
 
We made some mistakes in the user survey. Some questions (which i
formulated) were unclear. Especially the CD/DVD limit ones. We were
event told so by the users taking part in the survey.

> So for me, there are two use cases:
> 
> 1. Quite often: Use -small as a fits-everywhere system for rescue,
>    recovery and repair on the root file system..

I think we already had the discussion once but I can see the reason you
don't want to place the ISO image on /usr or somewhere else.

> 2. Every now and then: Use -full to have a browser without touching
>    the actual installation and/or without leaving traces behind.

This still works with the current release.

> But I always wondered who needs -medium and if asked, abandoning it
> would have been my first suggestion. But now, giving the impression
> you've dropped everything _but_ -medium is sending the message I'm not
> the target audience. Not a message I like.
 
No. We dropped all flavours and created one new one. Big difference. And
at least i can see somehow the need for grml-small.

Many people doing the releases never felt really strongly about grml-xl 
and rarely used it. This is not a good thing to base your work on if you
don't use it anyway.

> > And i think with this release it became clear and obvious.
> 
> For me, it's mostly: "We try to make one that fits all" (*)

Fits installation&recovery, but yes.

> > Releasing all different kind of flavours like
> > grml-{full,medium,small}{64,32} resulted in six isos, which all had to be
> > tested. And again there were typically not many people involved in
> > testing the releases.
> > It was neither fun nor interesting nor rewarding.  It was just a lot of
> > work for nothing really important. And this is not something new.
> 
> Please don't tell you want to punish the satisfied Grml users just
> because they were happy with the way Grml was.
 
We don't punish anyone. We don't offer treats or use carrots an sticks.
The changes were not because we wanted to punish anyone but because the
old process did not work. It was really stressfull and hard doing the
releases. No one liked it, wanted to do it. So we had to change
something managable and sustainable. Another option would have been stop
doing any releases.

> But now:
> 
> * Not everywhere the disk has enough space in /boot for the 2011.12
>   image, and re-partitioning is a tiresome process even if using LVM
>   (what I do), I don't want to do that again.

I understand that. And don't change a running system etc.

> * The copy operation of toram *is* fast on shiny new hardware. It's
>   not so funny on older one. That time tripled now - no thanks.
 
You can do that always directly from the booted system with the grml2ram
command. You can do this while working and don't have to wait until it
is finished.  (Disclaimer, i just noticed that due to some path changes
the command no longer works atm)

> > That being said, i think that we maybe should/can reintroducde
> > grml-small. Removing packages from a package list should result in less
> > problems than adding new ones. But first we must get rid of grml-small
> > specific hacks (IMHO).
> 
> Bring back good ol' S^H-small. It's the main thing why I use, like and
> promote Grml. Doing a private -small release for myself might be a way
> to go but that's not helping, neither the Grml project nor other
> people who miss -small, too.
> 
> So, what were the -small hacks? Open tickets, or provide a pointer,
> and we'll see.
 
I think for one the missing locales, exlcuding vmlinzu/initrd from the
squashfs, the different behaviour wrt consoles (should be all the same),
the specialized 98-clean-chroot script which removes imho too much stuff
like aptitude. Main packages would be grml-live as well as
grml-autoconfig.

> > If you look around the internet about discussions for rescue
> > systems, network stuff or other Live-CDs, Grml was never recommended as
> > the first Distribution. Typically only one persons in the threads
> > writing Oh but i like Grml. Thats it. And i personally think it is
> > because Grml was everything and nothing. No area it was especially good
> > at but tried to please everyone.
> 
> Rest assured Grml has a very pleased user base, perhaps a bit too
> quiet, and as always more taking than giving. A "Keep Grml just the
> way it is, it's almost perfect" might be boring but it's actually a
> compliment about the things you've achieved in the past seven-ish
> years.
 
We would kept it the way it was _if_ the process would have been
working. It were typically two to three people involved in the release
process. It was not working for last release and even did not work for
2009.10. No one stepped up or offered something. So we had to change
something to cope with the releases. Otherwise we would have dropped it.

> So, please don't worry too much. Dare to ask for help if you need it.
> And bring back -small.
 
We may.

Ulrich

P.S: IMHO this clear cut was the best thing that happend ever to the
project. Just because people started to discuss the project.
P.P.S: Due to the cleaner and simpler release we are also already
discussing a fixup release for the introduced bugs.
-- 
twitter: @mr_ud  | identica: @mru
IRCNet:  mru     | freenode: mrud