[x3d-public] [x3d] X3D Working Group: github mirroring, driving towards X3D interoperability

Wed Oct 24 08:58:42 PDT 2018

Michalis thanks for the in-depth responses to all my concerns, really appreciated.  I share your important motivations.

Several of us had an opportunity to discuss during the weekly Web3D Communications Team teleconference (Nicholas Polys, Anita Havele, Vince Marchetti, myself).

Going forward, following all your good reasons seems to be worthwhile for how the X3D working group + X3D community might progress in long term.

If you want to perform such a mirroring test immediately, please go ahead; might also wait a bit, since it also makes sense to set up for even more success.

Clearly this is a bit complicated too.  We want to do things well, not add confusion to existing sophistication.  We don't want to break things that work.

So.  It seems like there are maybe three broad categories of version-control source exposure:

a. *Private*: Draft specifications (Web3D member only, private, follows strict rules by ISO and Web3D, currently Github)
b. *Controlled*: Schemas, tools, other open resources (currently Sourceforge, vetted by unit testing, confirmed by X3D working group oversight).
c. *Curated*: Example scenes, X3D Tooltips, tools and implementations (currently Sourceforge, keeping track with mailing list communications).

So we should strive to understand by producing a plan - won't be hard.  Carpenter's motto:  "measure twice, cut once."

Again thanks for your great efforts.  Looking forward to further progress, all together.

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
> 

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman