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

Felipe Sateler fsateler at gmail.com
Thu May 28 07:14:17 UTC 2009


El jueves 28 de mayo, Reinhard Tartler escribió:
> 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".

I'm not sure about this... I don't think the wiki should document every single 
git usage we have. We should be able to expect people to get to know a bit of 
the tools we use after some time working with us. Ie, we should document only 
what is necessary: stuff for beginners to understand the workflow, and team-
specific tools and guidelines.

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

I don't understand this. You seem to be arguing the same point as I did 
(always recommend rebase).

BTW, I think it is good practice for direct commiters too, since merges only 
due to simultaneous work are only harder to read (as opposed to merges because 
of large changes). For some packages I enable rebasing by default (git config 
branch.<name>.rebase true), I wanted to add something of the sort, but my 
attempts at that failed miserably in the simplicity department.

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

I've changed this.

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

Done.

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

Done.

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

Of course. You can also choose to not publish the tags until you sign them 
(delete + create a new signed one). 

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

Done.


Saludos,
Felipe Sateler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20090528/cbaeeb23/attachment.pgp>


More information about the pkg-multimedia-maintainers mailing list