[Please don't cc me, thanks.] On Mon, Mar 24, 2003 at 11:46:18AM -0600, Adam Heath wrote: > On Sun, 23 Mar 2003, Adam Heath wrote: > > But, when [EMAIL PROTECTED] 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. > > 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, :-) > Note, that I have changed the order of the fields, to make parsing the files > by humans a tad easier, but the code itself won't care, when reading in the > files. Yeah, that's cool, it will make extensions *much* easier. > Since both file sizes are under a cluster/sector/block in length, there won't > be any additional space requirements, after the conversion is finalized. > However, during the transition, the number of additional inodes will increase > by 159000(or so), which is well under master's limits. 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. > Question: Should I store the bug# in the .db file? Yes, please. -- Colin Watson [EMAIL PROTECTED]
