On 9/23/10 11:26 PM, "Marius Vollmer" <[email protected]> wrote:

> 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.

I agree, and I'd rather have something like "Already fixed in version xyz",

rather than actually editing an already entered .changes item...that
wouldn't be correct and would confuse things...

Good suggestion...

rs



> _______________________________________________
> MeeGo-packaging mailing list
> [email protected]
> http://lists.meego.com/listinfo/meego-packaging
> 

_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging

Reply via email to