Hi Lucas, and thanks for your interest in this.
Lucas Nussbaum <lea...@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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130815225223.ga1...@mraw.org
