keeping software forks under MacPorts repo?

[Chris Jones]

> On 9 Nov 2019, at 5:00 pm, Mojca Miklavec <mojca at macports.org> wrote:
> 
> On Sat, 9 Nov 2019 at 17:54, Ken Cunningham wrote:
>> 
>> In #57751 Michael and I have been talking about how keeping up the patchset for qt4 would probably be easier with our own fork of it, with our patches added on.
>> 
>> QT4 has a github repo here <https://github.com/qt/qt> and we could fork that to MacPorts repo, and add our patches on there. Then we could draw from that repo for builds instead of the way we do it now. We both think this would be easier.
>> 
>> I see Haiku already does that exact thing for some of their ports.
>> 
>> Hopefully leaving aside a discussion about older systems / lots of patches/ etc for the moment, is there any interest in having these occasional forks under MacPorts github repo?
>> 
>> Otherwise either Michael or I can do it ourselves, but that might have access issues someday...
>> 
>> On a similar note, we have a couple of ports in the same boat (llvm*, for example). In those, Jeremy has his own fork with our patches, and uses a script to generate the patchsets — but that’s tricky, because I can’t access his repo very easily, so my patches are “extras” to his…
> 
> As long as someone is responsible for the individual repositories, I
> would personally support this idea. But we would probably want to
> prefix the repository names (something like "fork_qt", "fork_llvm") to
> clearly distinguish them from our main repositories. Is it possible to
> set up a cron job to keep the upstream branches and tags fully up to
> date (but without deleting our own branches, and ideally without
> accumulating deleted upstream branches)?

I don’t see much advantage to setting up a complex system to automatically keep the forks up to date. In practise, the fork will only need to be updated whenever someone is looking to make a new release in macports from them, so when this happens they can just do this themselves in their own checkout, and manually push it back. In fact, it probably would be better to have this a manual process as it might have to deal with conflicts with whatever patches the fork is using on occasion.

Chris

> 
> Mojca