France
Joined: Nov 7, 2005
Post Count: 9416
Status:
Offline
Re: Move to git (and github)?
Sweet Home 3D repository already moved to SVN a few months ago, because SoureceForge.net decided to drop support of CVS but this broke many links to source code and help pages that I was using in the forum. So sorry, don’t hope it will change again to a complex system as Git anytime soon just for the sake of modernity.
----------------------------------------
Emmanuel Puybaret, Sweet Home 3D developer
United States
Joined: May 27, 2018
Post Count: 3
Status:
Offline
Re: Move to git (and github)?
Git GitHub Slack
Please may we discuss a github and a slack channel for the community... id also like to include it in my Open Source Creative Community / MeetUps where we help teach and advocate use of OS software...
Joined: Jan 8, 2017
Post Count: 18
Status:
Offline
Re: Move to git (and github)?
At least have a mirror on Github or Gitlab that has a bot to notify you of Pull Requests. This way devs could look at the code accessibly and even send patches. The Scribus project still uses SVN but it has a GH repo that it can 'accept' (they still need to be converted to patches and submit but there were devs that would do that) patches from 3rd party devs.
France
Joined: Nov 7, 2005
Post Count: 9416
Status:
Offline
Re: Move to git (and github)?
Come on guys, I already answered to this request a few months ago, and the only official repository will remain on SourceForge.net until further notice. What code patches (real improvements not typo corrections in comments) do you want to propose that would make the difference if Git is used rather than SVN?
----------------------------------------
Emmanuel Puybaret, Sweet Home 3D developer
Joined: Jan 8, 2017
Post Count: 18
Status:
Offline
Re: Move to git (and github)?
@Puybaret I'm not advocating for you to leave SF and change from SVN to git. Tt's really about accessibility. Essentially I'm for being open to explore having a presence on Github or Gitlab and being receptive to code contributions from those places.
I've been lurking on FOSS projects for several years now and I've noticed a significant difference between FOSS projects. Take for example Scribus's approach (used to be on SF but now self-hosts and still using SVN and mirrors to Github) and say FreeCAD's which uses git and is based on Github (used to be based on SF).
Scribus is a small team that had a lot of growth earlier in it's timeline. This was in part due to a whole host of c++ proficient developers dropping in and contributing code. When that developer pool oriented to more modern higher level languages the contributions dropped. When the project started mirroring it's SVN to GH the contributions started to rise again because GH was how people found code and browsed through it comfortably and easily. But from what I saw when I participated in their community, the core-devs weren't interested in github culture and wouldn't incorporate it in to their workflow. So a handful of volunteers would actually convert the github PRs in to patches and submit it to the official scribus bugtracker for review because if they didn't the PRs would just rot. Many of those patches were merged. Of course some of the PRs were of low quality but not all of them. And so the project missed many opportunities to onboard volunteer talent and let a lot of patches - that with a little love could of made it in to trunk - rot.
Now take for example, FreeCAD. I believe it used to use SVN and was hosted on SF. It is written in C++ and python. When it shifted to git and changed hosting to GH (again, I'm not advocating for that) the volunteer code contributions just keeps on growing. The core-devs embraced change and it's made a difference in the quality of the community. Of course this has a lot to do with a strong community forum culture and the project using python, which is popular ATM and makes hacking on the code fairly easy without the need to compile each time.
But beside that users can navigate the code very comfortably using the github interface. And they can quickly make a PR which runs Continuous Integration tests on it and also post it to the forums for review by a small army of independent devs (taking the stress off the core-devs).
So essentially what I'm advocating for is that you create a GH mirror, with Continuous Integration and tests and be open to PRs submitted through that avenue, so that SH3D could benefit from another portal to onboard talent from. Keep SVN and accept git formulated patches in a way like I stated previously in this thread. Be receptive to Github/Gitlab activity.
France
Joined: Nov 7, 2005
Post Count: 9416
Status:
Offline
Re: Move to git (and github)?
For your information, contributors to Sweet Home 3D are mainly translators, 3D model designers and people helping other users in this forum or with documents they share. These people are rarely aware of how a repository works, and I take care to integrate their contributions obtained through other easier means (mails or SourceForge tickets). There are also a few programmers who proposed some plug-ins and until now, this seems to have been a good way to learn Sweet Home 3D architecture and integrate additional features, without taking the risk to deteriorate its quality. Beside that, I'm the only developer of Sweet Home 3D application, which makes me wonder how useful it will be to take care of another repository system. In the past, I spent some time to help some developers who wanted to contribute directly to Sweet Home 3D (see thread #3067 and thread #3113), but this gave no result... Not very encouraging even if I can understand your arguments
----------------------------------------
Emmanuel Puybaret, Sweet Home 3D developer
Joined: Jan 8, 2017
Post Count: 18
Status:
Offline
Re: Move to git (and github)?
@Puybaret fair enough though I do have some responses if you'd be interested to hear?
For your information, contributors to Sweet Home 3D are mainly translators, 3D model designers and people helping other users in this forum or with documents they share. These people are rarely aware of how a repository works, and I take care to integrate their contributions obtained through other easier means (mails or SourceForge tickets).
This is typical, right? A large part of the community usually isn't oriented toward infrastructure so much. Though, and this is not what I'm recommending, they could be captivated to learn more in that direction. End-users are educable. Again I'm not advocating for this per se.
There are also a few programmers who proposed some plug-ins and until now, this seems to have been a good way to learn Sweet Home 3D architecture and integrate additional features, without taking the risk to deteriorate its quality.
This is the power user/developer portion of the community. They have a lot more perseverance, interest, and captivation to learn and contribute. It seems that they can code plugins independent of having you merge their code in to trunk.
Beside that, I'm the only developer of Sweet Home 3D application, which makes me wonder how useful it will be to take care of another repository system.
This is an important reason, time-management and learning a whole other repository system. So in this regards, Github/Gitlab acting as a mirror, you can choose to remove the option for people to report issues/bugs and just soley accept Pull Requests. To me this is not much work. I anticipate there will be people that would want to converse with you about the PR but you can simply respond to them either there or direct them to this forum for further discussion.
Also I will say in thread #3113 the OP was asking to look at past commits in order to learn, I'm assuming about, how you approached fixes. I personally find SF not a very friendly interface to use to browse code especially code history, it takes many clicks and the interface is clunky. Essentially creates a high barrier for entry and simplicity in these more modern times when devs are used to slicker and more robust UIs.
All I ask is to consider this idea and if you're inclined, try a test run...maybe a few months. If you need help with writing documentation on how to submit PRs etc...I'd be happy to. I've written some for other projects already. I think we may be surprise at what independent devs may submit, especially to a project like this one. Though, Java isn't the most perceived collaborative language on repository sites like Github or Gitlab, I thunk we'll still be pleasantly surprised.
