Am 10.09.2013 19:48, schrieb subh...@hushmail.com:
Hello Tamme,
So far I like your approach. I've never heard of py2exe before,
but you seem to have done your research WRT the options for using
Python in Windows. If py2exe is good enough for BitTorrent, then
it's good enough for me.
Hello,
I have to look a bit more into the different options before we can
decide on the Python version. From what I've seen it should be possible
to get a reasonable distributable size with either though. I think I
would prefer the plain "include parts of Python" option, as that should
work without additional dependencies for the build. I really need to
look into build automation, with C# VS does everything and it "just
works". Maybe someone else reading this can help here.
BTW: before getting started on otr-dev:
1) How would you feel about releasing it under, say GPL v2
licensing? That would be my first choice.
It depends on whether that allows closed-source messengers to use the
service. I know both Pidgin and Gajim are GPL'd, but Trillian for
example isn't and as such can't be distributed with the GPLv2 OTR
plugin. It would be better to allow all clients to offer compatibility
as core feature.
I agree with dkg on the forward-compatibility, we should definitely
include the ", or (at your option) any later version" part.
I think we should use LGPLv2+ or LGPLv3+.
2) It sounds like you would like to develop in Windows first. I
would also propose that Debian stable (or testing or unstable, only
if necessary) be the primary Linux distro to develop in first
(trying to proceed in parallel with a Windows implementation),
taking the time necessary to keep the core functionality
installable and working in both OS's (before adding any bells-and-
whistles features).
I especially suggest Debian, because today's most popular Linux
distros (Linux Mint, *buntu, Elementary OS, etc) are downstream
from Debian. IMHO, the best hope for this project, would be that
an official Debian Developer would eventually come along (which I'm
not), and help this software become a proper Debian package,
eventually making its way into Debian main, with all the necessary
dependencies getting sorted out along the way. Eventually, it
would be great if all OTR-computible IM's would have this proposed
package as a dependancy (and not just a "recommendation", which
IMHO would be very naiive in today's computer security climate)!
Debian also ranks as a top recommendation on https://prism-
break.org/ , as being trustworthy amidst all the Big News in the
computer security world, which I'm sure you're also following.
That sounds like the best way to get started. I don't have a Debian
system at the moment but setting up a VM should be no problem. Testing
my commits there should be possible but I'm not sure if I can develop
against the system API.
I can perhaps offer a bit of help as time allows, and lots of Linux
expertise. I'll have to think over my current commitments before
making any promises. I've done some small-time coding of one-off
system-adminstration-related Python scripts (usually not more than
a hundred lines of code, which can accomplish quite alot), but I
have little familiarity with modern version control systems and
software packaging (you know, making .debs, unofficial APT
repositories, etc). I've never been a professional coder. I've
worked with many coders in past jobs. I do have a B.Sc. in
computer science, and 5 yrs experience as primarily a Unix/Linux
Sysadmin (with some Windows admin experience too). I have an eye
to make things low-maintenance, simpler when possible, and easy to
backup and restore.
I've only worked as Java developer for a short time before starting at
university (mostly unrelated field), but I've written a lot more code in
C# as private projects (a persistent dictionary, some network code, some
scheduling and graphics, lots of file IO, and a ton of unfinished
projects). I'd have to properly learn Python before starting which
should take a week or two.
I use Mercurial, but Git should be fine too. I prefer the former because
it's more convenient and has much better Windows integration (I prefer
GUI over CLI if I have the choice). No packaging experience here either,
everything I wrote so far didn't need to be installed.
No professional qualifications for me, I'd say I'm at a point where I
could do well in most coding jobs though. I know a good amount of
relatively low-level Windows, but not the C(++) API.
I tend to write modular code (my projects are split into reusable
binaries that have their own subrepos if there's a logical abstraction
layer), but not to the point where everything has an interface. I often
start with the "highest" layer and then implement the more low-level
parts as needed.
Unfortunately my free time varies a lot due to university, at the moment
I have a lot, but it will be less when the semester starts. It should be
enough to contribute on a regular basis.
Are there any other python geeks, Debian geeks, or Debian
Maintainers out there?
If you agree that this sounds sensible, then I'll see you on otr-
dev.
How does "OTR key storage" as topic sound? The service probably should
handle both known public-key-contact associations and private keys for
the user's identities as programs using one feature will most likely
also use the other.
I look forward to contributing here, it looks like an interesting
challenge that I hope will make encryption more accessible.
-Tamme
_______________________________________________
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
