Can you perhaps improve bugzilla instead of starting over? (I have not
looked at bugzilla code... I'm just hoping we can build from where we
are instead of starting over.)
> I.E. I am prepared to write it myself, if people think it's
> worthwhile.
>
> For example, we get a lot of posts on LKML like this:
>
> "Hi, foobar doesn't work in 2.4.19"
>
> Now, does that mean:
>
> * The bug first appeared in 2.4.19, and is still in 2.4.20
> * The bug reporter hasn't tested 2.4.20
> * The bug reporter can't test 2.4.20 because something else is broken
> * The bug actually first appeared in 2.4.10, but it didn't irritate
> them enough to complain until now.
This case is not specific to the kernel:
"feature X doesn't work in program Y version Z"
it may appear in Z-3 through Z+1, but fixed in Z+2, etc.
So I hope it is something that could be done in/added to bugzilla.
> A bug database designed from scratch could allow such information to
> be indexed in a way that could be processed and searched usefully. A
> list of tick-boxes for worked/didn't work/didn't test/couldn't test
> for several kernel versions could be presented.
>
> Also, we could have a non-web interface, (telnet or gopher to the bug
> DB, or control it by E-Mail).
Can you interface with bugzilla's database backend maybe? It seems like
refactoring bugzilla might be better?
> It could warn the user if they attach an un-decoded oops that their
> bug report isn't as useful as it could be, and if they mention a
> distribution kernel version, that it's not a tree that the developers
> will necessarily be familiar with.
Perhaps a more generalized hook into bugzilla for 'validating' a bug
report, then code specific validators for kernel work?
> I'm not criticising the fact that we've got Bugzilla up and running,
> but just pointing out that we could do better, (and I'm prepared to
> put in the time and effort). I just need ideas, really.
I certainly do not want to stand in your way! I just hope you can stand
on the shoulders of giants.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/