1 |
Greg KH wrote: |
2 |
> So the main bit that happened, was an agreement to allow the |
3 |
> bugzilla.kernel.org database, hold distro kernel bugs. The upstream |
4 |
> developers want to see the bugs earlier, and faster. So I'd really |
5 |
> recommend throwing them there almost immediately if we can, unless |
6 |
> it's obvious the problem is in our stuff (bootsplash, vesa-ng, etc.). |
7 |
> |
8 |
I really like this idea. I'm slightly worried that you'll end up with a |
9 |
pile of other bugs that just waste time though (not from Gentoo, but |
10 |
from other distros). About a month ago I tried to get a patch from |
11 |
Mandrivas's kernel. It was 2.6.12 with loaaaads of patches, so many that |
12 |
they revealed a very obscure bug in diffstat when trying to create these |
13 |
statistics: |
14 |
|
15 |
2257 files changed, 363439 insertions(+), 22957 deletions(-) |
16 |
|
17 |
As well as those ~700 patches, they also include 38 tarballs of |
18 |
out-of-tree modules (mostly drivers), which they then build into the |
19 |
kernel RPM. So you might even get some bugs on things that aren't even |
20 |
in the kernel tree in those cases... |
21 |
|
22 |
But for Gentoo at least, I think both the Gentoo maintainers and the |
23 |
upstream developers would find it really useful. |
24 |
|
25 |
> The big issue is that the reporter would have to create their own |
26 |
> account there to get notified of changes, and mirroring the stuff |
27 |
> back into our bugzilla would get to be a big chore. So I'd recommend |
28 |
> just starting out with a few of them, and see how it goes. |
29 |
|
30 |
I agree that there is an issue with getting the reporter to sign up for |
31 |
yet another bugzilla, but I don't think there would be any problem with |
32 |
mirroring: I don't see why we'd need to mirror anything back, except |
33 |
maybe the resolution of the bug. I need to give this more thought. |
34 |
|
35 |
> Another off-hand remark that happened was a conversation about the |
36 |
> bootsplash and vesa-ng code. People were wondering why the hell it |
37 |
> wasn't in mainline already! The bootsplash stuff was remarked by the |
38 |
> whole group involved that it looked great, and was way better than |
39 |
> the old implementation. Yeah, I know some RH people still don't like |
40 |
> the whole idea, as they use X for their splash stuff, but it |
41 |
> shouldn't be hard to keep that under control, as I think the code is |
42 |
> pretty self-contained with no real issues if you turn it off. |
43 |
> |
44 |
> And the same for vesa-ng, although most present were not even aware |
45 |
> of it. |
46 |
|
47 |
I'd love to see these merged. |
48 |
|
49 |
Michal can provide you with clearer answers but here is what I know: |
50 |
|
51 |
fbsplash was submitted about a year ago. Some developers commented "do |
52 |
it in userspace, you can do almost all of that there", and others gave |
53 |
feedback on things which must be changed or fixed before it is to be |
54 |
considered. I don't think Michal has had time to finish addressing those |
55 |
points -- when are you going to get SuSE to hire him? :) |
56 |
|
57 |
I don't think fbsplash is too far away from possible kernel inclusion, |
58 |
but vesafb-tng is. It is x86-only and is a big hack by design. Here's a |
59 |
recent comment from Michal: |
60 |
|
61 |
> Wrt the future of vesafb-tng -- it's unlikely any code can be moved |
62 |
> to vesafb. The way to go (and this seems to be both my own opinion |
63 |
> and the opinion of the fb developers) is to have the vm86 code |
64 |
> separated into an userspace application (which will also make it |
65 |
> possible for the driver to work on non-x86, since x86emu can be used |
66 |
> in place of vm86). I'm going to work on this during the summer, but I |
67 |
> wouldn't want to set any deadlines or promise completion dates just |
68 |
> yet :) |
69 |
|
70 |
|
71 |
So, did you show them the speakup patch? :) |
72 |
*runs for the hills* |
73 |
|
74 |
Daniel |
75 |
-- |
76 |
gentoo-kernel@g.o mailing list |