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: > > 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 > _______________________________________________ > x2go-dev mailing list > [email protected] > http://lists.x2go.org/listinfo/x2go-dev
Sounds good to me. Bye Henning _______________________________________________ x2go-dev mailing list [email protected] http://lists.x2go.org/listinfo/x2go-dev
