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 4f0hrM2SVsz2yBj for ; Tue, 27 Jan 2026 10:45:23 +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 4f0hrH5jStz2xdr for ; Tue, 27 Jan 2026 10:45:19 +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 4f0hrH1033z5cX; Tue, 27 Jan 2026 10:45:19 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1769510719; 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=YMFGEW3QZKXIhJhf5zmKZ8m58P6zG024zjytk5zj0Jw=; b=675zsma2C/e6oqSQTIqz4RlExduhYNvTPspfF8Bwca9l3zIUJWZCUzPYwD5/KUeUw3KgAP Dt9nMZFJX559goBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1769510719; 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=YMFGEW3QZKXIhJhf5zmKZ8m58P6zG024zjytk5zj0Jw=; b=rFTDMg0veQLnxIjO/PD5fAJo/b35ltcrfZbVEkwtsu103MiOFhWZbcBQ0UTdaD1jkFhymY 3C6mpeMnQtTAEFBK8iVhadJFADxlQu9IjYdPAwYlENcuyf2SxmObej2sPcQsR4qCeQ0Xso RfXCrLo9+ZUxtnt5s5UQdJfBjmf31xcQp7YnTPDnJh7m6pZYssJBgalOnL1h+rsd+1bi8d KHaYnkR14QqqfoFnqs7qX8zKHLxQ839+Utsx/f54y4cMDmjn2N00LOpVJ2op20ycxngKjr 471N6fB077Fag3ordgYd5IKQW0yVS8kT0s2Urwu2FJjsr2U3zF6MTZVnFc7Jww== 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: Date: Tue, 27 Jan 2026 10:45:18 +0000 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <79BB64F2-E33D-469B-A3B4-DA1463433D09@ipfire.org> References: <825C0B91-4C7B-4352-9469-4148E6337AA0@ipfire.org> <53ba3fe3aa6c9384fb1e5c5dc547802dd9558baa.camel@ipfire.org> <73B417BD-FF07-4721-8BAA-101A5087C53D@ipfire.org> To: Adolf Belka Hello, > On 26 Jan 2026, at 20:21, Adolf Belka wrote: >=20 > Hallo, >=20 > On 26/01/2026 18:13, Michael Tremer wrote: >> Hello, >> Sorry for not replying any earlier=E2=80=A6 >> I wanted to write up some more thoughts about basically closing our = GitHub account. This has been a long standing thought that I had since a = lot of Open Source projects have taken this step. Possibly for other = reasons, but I don=E2=80=99t believe that we are benefitting much from = our GitHub account at all. >> So initially we started this because we wanted to make sure that = IPFire will be available to more people. A GitHub search won=E2=80=99t = show us unless we have a copy of our repository, and it was also = intended as a backup in case our Git server is down for a moment. >> The backup is probably the only thing that is still a valid argument = to me. Otherwise, we have no option to disable PRs and we have seen a = lot of people who have always been ignoring any hints or even willingly = went against it and still opened any issues and PRs there. This has just = created extra work with no noticeable outcome. >=20 > I have never seen anyone who has posted a PR on our GitHub page ever = attempting to submit patches on our mailing list let alone starting a = discussion. There is a link to the IPFire web site at the top of the = GitHub page and in the Readme there are several links pointing to = various locations giving info on how to support/contribute etc >=20 > I believe those users who submit PR's in GitHub do that elsewhere in = other projects and are not willing to change to follow the IPFire = approach. We have had that with other users who have said, here is my = patch done my way, if you want it done differently then it is up to us = to re-write it. I absolutely agree. Although I don=E2=80=99t want to completely deny = people dropping of a quick fix to a small problem, we cannot tolerate = the kind of drive-by submissions that we have seen. There has never been = anything good coming out of them. If someone does not really want to spend the time to subscribe to our = mailing list to email a patch, I suppose that their fix is really not = important to them. We will have to have a hurdle to filter out these things or otherwise we = will create too much work for ourselves. >> Other open source projects are prominently moving away from GitHub = because of Microsoft=E2=80=99s influence and although this argument is = not as strong for as because we are not using GitHub as our primary = space for any sources, I agree with the intentions of those projects. >> Initially I thought that we should only remove the ipfire-2.x = repository, but now looking at it again, I don=E2=80=99t see why else we = would host anything there whatsoever. Currently we have libloc and ddns = copied there, too: >=20 > I think we should completely remove it. I don't believe we will lose = much in not having it. >=20 > Anyone doing a search for IPFire will find our web site, community, = git repo etc long before they find the github search result. I only checked this now=E2=80=A6 When typing in =E2=80=9CIPFire git=E2=80=9D= into Google, I am getting GitHub as the first hot. On there, there is = pretty much nothing. It looks like the project is *very* idle, which is = absolutely not true. This might be potentially harmful for the = project=E2=80=99s public image. >> https://github.com/orgs/ipfire/repositories >> Does anyone have any feelings about this? Should we just close it and = therefore the whole PR problem in the test is resolving itself somewhat? >=20 > Maybe. Our documentation talks about Patch Submission and if someone = wants to do an update we ask them to submit a patch so I think the = policy would be better aligned with the wording Patch Submission rather = than PR. Not a deal breaker for me and the worst is that we end up with = having to explain to users that PR means Patch Submission for the IPFire = AI Policy. Patch submission is great for me. That is term that is broad enough and = for any specifics there is more documentation on how to actually submit = smaller and larger changes. -Michael >=20 > Regards, >=20 > Adolf. >=20 >> -Michael >>> On 25 Jan 2026, at 17:38, Stefan Schantl = wrote: >>>=20 >>> Hello Michael, >>>=20 >>> thanks for working this out. >>>=20 >>> I've read through the document and it is very good written. Similar = to >>> Adolf I would clarify a bit more what a "Pull request" is and what = kind >>> of requests we accept and which not. >>>=20 >>> Best regards, >>>=20 >>> -Stefan >>>> Hello everyone, >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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 >>>> https://www.ipfire.org/docs/devel/ai-policy >>>>=20 >>>> All the best, >>>> -Michael >>>=20 >=20