Anonymous dijo [Sat, Sep 29, 2018 at 05:06:58PM +0200]: > Dear Chair Dear Anonymous, Although it is of course completely fine for you to contact us anonymously, in cases such as this one, having a "name" will help your case. Do you actually use this? Have you worked with the issue? Is it bothering you? Anonymous opinions are acceptable. But Debian is a socially cohesive group of people. It helps us to match opinions with people. Would help your point. Anyway, thanks for your mail. > (...) > Patch series are supported by git-am and git-format-patch. There is no > better approach to incorporate patches. I fear circumventing the policy > with "QUILT_SERIES=debian/patches/$(dpkg-vendor --query vendor).patch > quilt push -a" in debian/rules. The patch series separates vendor > specific code properly. If policy is against vendor specific code it has > to accept patch series at least. They are a last resort to make > independent patches. Well, IMO this would be precisely the _right_ way to do this: The source you have on disk at source package unpacking time is the same everywhere, and you can see precisely what would happen when building in Mint, Ubuntu, Debian or $whatever. This would not be circumventing policy — It would be following it with minimal friction to what you already have. > Builds for different vendors are not a standard use case at all. Identic > source after unpacking is possible with dpkg-source --skip-patches > anyways. A hint about different series during unpacking can be useful > but changing policy because someone was confused is unbelievable. Usage > of the right tools is good practice and should not forced with power. > > The decision is based on wrong assumptions and implications, arguments > are weak, valid objections ignored. This is abusing Debian policy and > technical committee against free software! Debian needs patches > regardless of policy. I do not share that feeling; I think we argued constructively with people that were against this outcome, and while there is not universal consensus, expressed issues were taken into account.
Attachment:
signature.asc
Description: PGP signature