ext Alexander Kanevskiy <[email protected]> writes: > On Thu, Sep 23, 2010 at 18:16, Roger WANG <[email protected]> wrote: >> "Nashif, Anas" <[email protected]> writes: >> >>> Hi, >>> We have noticed recently that bug fixes are being submitted but >>> without a bug number in the change log (.changes file) but with >>> detailed bug information in the commit message, which is used for >>> communication, but is never part of the resulting package. >> >>> Please add the bmc numbers or features you are working on in the >>> .changes file also, this is critical and otherwise changes will be >>> declined. >> >> What should I do if I find a bug is fixed by the new version later, >> after the package is accepted? > > if bug is not anymore reproducible with newly accepted version and > this version doesn't link to that bug, then close bug with > "WORKSFORME" resolution.
There is, however, a difference between a bug that can not be reproduced and we might thus have a bug that we haven't fixed, and a bug that is known and fixed already, and we can forget about it. We might want to distinguish these in Bugzilla. I agree that recording all fixed bugs in .changes is good, but if we enforce it strictly, we need a way to announce fixes in past versions as well, and accept that people might not want to make a new release just to add something to .changes. I see two ways: We can allow people to edit already released .changes entries (and make sure the tools will not be fooled by that), or we can simply make a convention for listing historical fixes in new .changes entries, maybe like so: * Frob the doodles. Fixes: BMC#xxxx. * Already fixed in version 0.1: - Fixes: BMC#Bxxxx, BMC#xxxx. This should be good enough, I'd say. _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
