public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: "Jon Murphy" <jon.murphy@ipfire.org>
To: "Michael Tremer" <michael.tremer@ipfire.org>,
	"Stefan Schantl" <stefan.schantl@ipfire.org>
Cc: "IPFire: Development-List" <development@lists.ipfire.org>
Subject: Re[2]: An AI Usage Policy for IPFire
Date: Mon, 26 Jan 2026 20:17:33 +0000	[thread overview]
Message-ID: <embe6fadad-dfd3-42eb-beba-0614559132e3@ipfire.org> (raw)
In-Reply-To: <73B417BD-FF07-4721-8BAA-101A5087C53D@ipfire.org>


I would prefer to keep the ipfire-2.x repository on Github.  For me, 
Github is much easier to work with and search.

If it helps, I volunteer to keep an eye on push requests, respond to 
them as needed, and then close them.

Jon


------ Original Message ------
From "Michael Tremer" <michael.tremer@ipfire.org>
To "Stefan Schantl" <stefan.schantl@ipfire.org>
Cc development@lists.ipfire.org
Date 1/26/2026 11:13:56 AM
Subject Re: An AI Usage Policy for IPFire

>Hello,
>
>Sorry for not replying any earlier…
>
>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’t 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’t 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.
>
>Other open source projects are prominently moving away from GitHub because of Microsoft’s 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’t see why else we would host anything there whatsoever. Currently we have libloc and ddns copied there, too:
>
>   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?
>
>-Michael
>
>>  On 25 Jan 2026, at 17:38, Stefan Schantl <stefan.schantl@ipfire.org> wrote:
>>
>>  Hello Michael,
>>
>>  thanks for working this out.
>>
>>  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.
>>
>>  Best regards,
>>
>>  -Stefan
>>>  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:
>>>
>>>    https://www.ipfire.org/docs/devel/ai-policy
>>>
>>>  All the best,
>>>  -Michael
>>
>
>


  reply	other threads:[~2026-01-26 20:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23 14:48 Michael Tremer
2026-01-23 17:30 ` Adolf Belka
2026-01-23 17:50   ` Michael Tremer
2026-01-23 18:13     ` Adolf Belka
2026-01-25 17:38 ` Stefan Schantl
2026-01-26 17:13   ` Michael Tremer
2026-01-26 20:17     ` Jon Murphy [this message]
2026-01-27 10:37       ` Michael Tremer
2026-01-26 20:21     ` Adolf Belka
2026-01-27 10:45       ` Michael Tremer

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=embe6fadad-dfd3-42eb-beba-0614559132e3@ipfire.org \
    --to=jon.murphy@ipfire.org \
    --cc=development@lists.ipfire.org \
    --cc=michael.tremer@ipfire.org \
    --cc=stefan.schantl@ipfire.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox