Project Panama is moving to GitHub
John Rose
john.r.rose at oracle.com
Sat Jan 25 03:24:01 UTC 2020
On Jan 24, 2020, at 3:10 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
> "A Project must be sponsored by one or more Groups. A Project may have web content, one or more file repositories, and one or more mailing lists."
>
> So I think, process-wise, we probably have cover.
Yes, we do have permission to make more repos in
any given project, although we don’t make use of
that ability much, except at the inception of a project.
I also think that the git-based infra will scale well
to a multi-repo use case. In the OpenJDK we have
lots of fork-like copies of the JDK, each with a
cluster of localized changes. I assume the GitHub
back end is able to recognize that there are many
objects in common between the various repos.
(Not getting into an hg-vs.-git evaluation here. It’s
likely that hg also has some story for partial sharing
across local repos. But AFAIK OpenJDK infra. doesn’t
use such a thing.)
So we can reconsider our choice to use branches, since
on GitHub we can spin up forks about as easily as branches.
I think our use of branches has worn well on the hg infra,
and would continue to wear well on GitHub. So I don’t
see much pressure to move to separate repos, other than:
1. Separate repos allow separate mirroring decisions for
Vector and Foreign.
2. We could make the Vector and Foreign work less visible
to people that don’t want to see one project or the other.
FTR, neither of those strike me as very strong reasons
to use multiple repos. Googling around on the theme
of “git fork vs. branch” suggests that forking is most
useful at a trust boundary, or divergence of artifacts,
but the whole OpenJDK is really just one trust domain,
one team, and one main result (the Java RI).
Caveat: I’m no expert in git vs. hg or fork vs. branch.
— John
More information about the panama-dev
mailing list