[pkg-lua-devel] Intent to upload prosody_0.8.2-1~bpo60+1, dh-lua_13~bpo60+1 and lua-ldap_1.1.0-1-geeac494-3~bpo60+1

[Matthew Wild]

On 9 May 2012 11:37, Luca Capello <luca at pca.it> wrote:
> On Tue, 08 May 2012 22:33:42 +0200, Matthew Wild wrote:
>> Another reason not to include them is that we work hard to keep
>> Prosody upgrades trivial. A config file from ~0.2 (Dec 2008) will
>> still work in Prosody 0.9 (coming) without change.
>
> May I play the devil here?  This is not true for Cyrus SASL
> authentication, there are changes between 0.7 and 0.8:
>
>  <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670549#35>
>
> OK, just kidding, the above is *documented* upstream (which is what is
> important to me), so everything is fine:
>
>  <http://prosody.im/doc/cyrus_sasl>

You absolutely may. I really thought this wasn't the case, but
apparently you are right. Luckily 0.2 didn't support Cyrus, so my
original statement still stands :P

So sasl_backend was an oversight, that at least I saw no-one complain
about during the release process, otherwise I would have fixed it.
There are other similar options, such as anonymous_login (which has
changed to authentication = "anonymous") that we have compatibility
code for.

>> Our upgrade-safety
>> includes things in prosody-modules. Having a significant portion of
>> users running code outside our control would make us cry.
>
> The problem I see here is that there *are* already users running code
> outside of your control:
>

If your point is about LDAP, yes. However the issue is not as simple
as Stefan's mod_auth_ldap going "over a year without review". It *was*
reviewed, the problem was that it worked differently to the one in
prosody-modules. There are apparently multiple schools of thought
around how to do LDAP "correctly", and they don't seem to agree. I
know because I discussed it in depth at the time.

The simplest solution to me seemed to wait until I had more time to
find a resolution, and (more importantly) more feedback on each
module. This is why I added the note to the documentation on
prosody-modules, so we could get feedback on both of them.

One problem is that I am not an "LDAP person", and all the LDAP people
I speak to have very strong, and different, opinions. I have yet to
review Rob's latest LDAP plugins properly. They seem very good quality
code-wise (as expected, Rob is an experienced Lua developer). His
plugins are also more extensive. It's quite likely we'll be moving
those to prosody-modules, and eventually supply them with Prosody when
they are proven stable. I have already told Rob that I plan to work on
this after the release when I have more time.

As for people running code that is beyond our control - I'm absolutely
fine with that. But most important is that we have no obligation to
maintain compatibility with such code. If the Prosody Debian package
comes supplied with unofficial LDAP modules that are incompatible with
official modules that are later released, that *is* of concern to me.

> Please note that I wanted to contact prosody-dev before any other email,
> while merging Stefan's and Rob's work into my local prosody-modules,
> minimizing the changes and also providing tests (which I did anyway,
> extensively if I may).  The fact that prosody-dev is on Google Groups
> and it seems it requires a Google account simply refrained me to do that
> (no Google here, sorry).

That is not the case, you can use any address - I certainly wouldn't
use any mailing list host that required otherwise! It's possible that
Google don't make this so clear when viewing the list there, but on
our site you can easily subscribe and unsubscribe any email address,
see http://prosody.im/discuss

We also don't require Google accounts for push access to
prosody-modules. Just email me privately as usual if you want access
and say you don't have a Google account.

If I didn't believe in a free, open and decentralized internet I
probably wouldn't pour over half my life into XMPP work :)

Regards,
Matthew

PS. But Google *is* very convenient... ;)