Re: debconf 5
On Tue, 01 Feb 2005 16:15:02 -0700, dann frazier wrote:
> On Tue, 2005-02-01 at 17:38 -0500, Kyle McMartin wrote:
>> On Tue, Feb 01, 2005 at 03:02:31PM -0700, dann frazier wrote:
>> > Any debian-kernel folks gonna be at Debconf this year? Anyone planning
>> > to talk? I was thinking about proposing one - maybe a general overview
>> > talk?
>> >
>>
>> I'm planning on attending.
>
> I plan to attend, but I'm not sure I will - hopefully we can put
> together a talk as a group, and whomever is there can give it.
>
>> Didn't previously think about giving a talk, but I am now...
>
> Cool. To brainstorm on some topics, I was thinking about quickly
> starting with some basics. This is kinda user-level, but I didn't
> understand it myself until I started maintaining a kernel.
>
> * kernel-tree - what it is, and how to use it
> * ABI numbers - so that's what that funky number means
> * -latest packages - what they are (track testing, not sid, etc)
>
> Then talking about some future directions:
> * One super-unified-source package (I've heard rumors about this
> on irc - not sure how much work has been done here)
> * Keeping configs in sync
Ubuntu is pushing hard for this as well; the config tool bit of
http://www.ubuntulinux.org/community/teams/kernel relates to that.
> * Nightly build testing (I started some work in this area over
> break, hopefully will have something to share soon; making sure
> the current packages in svn build, providing binaries that can
> be later tested for things like unintentional abi changes, etc)
>
That would be most excellent; nothing worse than getting ready to do a
release, and discovering a patch or 5 don't apply/compile..
> And fight really hard to avoid having this talk turn into a non-free
> firmware talk; I'd like to blacklist that topic from this BOF (assuming
> we only have an hour) maybe by making a BOF out of it (with metal
> detectors at the door).
I hope to get firmware stuff worked out a bit better this week. It's
seriously hurting us, and is at the very top of my TODO list.
As far as suggestions:
* How to properly report bugs against the kernel. Including boot
logs, hardware information, oopses, etc. Maybe even go so far as
describing the bk web interface, and go through the steps of
tracking down a patch that fixes the bug being reported. Bugs w/
patches supplied are much more likely to get fixed. :)
Norbert's suggestion for how kernel modules are dealt w/ would also be a
good idea. kernel-package, module-assistant, how kernel module packages
are structured, etc.
Reply to: