On Do 05 Mär 2015 16:33:17 CET, 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: 1. 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. 2. 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. 3. I am maintaining Windows XP compatibility for the time being. 4. 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: 1. 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. 2. SourceForge has recently done terrible things as GitHub has gained popularity: https://en.wikipedia.org/wiki/SourceForge#DevShare_adware_controversy 3. My repo isn't very visible because it is a personal git repo, not a project repo. 4. 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: 1. Host VcXsrv on both code.x2go.org and https://github.com/arcticaproject , simiilar to how nx-libs is hosted. 2. Prefer github for issue tracking. If an issue does affect X2Go users, then use the X2Go BTS and link to the github issue tracker. 3. 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 4. 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. 5. 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-project/ 6. Rebase to VcXsrv 1.16.x in time for X2Go Client 4.0.4.0. 7. Pull from upstream VcXsrv (the master branch) continuously. 8. Hopefully receive many pull requests via GitHub :) -Mike#2
+1 from here. Mike#1 -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
pgpVM7W3GgKNi.pgp
Description: Digitale PGP-Signatur
_______________________________________________ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev