There aren’t going to be great answers to this because it is hard to solve a social issue via technical means. But my 2c here is that if you absolutely have to fork, maintaining the fork as a patchwork repo on top of the Portfile repo is in play. If the rebase is done manually, or with some CI, you also have some quality assurance that the patched repo works and can minimize time spent on testing.
David Gilman :DG< On Mon, Jan 8, 2024 at 9:53 AM Kirill A. Korinsky <[email protected]> wrote: > Hi Perry, > > > On 8. Jan 2024, at 15:50, Perry E. Metzger <[email protected]> wrote: > > > > I'd like to float the idea that we create a fork of the MacPorts > repository that is devoted to operating systems and hardware that is more > than (say) a decade old, and that we allow the people who are interested in > maintaining that software to freely work on it. It doesn't hurt the rest of > us after all, and it absolves us of the need to keep the main MacPorts > repository complicated by patches to support very old systems. > > > > How do you see the way to backport changes from upstream MacPorts to > legacy MacPorts? > > at some point automatical merge would be broken on conflicts, and I assume > quite fast. > > -- > wbr, Kirill > >
