On Sat, May 21, 2011 at 20:43:18 (CEST), Mike Gabriel wrote:
Hi Reinhard,
We have to distinguish current code bases properly:
code.x2go.org -> X2go upstream (currently containing sort of upstream NX'ish code forks, which is a non-optimal redundancy now that NoMachine has brought up some recent work of NX again)
collab-maint on Alioth -> package preparation for Debian (pkg-x2go-devel team)
Launchpad.net/~x2go -> build engine for Ubuntu (provided by X2go upstream) packages.x2go.org -> build engine for Debian (provided by X2go upstream)
On Sa 21 Mai 2011 17:13:33 CEST Reinhard Tartler wrote:
o drop nxcomp (and later nxcompext, nxcompshad) from code.x2go.org (X2go upstream), same with nxproxy (the code is not a real fork...)
What problem would that solve? AFAIUI this step would break the PPA and leave users of released versions of ubuntu in the cold
As discussed on pkg-x2go-devel, for Debian the Debian maintainers of X2go will have to use NoMachine as upstream for nxlibs + nxproxy. So, there is no point of hosting NX code on code.x2go.org.
For the X2go Launchpad PPA (build engine) I would then draw in the code from collab-maint Git (instead of drawing in the code base from code.x2go.org / X2go Git).
But that's exactly my point, there is really no need for breaking the current setup before we have a something that can replace it. And now you propose to move the current known-to-work branches to something that doesn't even exist yet.
IOW: Go ahead and do whatever you want to do on alioth. When it's ready, we can reconsider if it's worth moving there, but currently, I really don't see any benefit in breaking the current infrastructure. And for Stéphane's work, well, what's the problem with integrating it in the *current* infrastructure on code.x2go.org?
o provide X2go-specific patches for NX 3.5 upstream on X2go upstream that are recommended to be incorporated by package maintainers
did you already look at those 'patches'?
This might be a misunderstanding.
No, it's not. Please have a look at them.
[...]
o draw Stéphanes work to collab-maint on Alioth
Why not on code.x2go.org?
Because code.x2go.or is intended for X2go upstream development. Not for building Debian packages.
I don't know what to say here, I'm speechless.
On Alioth's collab-maint workspace all Debian developers have write access by default. That's my main reason for hosting the packaging code there.
Still, so far you have found exactly one DD (i.e., me) willing to work on x2go upstream. Just granting access to everybody is unlikely to improve the situation.
-- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4