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