Guillem Jover <guil...@debian.org> writes: > Sorry, probably my fault! As I tend to use «Fixes:» git pseudo-fields > for things that fix part of a bug, but are not intended yet to close it, > for which I use «Closes:».
Ack, sorry, this was my fault. I optimistically added a bug closer when I started merging patches from this bug in the hope that we'd get them all merged before the next release and then forgot about it. (That said, and this is only personal preference and I don't feel that strongly about it, I usually err on the side of creating lots of bugs so that there can be roughly one bug per patch. It can make it a bit harder to track things if there's one bug following a bunch of semi-related but separable changes. Unfortunately, the BTS doesn't support the concept of a hierarchy with a tracking issue and a bunch of underlying implementaton issue very well.) > And for some reason I think I also got the impression, even though > the stanza changes had been committed, they could still be backed out. > (BTW I've now gone over the wiki and updated all paragraph references > that applied to stanza.) I'm personally happy to stick with stanza. > I also recalled another term that has always seemed very confusing in > context: «control information files» or «control information area». For > example in a sentence such as “the control file is a control information > file in the control information area in a .deb archive”. :) This also > seems confusing when some of the files in the .deb control member are > not really “control files” with a deb822(5) format. > My thinking has been going into calling these as the «metadata files», > and being located in either the «metadata part of the .deb archive» or > explicitly the «control member of the .deb archive», in contrast to the > filesystem part. In dpkg I'd be eventually switching to meta/metadata > and fsys/filesystem, from control or info and data. I've added a patch > with the proposed change, but again nothing set in stone, and I'm again > open to discussing pros/cons of this. I like metadata file, but I think I prefer talking about the "control member" than the "metadata part" because it more closely matches what one sees if one takes the *.deb file apart. But I haven't looked at your diffs yet. > Attached the proposals for discussion/review, and I might again have > perhaps missed instances or similar. Will take a look soon! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>