new Pd packages looking for sponsors

[Felipe Sateler]

On Wed, Nov 10, 2010 at 10:06, Jonas Smedegaard <dr at 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.



-- 

Saludos,
Felipe Sateler