On Thu, Mar 05, 2015 at 10:33:17AM -0500, Michael DePaulo wrote:
Hi everybody,
This is something I wanted to discuss at our meeting today: http://wiki.x2go.org/doku.php/2015-03:day-2015-03-05?s[]=meeting
Intro:
For those who do not know, VcXsrv is a port of the X.org X server to Windows. Specifically, the MS Visual C compiler. X2Go Client for Windows bundles and uses it. So does PyHoca-GUI.
SourceForge lots you create personal git repos based off of official project repos. So here is my branch on my personal git repo: https://sourceforge.net/u/mikedep333/vcxsrv/ci/xp-1.15.2.x-x2gochanges/tree/
The differences from usptream VcXsrv are:
- I am currently maintaining the 1.15.2.x branch, rather than the 1.16.x branch of upstream. Upstream never maintains previous branches/releases.
- I applied the nx-libs compatibility/bugfix patch from Alex, winmultiwindow.patch . I am keeping this on a branch with the suffix "-x2gochanges" branch because my convo with Alex indicated that upstream would not accept it.
- I am maintaining Windows XP compatibility for the time being.
- I respond quickly to security vulnerabilities in xorg-server and all the other bundled components (e.g., openssl, freetype2, X11 libs) Upstream simply updates/upgrades each component to the latest versions (even unreleased master branches often) on a seemingly arbitrary schedule.
There are a few problems with using SourceForge:
- SourceForge's support for git is terrible. Whenever I attempted a "request merge" from branch Y on my repo to the master branch on the usptream VcXsrv repo, it treid to merge my master branch instead.
- SourceForge has recently done terrible things as GitHub has gained popularity: https://en.wikipedia.org/wiki/SourceForge#DevShare_adware_controversy
- My repo isn't very visible because it is a personal git repo, not a project repo.
- Upstream VcXsrv (1 developer, marha) is horribly unresponsive. They ignore bugs and merge requests for CVEs. Only once have I gotten an email reply to a merge request. He had a valid reason to reject the merge request, but he didn't actually reject it, so it is still open. I never had a bug report replied to. So effectively, staying on SourceForge does not enable us to upstream anything.
Here is what I propose:
- Host VcXsrv on both code.x2go.org and https://github.com/arcticaproject , simiilar to how nx-libs is hosted.
- Prefer github for issue tracking. If an issue does affect X2Go users, then use the X2Go BTS and link to the github issue tracker.
- Create a README.md similar to the one for nx-libs 3.6.x https://github.com/ArcticaProject/nx-libs/blob/3.6.x/README.md
- Do not rename VcXsrv. State in the README.md that Arctica and X2Go are maintaining branch X or branch Y currently, or possibly even 2 branches at once. This is analogous to Linux distros maintaining a version of a package.
- In the README.md or the github releases page, link to our builds under: http://code.x2go.org/releases/binary-win32/3rd-party/vcxsrv-modified-by-x2go...
- Rebase to VcXsrv 1.16.x in time for X2Go Client 4.0.4.0.
- Pull from upstream VcXsrv (the master branch) continuously.
- Hopefully receive many pull requests via GitHub :)
-Mike#2
x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
Sounds good to me.
Bye Henning