From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4dyQSH4mQXz3322 for ; Fri, 23 Jan 2026 17:50:07 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4dyQSD0tJWz2xLt for ; Fri, 23 Jan 2026 17:50:04 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4dyQSC36qGzvw; Fri, 23 Jan 2026 17:50:03 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1769190603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YjQYn2bMMvlR7eP36XNCNM50XqcKK8Ia96ql7trHhAo=; b=xEYxSC9rtt8Yk9/Pdd8zY+BGnNtdjO2o8jV0vXIYWHFE4HxJtwZpjM2znoUgrLhrYDT/MK iXIF6xCDOeqgi+Ag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1769190603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YjQYn2bMMvlR7eP36XNCNM50XqcKK8Ia96ql7trHhAo=; b=KDVZ4oFAPMjdV1l3E3k8bnNpqkgLu00xm3K62ZCVsYQb1tDbXDlbYsMPpv4wGL7GF4Oomg vmdI+pEo7q212zXSqTDDXDZ7IusrtoTtXE4Z7yjJLt4gUG48sqfxQuQK6REKuYswFdE2w7 oIoYJICJLmTKEN2ARpg4rH5qfUy2K9Sf8XoV0dsEEnLXuAVzq9POmaFfkXyD0uL2eROIjY k4hJ0yy6lvy1Z0McK0bWmIznKaVZ11mtxiMEa3ASJ5AzK762s4kTDD5fVDLrVFf4jzzrY7 nFnyGtXGG4ocLJcYdP9mlzdHtkwvXrS3qOPSpi8SBhUZIuPCFhQQG51cvh8pkg== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: An AI Usage Policy for IPFire From: Michael Tremer In-Reply-To: <737628a6-73c1-4c21-bb17-068bb250bd81@ipfire.org> Date: Fri, 23 Jan 2026 17:50:02 +0000 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <142BE0A0-8402-4051-AFE0-2950B718C9D2@ipfire.org> References: <825C0B91-4C7B-4352-9469-4148E6337AA0@ipfire.org> <737628a6-73c1-4c21-bb17-068bb250bd81@ipfire.org> To: Adolf Belka Hello Adolf, Thanks for reviewing this. > On 23 Jan 2026, at 17:30, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 23/01/2026 15:48, Michael Tremer wrote: >> Hello everyone, >> While eating my lunch today I stumbled over the AI Usage Policy that = the Ghostty project has come up with. I quite liked it and I think that = IPFire should also have a policy for AI usage in place. We have not = received such an overwhelming amount of AI-generated patches unlike = Ghostty and cURL, but we have received some that have been very low = quality and when asked questions, the person who submitted this patch = raised his hands and dropped out. This is just a waste of time for = everyone involved. >> This policy that I have slightly adapted for IPFire demands that any = kind of AI usage is allowed, but has to be disclosed. The point is to = avoid any kind of low-quality, time-wasting submissions. I too believe = that we should make this known upfront so that we can all be on the same = page and make the job easy for us in case we need to reject any kind of = patch submission. >> On the other hand, the policy is encouraging AI usage as there are = indeed tasks where AI can help. But just because it is AI-generated does = not mean that something is good. >> I would like you all to have a look at this and see if this is = working for you as well or if you would like to have any changes made to = it: >=20 > Most of it seems fine to me and I agree with it. Good! > The only concerns are that it refers to pull requests from external = users but as far as I am aware we generally don't accept pull requests, = certainly not in the GitHub repo. If any IPFire GitHub pull request has = any merits then an IPFire developer has to take the pull request and = convert it into an IPFire patch submission supplied to the IPFire = Development mailing list. The original version used =E2=80=9CPull Request=E2=80=9D whenever they = talked about a contribution. We don=E2=80=99t normally use those, = certainly not using GitHub. There is however some documentation about PRs in case there are huge = patch sets. You know well how good Patchwork is with huge patch sets. It = is documented here: https://www.ipfire.org/docs/devel/git/pull-requests We pretty much never use this, but that does not mean that we won=E2=80=99= t in the future. So in this sense I kept pull request in one place of = the policy. Actually we are talking about any kind of contribution. I = hope the text is inclusive of all of this. > If the intent of pull request as mentioned in the AI Policy is = different than what I have described above then it is not clear to me = from the policy wording. We definitely don=E2=80=99t mean GitHub PRs. Those are shit and actually = a huge contributor to why so many projects are receiving so many AI slop = as they make these drive-by =E2=80=9Ccontributions=E2=80=9D so easy. -Michael > Regards, >=20 > Adolf. >=20 >=20 >> https://www.ipfire.org/docs/devel/ai-policy >> All the best, >> -Michael >=20 >=20