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

Leonard Daly Leonard.Daly at realism.com
Tue Oct 23 20:24:54 PDT 2018

Reduced distribution to just X3d-Public to help reduce duplication. I do 
not mind if others are [re-] added.

It's easiest to say that I completely agree with Michalis. The only 
advantage he did not point out is that the younger developers are (for 
the most part) exclusively using GitHub. It attracts more attention and 
respectability than other systems.

Leonard Daly

On 10/23/2018 11:27 AM, Michalis Kamburelis wrote:
> 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
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

*Leonard Daly*
3D Systems & Cloud Consultant
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181023/1c4e4997/attachment.html>

More information about the x3d-public mailing list