all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Andreas Enge <andreas@enge.fr>
To: guix-devel@gnu.org
Subject: Re: patches question
Date: Thu, 23 Jun 2016 13:09:43 +0200	[thread overview]
Message-ID: <20160623110943.GA748@solar> (raw)
In-Reply-To: <20160623104107.GA2505@shadowwalker>

Hello,

On Thu, Jun 23, 2016 at 10:41:08AM +0000, ng0 wrote:
> After the last reply to my netcat-openbsd, I am
> uncertain about the kind of patches which can
> be included by policy.

my opinion is: as few patches as possible, given that we need to maintain
them with very little peoplepower, and that we do not intend to substitute
ourselves to upstream. Also, if possible, things should be reported upstream
so that we can take patches out again. Another reason to do so is that
packages should essentially behave in the same way as the same software
compiled by hand. Recall also cases of security problems introduced into
other distributions by non-upstream adding patches to cryto software they
did not completely understand.

> For firefox, I would start to include what fixes
> buildprocess for us and fixes bugs (including
> features) upstream has not bothered to close yet
> or in general.

Particularities of our build process may clearly make patches necessary
(although I often prefer to treat them more generically in a build phase,
using "substitute*", for instance, which may be more robust across package
updates). After that, I would consider mainly security fixes and maybe
important functional fixes made by upstream that are not yet in a release.
Clearly features that upstream does not bother to implement are not acceptable
for patches, as they will have to be maintained and adapted indefinitely.

> For firefox, bundled libraries and applications
> can be patched away (system graphite+harfbuzz),

Unbundling and removal of non-free parts are also possible cases, although
most of the time this is done by a call to "delete-file-recursively" in a
snippet.

> That is what the netcat-openbsd-* files of debian
> are about I assume (but I have not asked debian
> yet).

I do not know about this particular software, but while Debian is a good
source for copyright info and patch material, they definitely are not our
lead as to the decision of whether to include patches: If you divide our
number of packages by the number of regular contributors, you will end up
with a few hundred packages per person. I think Debian has no particular
policy as to which patches are acceptable, and that this is mainly up to
the package maintainer. In our case, since we do not have designated
maintainers, every additional patch is an additional burden on the person
trying to update or more generally work on a package later. As a bad example
of a Debian patch, I have encountered one that corrected an English typo
in a comment (!) in the C code of a package.

Andreas

  reply	other threads:[~2016-06-23 11:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-23 10:41 patches question ng0
2016-06-23 11:09 ` Andreas Enge [this message]
2016-06-23 11:30   ` ng0
2016-06-23 20:14     ` Andreas Enge
2016-06-23 22:18       ` ng0
2016-06-23 13:23 ` ng0
2016-06-23 20:27   ` Andreas Enge
2016-06-24 12:09   ` Ludovic Courtès
2016-06-24 13:43     ` ng0
2016-06-24 15:48       ` Tor Browser Ludovic Courtès
2016-06-24 17:49         ` ng0
2016-06-26 10:05           ` Ludovic Courtès
2016-06-29 12:48             ` ng0
2016-06-30 10:29               ` Ludovic Courtès
2016-06-30 16:09                 ` ng0
2016-06-30 18:00                 ` ng0
2016-08-05 13:35                 ` ng0
2016-08-06  4:05                   ` Alex Vong
2016-08-06 11:14                     ` ng0
2016-08-08  8:03                       ` Alex Vong
2016-08-10 20:01                         ` Mark H Weaver
2016-08-11  8:51                           ` ng0

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160623110943.GA748@solar \
    --to=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.