To get back to the original point of the discussion: I see a value to having a repository that follows the goals stated by @Slamdunk. I also agree with @froschdesign in theory in that it may end up being difficult to maintain in the long run.
However, the reality is that there are ZF1 applications that are still running and still moving forward on this old code. They do need to be migrated. But as @froschdesign said, a soft migration is best, and that can take months or years. In the meantime, some portion of the code in this applications will be dependent on ZF1, while newer portions may well need to take advantage of PHP 7.1, 7.2 or possibly later. We may also not want these applications marooned on an old version of PHP that is past EOL and no longer receives security updates.
Therefore, we might as well have a community fork that makes it possible to share these patches. The alternative will be each of us creating our own fork, and each of us writing all of the patches.
I would also be for the inclusion of:
- A list of classes/issues that cannot reasonably be fixed so they can be avoided or worked around.
- Code that streamlines migration. That’s possibly a separate repo though.
As long as the fork clearly states that it isn’t for new projects, I don’t see the harm.