From: Larry McVoy <lm@bitmover.com>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: Hanna Linder <hannal@us.ibm.com>,
Eli Carter <eli.carter@inet.com>,
"Randy.Dunlap" <rddunlap@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Raw data from dedicated kernel bug database
Date: Wed, 1 Jan 2003 11:40:19 -0800 [thread overview]
Message-ID: <20030101194019.GZ5607@work.bitmover.com> (raw)
What are the chances that the raw data from the kernel bugdb could be
made available? I bet Bradford wants it and I know I want. We are
working on an integrated bugdb for BitKeeper and it would be cool if
we could track the real db at osdl.
The advantage of having the data available is that for the BK kernel
users we could give them access to the bugdb while they are doing
checkins so that the developers link the changes to the bugs as they
do the fixes, which is a good time to do it.
To calm any fears that we are trying to take over the bugdb, we're not.
We just want to track it. Any changes made in a BK bugdb are trivially
exportable to an external format and if the need arises we'll work with
IBM/OSDL to make that happen. In fact, we can automate it.
Getting back to the data, the ideal raw data format for us would be
for bug in `cat list-o-bugs`
do for field in `cat list-o-fields`
do extract $field from $bug into $bug.$field
set-timestamp \
of $bug.$field \
to date that $bugd.$field was created/updated
done
done
I'm not sure if the fields are all self-contained. For example, the updates
are done by someone, is that someone part of the data or is it "metadata".
What about state transitions (open -> closed)?
The other alternative is to make the whole infrastructure available as
tarball, the mysql db et al, so that someone could slurp that down and
poke at it locally.
Any chance of this? I'd much appreciate it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
next reply other threads:[~2003-01-01 19:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-01 19:40 Larry McVoy [this message]
2003-01-01 20:06 ` Raw data from dedicated kernel bug database John Bradford
2003-01-01 21:30 ` Martin J. Bligh
2003-01-01 22:15 ` Larry McVoy
2003-01-02 0:32 ` Martin J. Bligh
2003-01-02 2:03 ` Alan Cox
2003-01-02 0:38 ` Timothy D. Witham
2003-01-02 2:16 ` Larry McVoy
2003-01-02 2:39 ` Martin J. Bligh
2003-01-02 2:56 ` Larry McVoy
2003-01-02 5:12 ` Martin J. Bligh
2003-01-02 16:15 ` Timothy D. Witham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030101194019.GZ5607@work.bitmover.com \
--to=lm@bitmover.com \
--cc=eli.carter@inet.com \
--cc=hannal@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=rddunlap@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox