[x3d-public] [x3d] X3D Working Group meeting 19 OCT 2018 minutes: github mirroring, driving towards X3D interoperability

[Michalis Kamburelis]

Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> wrote:
>
> (Changed subject line to match discussion... added other key X3D implementers.)
>
> Thanks for the description of your github mirroring plans Michalis.
>
> No need for propagating 'legacy' tree, that is a safety net for old work.
>
> *However* you can still color me "puzzled" why you are motivated to put effort into this mirroring.
>
> For starters, here are most obvious downsides:
> a. what benefits occur?

Because GitHub is better than SourceForge in various small ways, IMHO.

- If you look at others: Most open-source projects are already on GitHub.

    - Khronos specifications (glTF, KTX...) and code is developed on GitHub.
    - As well as Web3D specifications, although private.
    - As well as X3DOM, X_ITE, view3dscene/Castle Game Engine.

- You can easily add Continuous Integration on GitHub.
- I migrated my own projects from SourceForge to GitHub during last
years, and I'm happy with the result.

For now, the repo on GitHub will remain read-only. But I hope that in
the future we could just switch to using GitHub (and then SourceForge
would be a read-only mirror). And then we get the *big* benefit of
GitHub:

- We could use GitHub "pull requests", which are a great way to
contribute code to projects, much better than sending SVN/GIT patches
IMHO. "Pull requests" allow external contributors (that do not have
write access to main repo) to contribute non-trivial changes, by
making commits in their own fork. It's a new workflow, and it really
makes a huge difference in my opinion -- both in my experience as
contributor to projects, and in my experience as author of open-source
projects that looks for contributions from other people.

> b. original authoritative sources remain elsewhere; how to synchronize updates?

I will set a script using https://github.com/michaliskambi/sync2git
that synchronizes updates automatically. Every commit on SourceForge
will automatically make a commit on GitHub, within max 15 minutes.

> c. similarly how to reconcile conflicts between archives?

There are no conflicts. GitHub version is read-only, for now.

In the future, if you like it, we could swap: SourceForge would be
read-only, and commits go to GitHub. In any case, no conflicts can
occur.

(Setting up two-way synchronization is possible, I did it at one point
for my project with sync2git... But this was *not* working reliably,
so I don't pursue this here. Either GitHub (now) or SourceForge (in
potential future) are read-only, thus preventing any conflicts.)

> d. what happens to years of version-control change history when you copy?

It is preserved. All the authors and all changes are preserved in a
new repository, using sync2git I linked above (which uses git2svn
under the hood). You can look at historical versions, compare
differences, run "git blame" etc. I did test this on my large
projects, it really works reliably.

> e. there are multiple projects with a lot of build scripts that each have multiple workflows, now what?

I simply synchronize the repository contents. Files remain the same.
And the SourceForge SVN remains working, too. So no workflow needs to
change.

> f. what are identified problems with current workflow that such version-control mirroring might fix?

See the answer to point A above:

- There are some small advantages in having a GitHub mirror.

- And it's a first step to a possible future where GitHub would be
used for development (and SourceForge read-only). Essentially, it's a
"demo" for you, to show you how it looks on GitHub. If you like it
(and only then, of course), then we can switch to developing on
GitHub.

    And then we would get that *big benefit*: "Pull requests" are
great, and GitHub (as well as some others, like GitLab and Assembla)
make using "pull requests" really comfortable. This feature is not
available on SourceForge, with SVN or GIT repo (in theory, you could
use SourceForge GIT repo, and use GIT to fork and "manually" do
something similar to pull requests; but using a system that has pull
requests built-in, like GitHub, is much more comfortable).

    If you didn't use pull requests, I advice to play around with them
:) You can e.g. submit some modification / addition to my X3D test
files on https://github.com/michaliskambi/x3d-tests/ .

> Meanwhile SourceForge (where these code and example archives reside) support includes git.  Not sure, perhaps even alignable with subversion?
> - https://sourceforge.net/p/forge/documentation/Git
> - https://sourceforge.net/p/forge/documentation/SVN%20Overview

This way you could convert SVN to GIT.

But you do not get pull requests, or nicer GitHub website, this way.

>
> I certainly don't want to inhibit growing activity but it looks like it will make things more difficult for us to keep aligned, and possibly much more time needed for me to keep our X3D workflow stable.  Ouch ouch.

I'm really sure that no problems will happen :) You can simply ignore
the new GitHub repository, and no additional work will come from it.

Setting up a mirror from one repository to another (SourceForge ->
GitHub, or GitHub -> SourceForge) is not that uncommon. The
synchronization happens automatically. Projects like "freepascal" are
doing it for years.

>
> g. Updated our X3D Node Inventory Comparison support spreadsheet to show everyone's latest greatest:
> h. Share/compare open-source code as appropriate to get all major browsers supporting X3D Interchange and Interactive Profiles.
> i. Continue prioritization of all major browsers to finally achieve X3D Immersive Profile.
> j. Enter new year with active collaborations in place to accelerate X3D v4.0 implementations.

The fact that I'm spending time on the "GitHub mirror" task doesn't
mean that less time is spend on the G-J points you mentioned.

As for G: as far as view3dscene/CGE is concerned, this spreadsheet
needs no updates.

As for H-J: I do not see how I could contribute there. I'm interested
in making the X3D specification better, making development of X3D
specification better (which includes proposing better tools, like
GitHub) and in pursuing my own X3D implementation (view3dscene/CGE).
I'm afraid that I don't see how I could help in H-J points.

And nobody else will lose time because of the "GitHub mirror" task :)

Regards,
Michalis