Greg KH wrote:
> So the main bit that happened, was an agreement to allow the
> bugzilla.kernel.org database, hold distro kernel bugs. The upstream
> developers want to see the bugs earlier, and faster. So I'd really
> recommend throwing them there almost immediately if we can, unless
> it's obvious the problem is in our stuff (bootsplash, vesa-ng, etc.).
I really like this idea. I'm slightly worried that you'll end up with a
pile of other bugs that just waste time though (not from Gentoo, but
from other distros). About a month ago I tried to get a patch from
Mandrivas's kernel. It was 2.6.12 with loaaaads of patches, so many that
they revealed a very obscure bug in diffstat when trying to create these
2257 files changed, 363439 insertions(+), 22957 deletions(-)
As well as those ~700 patches, they also include 38 tarballs of
out-of-tree modules (mostly drivers), which they then build into the
kernel RPM. So you might even get some bugs on things that aren't even
in the kernel tree in those cases...
But for Gentoo at least, I think both the Gentoo maintainers and the
upstream developers would find it really useful.
> The big issue is that the reporter would have to create their own
> account there to get notified of changes, and mirroring the stuff
> back into our bugzilla would get to be a big chore. So I'd recommend
> just starting out with a few of them, and see how it goes.
I agree that there is an issue with getting the reporter to sign up for
yet another bugzilla, but I don't think there would be any problem with
mirroring: I don't see why we'd need to mirror anything back, except
maybe the resolution of the bug. I need to give this more thought.
> Another off-hand remark that happened was a conversation about the
> bootsplash and vesa-ng code. People were wondering why the hell it
> wasn't in mainline already! The bootsplash stuff was remarked by the
> whole group involved that it looked great, and was way better than
> the old implementation. Yeah, I know some RH people still don't like
> the whole idea, as they use X for their splash stuff, but it
> shouldn't be hard to keep that under control, as I think the code is
> pretty self-contained with no real issues if you turn it off.
> And the same for vesa-ng, although most present were not even aware
> of it.
I'd love to see these merged.
Michal can provide you with clearer answers but here is what I know:
fbsplash was submitted about a year ago. Some developers commented "do
it in userspace, you can do almost all of that there", and others gave
feedback on things which must be changed or fixed before it is to be
considered. I don't think Michal has had time to finish addressing those
points -- when are you going to get SuSE to hire him? :)
I don't think fbsplash is too far away from possible kernel inclusion,
but vesafb-tng is. It is x86-only and is a big hack by design. Here's a
recent comment from Michal:
> Wrt the future of vesafb-tng -- it's unlikely any code can be moved
> to vesafb. The way to go (and this seems to be both my own opinion
> and the opinion of the fb developers) is to have the vm86 code
> separated into an userspace application (which will also make it
> possible for the driver to work on non-x86, since x86emu can be used
> in place of vm86). I'm going to work on this during the summer, but I
> wouldn't want to set any deadlines or promise completion dates just
> yet :)
So, did you show them the speakup patch? :)
*runs for the hills*
email@example.com mailing list