On Wed, Nov 10, 2010 at 10:06, Jonas Smedegaard <d...@jones.dk> wrote:
> On Wed, Nov 10, 2010 at 11:55:55AM +0100, Reinhard Tartler wrote:
>> On Wed, Nov 10, 2010 at 09:21:17 (CET), IOhannes m zmoelnig wrote:
>>> On 2010-11-09 22:51, Felipe Sateler wrote:
>>>>> pd-pan
>>>> Please update the changelog when updating the package. The timestamp
>>>> helps people tell when was the last time someone worked on a package. Also
>>>> the long description is too short
>>> hmm, this confuses me a bit.
>>> i thought that the changelog should not be touched until the upload, and
>>> only the person uploading would then run git-dch to regenerate the changelog
>>> from the commit-messages (and eventually cleanup).
>> You can greatly help the person reviewing the upload by running git-dch at
>> the point where you think the package is ready for upload, i.e., you think
>> the package is in a state that you would have uploaded yourself if you had
>> upload priviledges.
>> Of course the actual upload might want to do some additional changes or
>> spots mistakes. In that case he has to update the changelog in a seperate
>> commit, but that's not really a problem.
> I suspect (but must admit that I haven't closely read our wiki pages lately)
> that we have no clear rules about this.
> I propose the following:
>  * As a minimum, the changelog is completely untouched until final
> release, where the uploader auto-generates using "git-dch -R",     adjusts
> by hand as needed, and commits the changes.
>  * Optionally intermediate updates to the changelog can be applied.
>    Begin with "git-dch" and if that fails then instead use
>    "git-dch --since <REF>" (replacing <REF> with reference to last
> commit that touched debian/changelog), set distribution to
>    UNRELEASED, and commit the changes.
>  * Intermediate changelog updates are encouraged when release is
> expected only later, and when more people work on same package.

But if the primary worker on a package thinks the package is ready for
release, the trailer line should be updated, I believe.

> In other words, I propose to replace the earlier commit style (documented in
> the wiki?) of unconditionally adding UNRELEASED - which does not work
> optimally together with git-dch IMO.

If you use the changelog heuristic (see man dch), dch will leave the
to as UNRELEASED and the trailer line not updated. At release time,
one can issue a dch -r that will update both. This workflow is good,
because it lets us know when someone believes the package is ready at
the time one looks at the package.


Felipe Sateler

pkg-multimedia-maintainers mailing list

Reply via email to