In a conversation with Guillaume Boissiere it was mentioned that setting
up a bug/problem report database for later in the 2.5 development cycle.
Cox won't let me run an Apache web server from home with a bugzilla-type
database (my preference), but I have been playing around with a simplistic
web page problem report tracking available at
http://members.cox.net/tmolina
Would something like this be sufficient, or would a full-fledged server be
required? Feedback/comments are welcome
On Mon, 22 Jul 2002, Thomas Molina wrote:
> http://members.cox.net/tmolina
>
> Would something like this be sufficient, or would a full-fledged server
> be required? Feedback/comments are welcome
A simple page _that is being maintained_ is much better than a
database which accumulates hundreds of stale entries over time ;)
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Mon, 22 Jul 2002, Rik van Riel wrote:
> On Mon, 22 Jul 2002, Thomas Molina wrote:
>
> > http://members.cox.net/tmolina
> >
> > Would something like this be sufficient, or would a full-fledged server
> > be required? Feedback/comments are welcome
>
> A simple page _that is being maintained_ is much better than a
> database which accumulates hundreds of stale entries over time ;)
davej runs such a simple page since several months at
http://www.codemonkey.org.uk/Linux-2.5.html
> Rik
cu
Adrian
--
You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
Alan Cox
On Monday, 22 July 2002, at 15:59:01 -0500,
Thomas Molina wrote:
> Would something like this be sufficient, or would a full-fledged server be
> required? Feedback/comments are welcome
>
Don't know, but in the process of compiling a 2.5.27 kernel with ALL
options enabled I have found not less than 60 compilation bugs. Expect
run-time problems to be much more than compile-time problems. Moreover,
problems can happen on several kernel versions (untill they are solved),
so the page can quickly get out of control.
I would suggest categorizing reported bugs to get a smaller front-page,
maybe with a back-end database to store and keep track of bugs.
Just an opinion :)
--
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1)
The discussion actually started because Dave said he did not have much time
these days to maintain the page and Thomas offered to help.
For the time being, continuing to maintain Dave's page may be the best
solution, I don't know. People should tell Thomas what they think would
be the best use of his time *now* to help the community.
Personally, I think there is a huge value in setting up a bug database, but
only after the feature freeze. This way, all the developers can go to one
place with all the problems listed and focus on fixing bugs for a while.
Once the 2.6 release appears, the bug database can be discontinued if
there is no longer much interest.
As Rik pointed out, the key thing here is _maintained_ and the only time
where we can be certain a bug database is going to be well maintained is
between feature freeze and release, because that's when everyone will be
working on fixing as many bugs as possible to make a rock solid release.
Cheers,
-- Guillaume
On 22 Jul 2002 at 23:39, Adrian Bunk wrote:
> On Mon, 22 Jul 2002, Rik van Riel wrote:
>
> > On Mon, 22 Jul 2002, Thomas Molina wrote:
> >
> > > http://members.cox.net/tmolina
> > >
> > > Would something like this be sufficient, or would a full-fledged server
> > > be required? Feedback/comments are welcome
> >
> > A simple page _that is being maintained_ is much better than a
> > database which accumulates hundreds of stale entries over time ;)
>
> davej runs such a simple page since several months at
> http://www.codemonkey.org.uk/Linux-2.5.html
>
> > Rik
>
> cu
> Adrian
>
> --
>
> You only think this is a free country. Like the US the UK spends a lot of
> time explaining its a free country because its a police state.
> Alan Cox
>
>
On Mon, Jul 22, 2002 at 03:59:01PM -0500, Thomas Molina wrote:
>
> In a conversation with Guillaume Boissiere it was mentioned that setting
> up a bug/problem report database for later in the 2.5 development cycle.
> Cox won't let me run an Apache web server from home with a bugzilla-type
> database (my preference), but I have been playing around with a simplistic
> web page problem report tracking available at
> http://members.cox.net/tmolina
>
> Would something like this be sufficient, or would a full-fledged server be
> required? Feedback/comments are welcome
Quite nice. It's a more organised version of what I had, but as the
number of reports gets higher and higher, it could end up being as much a
maintainence nightmare as the log I was updating.
Talking with a few folks about this problem at the summit, a few times
jitterbug was mentioned. My faded memory doesn't recall too much about
those days, but ultimatly it didn't work out.
I'm wondering how such a system would work out today.
There's even possibilites for neat things like checking
bitkeeper to automatically update status when Linus applies
a patch, which before required interaction from Linus.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Mon, Jul 22, 2002 at 11:31:19PM +0200, Dave Jones wrote:
> > http://members.cox.net/tmolina
> >
> > Would something like this be sufficient, or would a full-fledged server be
> > required? Feedback/comments are welcome
>
> Quite nice. It's a more organised version of what I had, but as the
> number of reports gets higher and higher, it could end up being as much a
> maintainence nightmare as the log I was updating.
>
> Talking with a few folks about this problem at the summit, a few times
> jitterbug was mentioned. My faded memory doesn't recall too much about
> those days, but ultimatly it didn't work out.
>
> I'm wondering how such a system would work out today.
> There's even possibilites for neat things like checking
> bitkeeper to automatically update status when Linus applies
> a patch, which before required interaction from Linus.
We have a bug database pretty close to being ready be shipped. It's a
somewhat "unique" approach, we figured out how to coax a BK repository
into looking like a database and added a layer so you can spit pseudo
SQL queries at the repository and get bug reports. You can play with
it at http://bitkeeper.bkbits.net/bugs.html which is actually our
live bug database so don't close bugs unless you fixed them :)
Part of the point of doing it as a BK repository was that you could
take your bugdb with you and link bugs to changesets as you create
the changesets. If people do that, the release notes which list the
set of bugs closed by that release can be generated with a one line
command, which is a big part of what people want.
For those people who'd rather roll their own than use ours, the linkage
is done through the use of "changeset keys" which are the underlying name
for revisions. You can dig those out with a
"bk prs -r<rev> -nd:KEY: ChangeSet"
and there is a key2rev command which will convert them back if you like.
We can easily import any format so long as we can get at the data so if
a bugdb emerges which has the data and people no longer want to maintain
it, we'll do the import.
Regardless of what database is used, we can provide a machine, net
connection, etc. I think the person who did that page mentioned that
their ISP wouldn't let them host it. If you want a kbugs.bkbits.net or
some other name, let me know, I'll get someone to set it up. It won't
be the biggest machine in the world, probably a 400Mhz bookpc, but the
bugdb would be the only thing on it so it might be enough. If it's not,
we'll revisit the issue.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm