From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1G3pcl-0005zJ-LF for garchives@archives.gentoo.org; Fri, 21 Jul 2006 07:40:40 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k6L7duvI020537; Fri, 21 Jul 2006 07:39:56 GMT Received: from mtaout03-winn.ispmail.ntl.com (mta09-winn.ispmail.ntl.com [81.103.221.49]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k6L7dtFl019561 for ; Fri, 21 Jul 2006 07:39:55 GMT Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20060721073955.GHGC1865.mtaout03-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Fri, 21 Jul 2006 08:39:55 +0100 Received: from [192.168.0.2] (really [86.14.216.162]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20060721073954.FNCO15733.aamtaout04-winn.ispmail.ntl.com@[192.168.0.2]> for ; Fri, 21 Jul 2006 08:39:54 +0100 Message-ID: <44C08672.6070700@gentoo.org> Date: Fri, 21 Jul 2006 08:46:58 +0100 From: Daniel Drake User-Agent: Thunderbird 1.5.0.4 (X11/20060603) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-kernel@gentoo.org Reply-to: gentoo-kernel@lists.gentoo.org MIME-Version: 1.0 To: gentoo-kernel@lists.gentoo.org Subject: Re: [gentoo-kernel] push kernel bugs upstream sooner and bootsplash/vesa-ng stuff References: <44BFC945.9090803@gentoo.org> <20060721023732.GB6571@kroah.com> <20060721032818.GA7285@kroah.com> In-Reply-To: <20060721032818.GA7285@kroah.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: ab3c3703-74c4-4879-8eba-c03d90616659 X-Archives-Hash: 6ff6bff0cad92408f8793cb6ad9718b7 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 statistics: 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* Daniel -- gentoo-kernel@gentoo.org mailing list