Minutes from the Grml developer meeting, October 2011
Hi,
during those days we had a small Grml developer meeting. Christian, Jimmy and me met in Graz/Austria and got a bunch of stuff done. I'm happy to provide the minutes from the Grml developer meeting in this mail.
Report from the Grml developer meeting, October 2011 ====================================================
What has been achieved ----------------------
* wiki.grml.org has been migrated to our new server (+ dokuwiki was upgraded) * boot-info-script has been packaged and uploaded to Debian * currently sitting in NEW: http://ftp-master.debian.org/new/boot-info-script_0.60-1.html * major cleanups in grml-scripts, grml-scripts-core and grml-network * figured out technical details regarding usage of github (see below) * discussed project vision, team constitution, rebranding of grml-small/grml-medium, package removals and efforts towards providing our packages to Debian and welcoming new contributors
What needs to be done in the next days/weeks/months ---------------------------------------------------
* github (ch + mika) * mailing list migration (jimmy) * improve infrastructure documentation (jimmy) * move daily build server (ch + mika) * fix the hostname from DHCP story in grml and grml-debootstrap (mika + ch) * live-initramfs patches (ch + mika + mru) * proper backup infrastructure for our server (admins?) * iso2usb (jimmy) * package cleanup/removal (everyone) * call for netscripts on mailing list in order to provide examples with grml (mika) * planning of bi-weekly online team meeting (mika) * further streamline release process (ch + mika) * upcoming stable release planned for 2011-12-06
The Grml Project Vision -----------------------
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)
Everything else (for what no developer invests enough time) should go: this includes accessibility support, old texttool configs/wrappers, various X tools/WMs, compilers.
Grml Team Constitution ----------------------
We want to provide a transparent way how the Grml team works. To reflect that we came up with a document which provides the constitution for the Grml team:
* https://github.com/grml/grml-constitution/blob/master/Constitution.md
Based on recent activity the team was restructured:
* Developers: Alexander Wirt, Christian Hofstaedtler, Frank Terbeck, Gerfried Fuchs, Michael Prokop, Ulrich Dangel * Contributors: Jimmy Gredler, Michael Gebetsroither * New contributors considered for joining the team: Axel Beckert, Bernhard Tittelbach
Grml Developer Roles/Teams --------------------------
We'd love to actually have commitments from our individual developers on what they'll be doing. Please add yourself to http://www.doodle.com/pke97c2k9xd5nrpa with which teams you'll want to be associated with.
Deprecate i386 port -------------------
i386 is an architecture which is annoying to maintain, since most (all?) of us developers work on 64bit only systems nowadays and building packages for i386 kind of duplicates our efforts WRT packaging and kernel maintenance.
Since too many users still need 32bit kernels we'd like to remove the i386 port of Grml in 2014 (or earlier if demand drops/it becomes completely unmaintainable).
Removal of grml-small flavour -----------------------------
The grml-small flavour is a hack and something most (all?) of us developers never use ourselves. grml-medium is the much cleaner and better working solution. If someone really needs a minimalistic ISO other distributions exist (Damn Small Linux, Tiny Core Linux) which do a better job at that than we do.
Instead we propose the rebranding of grml-medium into grml-light and keep grml-full as it is. (And remove grml-small.) This slightly reduces the amount of ISOs we have to build (also on a daily base), removes all the hacks we're doing for grml-small, reduces space on the mirrors, and to some extent users hopefully will be a little less confused what the Grml variants are about.
Using Github ------------
We're officially using github (https://github.com/grml/) as a mirror of the Grml git repositories (http://git.grml.org/) since 19th of june 2011. Since we want to improve the workflow with Grml's contributors (forking, pull-requests,...) we decided to further evaluate the usage of Github as our primary Git server. git.grml.org would be used for the private repositories and as a backup/mirror of our github repositories. A mirroring script has been written and available post-receive hooks have been evaluated.
Funny side note: exactly while we reviewed the issue tracking workflow of Github we noticed that "Issues Dashboard for Organizations" feature (see https://github.com/organizations/grml/dashboard/issues), which launched just a few minutes(!) before we looked at it (see https://github.com/blog/959-issues-dashboard-for-organizations for the official announcement). :)
Bug Tracking ------------
Since we're providing more and more packages officially to Debian another bug tracking system is showing up on the Grml developer front: http://bugs.debian.org/
To avoid further confusion that's our plan:
* packages available in Debian should use bugs.debian.org * packages which have a git repository at github should be handled on github by default (unless already used inside Debian BTS, then the user chooses) * virtual package/repo "grml" for handling meta packages/non-packages * bts.grml.org might be deprecated in the long run if it works as expected
Package removals ----------------
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.
The following packages and repositories will be gone by 30th of October 2011 unless we receive qualified objections:
* aesutil * bfa * bkp * deletemail * dupseek * evms * ex * ext3rminator * ftpbackup * gateguardian * gifshuffle * grml-vpn * grml * grml64 * grml-small * grml-btnet * grml-docs * grml-firefox (replaced) * grml-files (replaced) * grml-lsb * grml-mercurial-utils * grml-roadmap * grml-runit * grml-scanpartitions * grml-templates * grml-terminalserver-data * grml2hd-util: merged with grml-insomnia (see below) * icmp-mtu * icmp-quench * icmp-reset * lcdtest * rootsh * nat-traverse * ncp * prosilla * shadowfs * shish * smap * tal * thc-ipv6 * thinkfinger-tools * upgrade-oldest
The following packages and repositories need love:
* grml-debugtools: needs love * grml-desktop: needs configfile discussion * grml-etc: remove various old configs/skel * grml-etc-core: needs love * grml-git-doc: replace with contributing doc TBD * grml-git-tools: needs love, possibly move contents to Debian * grml-homepage: reevaluate for homepage ideas * grml-infrastructure: split source-report away * grml-policy: move to new homepage * grml-saveconfig: remove, provide upgrade path * grml-shlib: check who uses this * heirloom-sh: if anyone still wants to see it available provide it officially within Debian, otherwise we're going to remove it from our repos * any takers for Debian? * ptfinder: considered for inclusion in Debian Forensic
New packages considered:
* 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
* grml-zshrc: migrate zsh stuff from grml-etc-core and include grml-gen-zshrefcard in it to have a better name for advertising our Zsh configuration
Thanks for listening,
regards, -mika- - for the Grml project
On Fri, Oct 14, 2011 at 13:28, Michael Prokop mika@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 correctly.
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?
Richard
* Richard Hartmann richih.mailinglist@gmail.com [111014 14:53]:
On Fri, Oct 14, 2011 at 13:28, Michael Prokop mika@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.
Yes, good point. This is part of the install goal.
Deprecate i386 port
By i386, you mean 32bit Intel-based architecture, not actually moving from 386 to 486 or 586, I presume?
x86-32, Yes.
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.
Well, 'refuses'. You can do post-receive (HTTP POST) hooks. We plan to do a daily mirror run using this: https://github.com/zeha/assorted/blob/master/github-mirror/github-mirror-all
 * 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?
Grml Devs are plagued by nightmares of users running grml2hd. Just kidding ;-)
-ch
* Richard Hartmann wrote [14.10.11 14:52]:
 * 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.
Good catch. But the document also does not specify what a team is an what the rights of team members are. I don't think it is really necessary to specify that a team can make someone a member of the team.
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 correctly.
IMHO no as the timer only starts after you change roles. That means if you get demoted to contributor you will stay contributor at least for one additional year.
I think we definetly need a better description as your interpretation is also valid.
Ulrich
Teilnehmer (4)
-
Christian Hofstaedtler -
Michael Prokop -
Richard Hartmann -
Ulrich Dangel