Re: Paths into Debian
On 23/09/13 19:31, Jakub Wilk wrote:
> * Lucas Nussbaum <email@example.com>, 2013-09-23, 14:46:
>> Alternatively, maybe we should review the current process for one-shot
>> patches. Assuming that someone wants to fix a typo in a package and
>> submit it as a patch, the current simpler process is (TTBOMK):
>> 1. 'debcheckout packagename' (but this fails when the package is not
>> maintained in a VCS. maybe it should fallback to using 'apt-get source'?)
>> 2. Build a source package, so that we can run nmudiff later:
>> 'dpkg-buildpackage -us -uc -S' or 'git-buildpackage -us -uc -S'
>> (depending on the Vcs used.)
> If you don't fancy running untrusted code, point 2 is more like this:
> - Build the VCS checkout of the package using "dpkg-buildpackage -S -nc".
> - Grab last version of the same package from the archive.
> - Run debdiff between the two *.dsc.
> - Start reading the diff.
> - Realize that the diff is flippin' huge.
> - Nuke the VCS checkout; use the version from the archive instead.
There are some other ways about it:
- allow untested patch submission - for things like doc fixes, it would
be nice if the maintainer could easily cherry pick such patches from the
bug tracker next time he does a build, no need to expect every
contributor to make a build for such things
- use of CI (e.g. Jenkins) to try and build each contribution. People
could then contribute patches (possibly cherry picked from upstream) and
the maintainer could see whether the package builds successfully in
Jenkins and if so, the maintainer just makes one click to accept it.
This would be good for packages that are suitable for CI of course.