Re: status of d-i development -- call for help?
Hi Lucas,
and thanks for your interest in this.
Lucas Nussbaum <leader@debian.org> (2013-08-16):
> It has been suggested to me that the work on d-i could use more
> manpower. AFAIK, the current active maintainer is Cyril Brulebois, but
> I've been told that he could use some help for the jessie cycle. :)
> Cyril, am I correct?
I wouldn't phrase it this way. I'm just the current release manager,
meaning I get to draw the line when we're getting close to releasing
d-i. Early in the release cycle, that doesn't make much sense to try and
release d-i, because of many transitions happening, and because things
like the linux kernel are fast moving targets (see how many uploads it
takes to have something suitable for testing). Late in the release cycle
(before and during the freeze), I might become a bottleneck, because
release managers usually want to get ACKs/NACKs from me on proposed
changes to testing. But I think that worked out mostly OK for wheezy,
despite the late start (I jumped into those shoes not much before the
freeze, so…).
That doesn't mean I'm the sole maintainer/uploader of all the pieces of
that big d-i puzzle; some guys are well versed into l10n, some are
interested in keeping their particular setup working, or care about this
or that architecture in particular; or just scratch their own itch, as
usual!
Anyone can give a hand regarding any aspects, I'm just the guy trying to
put all the pieces together at the end (I guess it's fair to compare
that to release managers trying to get testing into shape to become
stable).
> I think that something that is worth trying is to write a call for
> help with a job description, outlining what are the required skills to
> contribute to d-i.
Basically, not much. Plenty of bugs need triaging, and then fixing. Most
parts are just shell scripts, with the exception of some C bits. Being
able to grasp the extreme modularity might be seen as a requirement, or
just a first step though.
> What usually works great is to provide a micro-task that allows
> prospective contributors to check that they have the basic skills
> required (that also has the advantage to detect people that don't have
> the required skills, and avoid losing time mentoring them). For
> example, adding one's name in an 'About' box.
>
> We could then ensure that that job description gets wide coverage
> (dpn, dda bits).
>
> Could someone write such a job description, or help me write it? I'm
> totally clueless about d-i development, so I would need some help,
> unfortunately.
Maybe Christian could help write bits about d-i? He's quite good at
making (possibly complex) things look easy, and has been involved in d-i
for a looooooong time.
I'll try and think about things I'd like to see done/changed in d-i, and
how that could translate into micro-tasks (but I can't promise anything
in a timely manner). Basically, anyone wanting to get involved might
start looking at triaging bug reports (even though that might not be
the easiest way to start). Non-regression tests would be nice (I haven't
yet resumed working on that part, but hope to do so soon). Maybe some
official images with backported kernels would be nice. (Need to check
what's happening on the kernel side and catch up with Ben's kernel talks
anyway.)
I fear that isn't exactly what you hoped for, but hopefully it clarifies
the current situation a bit.
Mraw,
KiBi.
Reply to: