Re: Closing bugs in removed packages, plus .status format change
On Tue, 25 Mar 2003, Colin Watson wrote:
> [Please don't cc me, thanks.]
What about bcc? Or forward?
> On Mon, Mar 24, 2003 at 11:46:18AM -0600, Adam Heath wrote:
> > On Sun, 23 Mar 2003, Adam Heath wrote:
> > > But, when control@bugs unarchives a bug, it will *not* reopen it. That should
> > > be a separate step. This would need to be documented well, as I would see
> > > some people thinking that the bug would be automatically reopened.
>
> OK. I'd considered both behaviours, but it does seem simplest to have
> 'unarchive' be a primitive operation.
Yeah, most bts commands should be simpletons.
>
> > > Btw, I'm working on changing the .status format. There will be a new file,
> > > .db, that will be formated like a dpkg control file. My plan is to work on
> > > some converter code offline, modify the existing .status reader, modify the
> > > existing debbugs code to .....
> > >
> > > NOT USE GLOBALS FOR BUG DATA,
Actually, there are 2 very separate phases to this project. Removal of $s_*
globals, and using a single function to read/write the data; then changing
that function to use a new file format.
> Or you could add the new code but include a temporary fallback to the
> old code, convert one file at a time deleting the old one, then delete
> the temporary fallback. *shrug* As you say, master can handle the
> transition.
It's simpler to convert them all at once, and then just write out both files
as needed. If done as you suggest, we have to maintain code that can read
both files.
> > Question: Should I store the bug# in the .db file?
I'm since been convinced(didn't take much) to do this. The benefits far
outweigh the single downside(cloning).
Reply to: