keeping software forks under MacPorts repo?

[Ken Cunningham]

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 > 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…

Ken

Re: keeping software forks under MacPorts repo?

[Mojca Miklavec]

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  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)?

Mojca

Re: keeping software forks under MacPorts repo?

[Ryan Schmidt]

On Nov 9, 2019, at 10: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  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?

That seems reasonable to me for projects like qt4 and llvm where we have 
extensive patches. 

But for many projects (is Qt one of them?) upstream produces release tarballs 
that contain generated files (like configure scripts) that aren't in the repo. 
We would either have to produce those tarballs ourselves, or else make the 
ports use ./autogen.sh or equivalent. 


> 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…

Back when Jeremy was maintaining these ports more actively, llvm used to use a 
Subversion repository. I suppose Jeremy maintained his fork using git-svn. Now 
that they've migrated to git, keeping a fork of their repo should be easier. 

Re: keeping software forks under MacPorts repo?

[Ryan Schmidt]

On Nov 9, 2019, at 11:00, Mojca Miklavec wrote:
> 
> But we would probably want to
> prefix the repository names (something like "fork_qt", "fork_llvm") to
> clearly distinguish them from our main repositories.

I wouldn't necessarily suggest doing that. We're not forking in order to 
diverge from upstream and evolve the software into a different product. We're 
only doing it to apply bug fixes. 


> 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)?

Given how pervasive git is today, there probably is. But syncing out fork with 
upstream seems like a normal task that a developer would be expected to do 
manually at their convenience. 

Re: keeping software forks under MacPorts repo?

[Ken Cunningham]

> On Nov 9, 2019, at 9:06 AM, Ryan Schmidt  wrote:
> 
> On Nov 9, 2019, at 11:00, Mojca Miklavec wrote:
>> 
>> But we would probably want to
>> prefix the repository names (something like "fork_qt", "fork_llvm") to
>> clearly distinguish them from our main repositories.
> 
> I wouldn't necessarily suggest doing that. We're not forking in order to 
> diverge from upstream and evolve the software into a different product. We're 
> only doing it to apply bug fixes. 


if it was decided to proceed, perhaps MacPorts/qt4 might be a reasonable name 
for the fork …

the default  fork name of “qt” is not specific enough, I think.

Thanks for considering.

K

Re: keeping software forks under MacPorts repo?

[Christopher Jones]

> On 9 Nov 2019, at 5:06 pm, Ryan Schmidt  wrote:
> 
> On Nov 9, 2019, at 11:00, Mojca Miklavec wrote:
>> 
>> But we would probably want to
>> prefix the repository names (something like "fork_qt", "fork_llvm") to
>> clearly distinguish them from our main repositories.
> 
> I wouldn't necessarily suggest doing that. We're not forking in order to 
> diverge from upstream and evolve the software into a different product. We're 
> only doing it to apply bug fixes. 

I agree. changing the name is unnecessary and for me would in itself be 
confusing.

forking is standard in GitHub, and never changes the name of the repo. e.g.

https://github.com/cjones051073/macports-ports 


is my fork of

https://github.com/macports/macports-ports 


and it is clearly stated at the top this is the case. I see no benefit in 
changing it by appending “fork_”.

Chris

> 
> 
>> 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)?
> 
> Given how pervasive git is today, there probably is. But syncing out fork 
> with upstream seems like a normal task that a developer would be expected to 
> do manually at their convenience. 



smime.p7s
Description: S/MIME cryptographic signature

Re: keeping software forks under MacPorts repo?

[Christopher Jones]

> On 9 Nov 2019, at 5:24 pm, Ken Cunningham  
> wrote:
> 
> 
> 
>> On Nov 9, 2019, at 9:06 AM, Ryan Schmidt  wrote:
>> 
>> On Nov 9, 2019, at 11:00, Mojca Miklavec wrote:
>>> 
>>> But we would probably want to
>>> prefix the repository names (something like "fork_qt", "fork_llvm") to
>>> clearly distinguish them from our main repositories.
>> 
>> I wouldn't necessarily suggest doing that. We're not forking in order to 
>> diverge from upstream and evolve the software into a different product. 
>> We're only doing it to apply bug fixes. 
> 
> 
> if it was decided to proceed, perhaps MacPorts/qt4 might be a reasonable name 
> for the fork …

Thats exactly my point. "MacPorts/qt4” is enough to signify its a fork. Adding 
“fork_” to the name is IMHO pointless and in fact adds confusion, not removes 
it.

Chris


> 
> the default  fork name of “qt” is not specific enough, I think.
> 
> Thanks for considering.
> 
> K



smime.p7s
Description: S/MIME cryptographic signature

Re: keeping software forks under MacPorts repo?

[Chris Jones]

> On 9 Nov 2019, at 5:00 pm, Mojca Miklavec  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  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