Bug#904302: That's a free software issue!
Anonymous writes ("Bug#904302: That's a free software issue!"):
> If Debian want patches it has to support this process with tools. The
> attitude Debian owns all source packages is wrong. Sharing source
> packages among different vendors is more efficient. Different patch
> series may be the best solution in some cases.
I do agree with the underlying ideology behind these ideas. I think
code sharing between different distros in the Debianish ecosystem is
very important and I certainly don't think that `Debian owns all
source packages', whatever that means.
Indeed, in my technical Debian work I am writing tools which I hope
will support people who want to diverge from Debian, and retain and
carry those divergences in the long term. I have long been frustrated
that it is too difficult to do this.
The problem I have with the vendor series feature is narrower and more
technical. For all the reasons I and others have explained, I think
the vendor series feature is a very poor way to support divergence and
diversity. It does more harm than good.
The background to this is that I think that Debian source packages,
which I designed in the mid 1990s and which were since extended with
`3.0 (quilt)' [1], are a clumsy system which has been obsoleted by the
new generation of distributed version control systems, especially git.
.dsc format source packages are bad enough for the newcomer to Debian,
without the very weird vendor patch series feature. And the vendor
patch series feature makes migration to better source code management
tools harder.
So in summary I think the real way to promote divergence by Debian's
derivatives, and code sharing amongst derivatives, is to use to the
full the features of very capable modern revision control systems.
TBH I don't expect this to convince you. And I found many of your
comments rather overblown. It would be helpful if you could avoid
wild accusations.
But, if you really want to help promote software freedom for Debian's
derivatives and users, by addressing issues to do with package source
code management tooling: please consider trying out dgit and maybe
suggesting it to Debian's downstreams as a way to get the source code
from Debian.
Please also consider advocating that Debian maintainers should use
dgit for their uploads. If you're very keen you could come and help
out with work on making git-debrebase become a useful tool for
downstreams.
Ian.
[1] To be clear, although I have a lot of criticisms of `3.0 (quilt)',
it is much better than what was being widely done in Debian
beforehand.
Bug#904302: That's a free software issue!
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. signature.asc Description: PGP signature
Bug#904302: That's a free software issue!
Dear Chair reasoning of this policy is really absurd. The opposite is actually true. Usage of vendor patches should be encouraged downstream. That's a free software issue! The goal is to facilitate patches. If Debian want patches it has to support this process with tools. The attitude Debian owns all source packages is wrong. Sharing source packages among different vendors is more efficient. Different patch series may be the best solution in some cases. This policy decision only breaks the workflow. Derivatives have to duplicate the whole source tree. It is a huge burden and waste of resources. 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. 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. Yours truly
