Christian Faulhammer wrote:
Hi,
any project lead/member can post an answer to this mail for a status
report:
kernel:
Continues to be a small team with desires to grow. Our processes scale
well but recruitment does not. Only real task is to handle
gentoo-sources, 90% of the time is handling upstream bugs reported by
users (the kernel is so big and fast-moving that in order to be more
effective, we have to do a certain amount of work before sending users
upstream).
gentoo-sources patchset continues to shrink, we're very close to vanilla
which is great from a working-with-upstream perspective.
I'm not finding much time to devote to the project due to other
commitments (seems to be an ongoing curse that occurs to anyone taking
the 'lead' position). Not likely to change very soon :( Happy to
consider proven contributors for taking over the lead position, past
present and future.
Mike Pagano continues to be a driving force, continually attacking bugs,
wranging patches and making releases.
Recruited George Kadianakis and Markos Chandras who have helped a lot.
Need to spend more time integrating them and delegating more from me and
Mike.
Overall in good shape with 22 open bugs.
One real drain for us is dealing with crazy gentoo devs who decide to
maintain packages of kernel code outside of the kernel (i.e. external
kernel drivers). These break really often because these external
packages use the internal kernel API which is deliberately unstable.
Many maintainers are responsive, but very often we have to deal with
unresponsive maintainers or packages which simply can't be fixed easily,
this eats a lot of our time, slows down stabling processes, and results
in a bad experience for our users. Asking for extinction of all such
packages is probably unreasonable, but it would be good to see them kept
out of the stable tree or something like that, and we could do a better
job at communicating these maintenance difficulties to our users ("use
at your own risk, this will probably break next week").
My ideas for potential goals/improvements, totally dependent on time and
interest from team members:
- get bugs upstream faster
- fewer and fewer bugs
- accelerate stabling to the previous rate of 3 weeks after every major
release from upstream. (quite time consuming)
- speed up regression handling, prioritise higher
- work more with bugs that we send upstream, right now they get a bit
neglected by us and sometimes by upstream (probably have 30-40 bugs in
this state)
- move genpatches website to independent location, automatically
generated, with permanent/reliable tarball hosting
kernel-misc: Maintains various userspace packages that are tightly
linked to the kernel e.g. jfsutils, module-rebuild, fuse,
also the kernel-2, linux-info and linux-mod eclasses.
Mostly neglected. Some packages have active maintainers, thanks! For the
others I usually do a bug sweep every 6 months or so, taking out the
easy bugs and applying patches from users.
Goals/improvements: find people to take care of this stuff..preferably
people who can just step in and get on with it without me needing to
find recruitment time.
