DevelopPackaging, Was: Bug#529160: zita-convolver: FTBFS: dpkg-genchanges: failure: cannot read files list file: No such file or directory

[Reinhard Tartler]

Felipe Sateler <fsateler at gmail.com> writes:

> El jueves 28 de mayo, Reinhard Tartler escribió:
>> Reinhard Tartler <siretart at tauware.de> writes:
>> > For beginners, I'd suggest the following workflow (I hope that is
>> > wiki-like syntax so that it can easily be copied, please someone review
>> > and copy it to the wiki):
>>
>> I've updated http://wiki.debian.org/DebianMultimedia/DevelopPackaging
>> now. Comments, Reviews and corrections welcome.
>>
>> I'm particularily unhappy with the section 'tasks for team
>> members'. Registering remote archives should probably be seperated into
>> its own task. Moreover, notes how to import patches with preserving
>> attribution and pushing them to git.debian.org are missing.
>
> What do you mean by registering remote archives? git remote add? If so, why 
> would you want it split into a new section?

Yes, I mean git remote add. In tla, there was an explicit command `tla
register-archive` for that.

Registering the remote archive is a perquisite for all steps that touch
the remote archive. It only needs to be done exactly once. Splitting
it out would be in the "tradition of code reuse".

> Some comments:
> I would recommend all packagers not committing directly to use rebase, I think 
> you can't preserve merge information in a patch series, the commiter may need 
> to do conflict resolution.

I am aware about the merge vs. rebase discussion. For this particular
use case, I think rebase is better. Here, you are encouraged to do
small, focused commits anyway, and I don't expect they will do heavy
development here. If they do, the will be aware about this discussion
anyway use merging instead anyway. On the other hand, the cleaner diff
history makes using git-format-patch(1) easier and let's it produce more
useful output, I think.

> (As an extra, thing, you can use git pull --rebase 
> instead of the 2-step fetch and rebase).

Ah, right. Excellent.

> Git-import-dsc preserves attributions, so there is no need to set up the 
> GIT_AUTHOR_* variables. Upstream source will be marked as imported by the 
> committer, but that is not a problem (the important part is the debian patch).

Ah, I wasn't aware of that. Every change to make the instructions
easier is an improvement, IMO

> I've modified setup-repository to ensure that we are in the team's area. So the 
> create repository step can be:
>     ssh git.debian.org /git/pkg-multimedia/setup-repository <project>

Excellent!

> I would also recommend using --sign-tags in git-import-orig (and the final git-
> buildpackage run).

Hm, I do use a gpg smartcard, which I don't have around with me all the
time. Requiring this will definitely make working on packages for me
harder. For this reason, I'd love to see that optional.


> What do you think about these changes? Do I put this in the wiki?

ACK

> BTW, at this point I think we can remove the note at the beginning of the 
> page.

ACK


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4