On Fri, Apr 02, 2010 at 20:59:02 (CEST), Jonas Smedegaard wrote:
>>Jonas, perhaps you answer these questions:
>> - do you commit the quilt control directory .pc/?
>> - do you commit the tree with patches applied?
>> - if not, is everyone expected to run 'quilt pop -a' before committing
>> changes to the tree?
> So there is your answer to the questions: No - I commit unapplied
> patches, not applied ones or quilt noise!
Hm, but requires additional manual overhead to make sure that you don't
commit noise. Does this really make packaging easier then?
> I use git-buildpackage, not topgit!
I don't understand this comment. Topgit managing each "change" as a
>> Sorry, I still think this mode of operation is pretty silly. I'd much
>> prefer if the patches were maintained by git-buildpackage as proper
>> git commits instead of text files. Upon source package generation,
>> these commits need to be exported as quilt patches of course. This
>> way, updating to a new upstream version would use git's conflict
>> resolution mechanisms instead of quilt (which can only merge 2-way,
>> git can do a 3-way merge).
>> I guess other VCS systems like hg or bzr at least try something in
>> that directions (although I have to admit that I didn't follow the
>> latest developments there).
> You are free to find git-buildpackage silly, and prefer different VCSes
This is not what I said, and granted, I shouldn't have used the word
'silly' but a less strong word. I think that Format 3.0 does not work
well with git-buildpackage. At least, git-buildpackage should integrate
more with dpkg so that unnecessary "commit noise" is avoided.
> Am I free to not find it silly? As part of this team?
I'd very much prefer to work on a consistent set of packages. Having
some packages maintained in this and some in another way leads
individuals to look and care only after a subset of our team's packages.
Reinhard Tartler, KeyID 945348A4
pkg-multimedia-maintainers mailing list