Inclusion of MXit plugin into Pidgin

[Pieter Loubser]

Hi,


Thank you for all the feedback.


As mentioned before we are fully committed to maintain and support the
plugin.

As asked below we have followed the development guidelines for Pidgin
listed on the wiki. We have based our plugin on the other plugins to
maintain the same look and feel. The plugin code can be downloaded from
here http://devzone.mxit.com/libPurple/download/2/ to check for any
problems including earthworm hunting.

Concerning the AES functionality we agree that it make sense to move it
to the cipher support in purple.

The popup mentioned on a separate mail in this thread which sometimes
displays at login is used for communication from MXit to MXit users, and
is required to comply with the MXit usage license which we would prefer
to stay in line with to avoid hassles.

If you are happy with the code, please let me know what is the next step
to load it into monotone.


Thank you,

Pieter



On Wed, 2009-08-05 at 20:08 +0200, Mark Doliner wrote:
> On Tue, Aug 4, 2009 at 9:50 PM, John Bailey<rekkanoryo at rekkanoryo.org> wrote:
> > Kevin Stange wrote:
> >> I am generally in favor of doing this, provided you're willing to
> >> subscribe some of your support team to our "support" mailing list and
> >> field questions about the mxit plugin and help us expand documentation
> >> on our wiki to include login and usage help.  Presence in our IRC
> >> channel and on other lists would be welcome as well.
> >
> > Yes, this would be a great first step toward including the plugin in Pidgin.
> > Getting involved in the community and helping us to support the plugin will
> > greatly smooth the bumps in the road.
> 
> I'm in favor of this with a few assumptions.  In addition to what
> Kevin mentioned above:
> 
> * I don't think any of us have experience with MXit, and we would
> expect you to maintain the plugin.  That means we'd give you access to
> our version control system (we're using Monotone) and you could check
> things in, fix bugs, add features, etc.
> 
> * You would have to follow our design guidelines
> (http://developer.pidgin.im/wiki/DesignGuidelines )
> 
> * We should probably look over your existing code and make sure we're
> comfortable with it.  Like, make sure it doesn't scan the user's hard
> drive for pictures of earthworms, or link against any crazy libraries,
> or break the user's expectations, or have buffer overflows, or crash
> on the 76th second of every Tuesday
> 
> >> It's certainly not my decision to set you up with commit access, but I
> >> would think having you work on your development in a mxit monotone
> >> branch, which we occasionally propagate to our primary branch for
> >> "release ready" code would be reasonable.  This is how we handle the
> >> OpenQ project for QQ support as well.  Other developers should chime in
> >> with opinions. :)
> >
> > I know I've objected to including more prpls before, particularly the Facebook
> > Chat plugin, but in this case I have no preference one way or the other.  If we
> > are to accept the plugin into our tree, I agree that it should be handled in
> > much the same way that we handle the QQ plugin--have a team that works on a
> > separate branch that can be merged back to im.pidgin.pidgin at release-ready points.
> >
> > Also, as a side note, we can't do this for 2.6.0 as we're already in string
> > freeze.  If it's decided we want to have the plugin in-tree, it will have to be
> > for 2.6.1 or some future version.
> 
> I don't feel like a separate branch is necessary, but I have no
> objections to it if that's what people want.
> 
> -Mark


#####################################################################################
MXit Lifestyle (Pty) Ltd - Join The Evolution
Scanned by MailMarshal - Marshal's comprehensive email content security solution. 

#####################################################################################