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
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
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:
- 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
+1 from here.
Mike#1
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Thu, Mar 5, 2015 at 4:22 PM, Mihai Moldovan <ionic@ionic.de> wrote:
On 05.03.2015 04:33 PM, Michael DePaulo wrote:
- Host VcXsrv on both code.x2go.org [...]
Ping me if you need this set up and I'll do it, including importing your SF data.
Mihai
Thanks for the offer.
I imported it to GitHub successfully: https://github.com/ArcticaProject/vcxsrv And as you can see, I created a README.md.
I will import it to code.x2go.org after work today.
On 08.03.2015 05:07 PM, Michael DePaulo wrote:
I will import it to code.x2go.org after work today.
Please don't. I'll do it based on your github archive, then, whenever I get home at "night".
I still need to change a few scripts and make them available for git repo creation.
Mihai
On Mar 8, 2015 12:17 PM, "Mihai Moldovan" <ionic@ionic.de> wrote:
On 08.03.2015 05:07 PM, Michael DePaulo wrote:
I will import it to code.x2go.org after work today.
Please don't. I'll do it based on your github archive, then, whenever I get home at "night".
I still need to change a few scripts and make them available for git repo creation.
Mihai
Ack.
On 08.03.2015 05:25 PM, Michael DePaulo wrote:
On Mar 8, 2015 12:17 PM, "Mihai Moldovan" <ionic@ionic.de <mailto:ionic@ionic.de>> wrote:
I'll do it based on your github archive, then, whenever I get home at "night".
Ack.
Your repository has been successfully imported. You can check it out with the usual commands.
Overview: http://code.x2go.org/gitweb?p=vcxsrv.git;a=summary
Please note that the branch names were adapted as discussed on IRC. You should probably change them accordingly on github, too, to prevent confusion and mishaps.
Mihai
-
Henning Heinold -
Michael DePaulo -
Mihai Moldovan -
Mike Gabriel