[Grml-devel] Minutes from the Grml developer meeting, October 2011

Richard Hartmann richih.mailinglist at gmail.com
Fri Oct 14 14:52:35 CEST 2011

On Fri, Oct 14, 2011 at 13:28, Michael Prokop <mika at grml.org> wrote:

> Focus on two targets:
>  * Ship an Install&Rescue system (targeted ISO + Netboot options)
>  * Provide & Maintain texttools inside Debian (zsh package, various
>   texttool configs we want people to use)

This is probably oart of "rescue", but "testing and verification" is
very important as well, imo. We are using grml on literally every
single machine we deploy to test that the hardware is OK.
Maybe "hardware test-suite" is even something that should go into
future PR stuff.

> Everything else (for what no developer invests enough time) should
> go: this includes accessibility support, old texttool
> configs/wrappers, various X tools/WMs, compilers.

Hard decision, but probably a good one in the long term.

>  * https://github.com/grml/grml-constitution/blob/master/Constitution.md

Teams can grant commit access to their repos, but according to this,
they can not actually make someone a _member_ of the team. Although
the implied meaning is clear, if you do write a constitution, it would
be better to do it 100% self-consistently.

As I understand things, a dev who disappears for a year will get
demoted to contributor and then removed from contributors immediately.
Fringe case, but I just wanted to make sure I understand this

> Deprecate i386 port

By i386, you mean 32bit Intel-based architecture, not actually moving
from 386 to 486 or 586, I presume?

There's the corner case of running grml on Alix boards, but I have not
done that in ages.

Other than those almost-embedded systems, every current
Intel/AMD-based achitecture CPU can execute x64, the only notable
exception being first-generation Atoms.

All in all, 2014 seems like a realistic and safe goal, especially
considering that it's easy to watch download stats.

> Using Github

Github refuses to let you auto-commit/export from them to other repos.
You have to rely on local hooks or query & pull.

Other than that, there offering is very nice indeed.

> As part of our ongoing efforts to get as many of our packages to
> Debian and keep in our repositories just what doesn't fit in Debian
> (yet), we did further cleanup reviews.

Very worthwhile goal.

>  * grml-insomnia: grml2hd will be renamed to grml-insomnia and moved
>   out of PATH so people don't use grml2hd for something else than
>   demonstration purposes

What's the reasoning/mnemonic for this name?


More information about the Grml-devel mailing list