remote-help-assistant team mailing list archive

[Andrew Sayers <andrew-bugs.launchpad.net@xxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I suppose I should have talked about the plan first - after days of
trying things that didn't work, I was so glad to find a plausible
solution that I didn't think to consult.

Essentially, the problem is that there are two distinct use cases for
the assistant: sharing your desktop, and helping someone who shares
their desktop.  Both use cases have the same technological requirements,
but slightly different packaging and UI requirements.  For example,
sharers' packages should require a VNC server to be installed, whereas
helpers' packages should require an SSH server to be installed.

To address those different use cases, there are now three branches of
development:

* trunk - this is where most actual development should go on
* helper - minor tweaks to trunk, optimising for helpers
* sharer - minor tweaks to trunk, optimising for sharers

Currently, the only difference is that the "helper" branch creates a
.deb that depends on openssh-server, the "sharer" branch creates a .deb
that depends on x11vnc | krfb | vino, and the trunk creates a branch
that doesn't depend on either.  I would quite like to alter the "helper"
branch to make page 2 default to "connect", but that's as far as I plan
to have the branches diverge.

So to be clear, all the branches currently have, and I expect always
will have, exactly the same functionality.

http://www.pileofstuff.org/remote-help-assistant/ tries to present the
choices in a way that novices will find easy to understand, but I'm not
happy with it yet, and will probably play around with it a bit in the
coming days.  I'll ask on the list again before linking to it from the
"external downloads" link on https://launchpad.net/remote-help-assistant

To answer your question, you should continue to pull the "trunk" branch,
because that's where interesting development work will go on.  You're
welcome to pull the other branches as well, but I don't expect that much
of interest will happen in them.  I've just pushed trunk revision 84
now, so I'm not sure why you were being told it already existed before.

	- Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJmKmGGRQTxegE/G4RAlfMAJ9m7LbeBV+VldyN4l8Y//M+VwlY6gCcD12D
r/4Dq9zHouIY0zVBPEu5Gw8=
=RX4c
-----END PGP SIGNATURE-----