Yann Leboulanger asterix@lagaule.org wrote:
Jonathan Schleifer a écrit :
Here's a mail where OpenBSD states why they won't commit 0.12 into their ports tree.
Thanks for the news.
So much for "This is not a issue for users not using GPRS", Yann.
This is not a personal attack, no, of course.
It's not. It's just that I want to show you that it's not true that this is only affecting GPRS users.
We need to release 0.12.1, and we need to do that ASAP!
your a dev, as me, and I don't really see your commits to fix the problem you caused : http://www.lagaule.org/pipermail/translators/2008-December/000271.html
I committed it to trunk, like always. And I told you that I do that and asked you to backport it to 0.12. Plus, I'm not on the translators list, as I can't subscribe, which I also already told you.
I don't see your commits to implement what has been discussed in the jabber room: http://www.gajim.org/muc_logs/gajim@conference.gajim.org/2008/12/18.html#22:...
Not solving the problem, but only making the user aware of it.
Why not send a blank space every 55 sec to avoid routers closing idle connections? That would also detect if our connection is dead, thanks to TCP/IP. And that's what one really understands when talking about keep alive. What we do is ping, not keep alive.
I'm not saying it's your job more than mine or the job of any dev, of course, just that it's a free software, we all have many other things to do, and that putting presure on others is not a good thing.
I'm not saying to release as it is, but that we need to find a solution, test that and release a 0.12.1 ASAP.
have nice end of year parties
You too :).
As it's not possiblt to have private mail, let's continue here.
Jonathan Schleifer wrote:
Yann Leboulanger asterix@lagaule.org wrote:
Jonathan Schleifer a écrit :
It's not. It's just that I want to show you that it's not true that this is only affecting GPRS users.
thousands of people uses svn version and have no problem, it's why I still thing xmpp ping is a good thing. You can look in trac, some people are disappointed because they send a message, and have no answer. They have to wait 10 minutes at least to know they are disconnected. Gajim is a *instant* messager. Having to wait 10 minutes to know we are no more connected is not an option in my opinion.
I committed it to trunk, like always. And I told you that I do that and asked you to backport it to 0.12. Plus, I'm not on the translators list, as I can't subscribe, which I also already told you.
translations was for 0.12. I didn't see why it was for trunk. And I don't know when you told me to commit it to 0.12 branch, nor why you can't do that. As you cannot be in translators mailling list, I'll maintership to someone who can receive and review patches from other translators.
Why not send a blank space every 55 sec to avoid routers closing idle connections? That would also detect if our connection is dead, thanks to TCP/IP. And that's what one really understands when talking about keep alive. What we do is ping, not keep alive.
See my comments above. Having to wait 10 minutes for an *instant* messager is not an option in my opinion.
I'm not saying to release as it is, but that we need to find a solution, test that and release a 0.12.1 ASAP.
Sure we have to find a solution. But that can (and will IMO) take a long time ...
Yann Leboulanger asterix@lagaule.org wrote:
As it's not possiblt to have private mail, let's continue here.
Jonathan Schleifer wrote:
Yann Leboulanger asterix@lagaule.org wrote:
Jonathan Schleifer a écrit :
It's not. It's just that I want to show you that it's not true that this is only affecting GPRS users.
thousands of people uses svn version and have no problem, it's why I still thing xmpp ping is a good thing.
Who also complained about frequent disconnects, yes.
You can look in trac, some people are disappointed because they send a message, and have no answer. They have to wait 10 minutes at least to know they are disconnected. Gajim is a *instant* messager. Having to wait 10 minutes to know we are no more connected is not an option in my opinion.
And ping would help there how? Gajim would disconnect and can't reconnect, as the connection is dead. If the connection wouldn't be dead, TCP/IP would have fixed that already. If TCP/IP couldn't recover the connection and it hangs, reconnecting won't work. The only case where a reconnect might work is if TCP/IP interrupts the connection.
I committed it to trunk, like always. And I told you that I do that and asked you to backport it to 0.12. Plus, I'm not on the translators list, as I can't subscribe, which I also already told you.
translations was for 0.12. I didn't see why it was for trunk.
Because the translator based on trunk and also translated the XHTML stuff etc.
And I don't know when you told me to commit it to 0.12 branch, nor why you can't do that.
I don't backport changes to 0.12, you do. Noone except you committed to the 0.12 branch at all. Everybody always committed to trunk and you backported it. Why should that be different now?
As you cannot be in translators mailling list, I'll maintership to someone who can receive and review patches from other translators.
You could just manually subscribe me…
Why not send a blank space every 55 sec to avoid routers closing idle connections? That would also detect if our connection is dead, thanks to TCP/IP. And that's what one really understands when talking about keep alive. What we do is ping, not keep alive.
See my comments above. Having to wait 10 minutes for an *instant* messager is not an option in my opinion.
You don't have to wait for 10 minutes. Either the connection can be recovered and lags for a time, in which case a reconnect would fail, or TCP/IP disconnects you, in which you can reconnect and it might succeed again. But when a TCP/IP connection is dead, a reconnect won't work either. So where's the point?
Plus, it's not 10 minutes. It's only a long time if we don't send anything. But sending anything doesn't mean we need to send a ping. We can send a space, that's enough. If the TCP/IP connection has an error, TCP/IP will close it on the next send. So we send a space and detect that the connection isn't working anymore. No need to XMPP ping.
Sure we have to find a solution. But that can (and will IMO) take a long time ...
There's no need for it to take a long time. Why not just send a space every 55 sec and let TCP/IP handle it for us? You always compare having no keep alive at all to having XMPP ping. Why not compare XMPP ping to having a keep alive the normal way, which is sending a space? That *WILL* force TCP/IP to close the connection if it's dead.
I really wonder why every other client and all servers are fine with just sending a space and why we are not… And I wonder why nobody complained about dead connections not being detected by them… (Again: No keep alive is something completely different than sending a space. With no keep alive, it might really take 10 minutes)
Guys,
releasing after so much time means a lot of pressure. Since all guys here want the best for Gajim I think that (a) there is no need to argue so much about stuff, just let it be for a while and a .1 will come and fix regressions and (b) let everyone take some days off relax and see what's the feedback then about 0.12. Afterall noone is /forced/ to update.
Next major release should be Gajim 1.0
On Fri, Dec 19, 2008 at 19:39, Jonathan Schleifer js-gajim@webkeks.orgwrote:
Yann Leboulanger asterix@lagaule.org wrote:
As it's not possiblt to have private mail, let's continue here.
Jonathan Schleifer wrote:
Yann Leboulanger asterix@lagaule.org wrote:
Jonathan Schleifer a écrit :
It's not. It's just that I want to show you that it's not true that this is only affecting GPRS users.
thousands of people uses svn version and have no problem, it's why I still thing xmpp ping is a good thing.
Who also complained about frequent disconnects, yes.
You can look in trac, some people are disappointed because they send a message, and have no answer. They have to wait 10 minutes at least to know they are disconnected. Gajim is a *instant* messager. Having to wait 10 minutes to know we are no more connected is not an option in my opinion.
And ping would help there how? Gajim would disconnect and can't reconnect, as the connection is dead. If the connection wouldn't be dead, TCP/IP would have fixed that already. If TCP/IP couldn't recover the connection and it hangs, reconnecting won't work. The only case where a reconnect might work is if TCP/IP interrupts the connection.
I committed it to trunk, like always. And I told you that I do that and asked you to backport it to 0.12. Plus, I'm not on the translators list, as I can't subscribe, which I also already told you.
translations was for 0.12. I didn't see why it was for trunk.
Because the translator based on trunk and also translated the XHTML stuff etc.
And I don't know when you told me to commit it to 0.12 branch, nor why you can't do that.
I don't backport changes to 0.12, you do. Noone except you committed to the 0.12 branch at all. Everybody always committed to trunk and you backported it. Why should that be different now?
As you cannot be in translators mailling list, I'll maintership to someone who can receive and review patches from other translators.
You could just manually subscribe me…
Why not send a blank space every 55 sec to avoid routers closing idle connections? That would also detect if our connection is dead, thanks to TCP/IP. And that's what one really understands when talking about keep alive. What we do is ping, not keep alive.
See my comments above. Having to wait 10 minutes for an *instant* messager is not an option in my opinion.
You don't have to wait for 10 minutes. Either the connection can be recovered and lags for a time, in which case a reconnect would fail, or TCP/IP disconnects you, in which you can reconnect and it might succeed again. But when a TCP/IP connection is dead, a reconnect won't work either. So where's the point?
Plus, it's not 10 minutes. It's only a long time if we don't send anything. But sending anything doesn't mean we need to send a ping. We can send a space, that's enough. If the TCP/IP connection has an error, TCP/IP will close it on the next send. So we send a space and detect that the connection isn't working anymore. No need to XMPP ping.
Sure we have to find a solution. But that can (and will IMO) take a long time ...
There's no need for it to take a long time. Why not just send a space every 55 sec and let TCP/IP handle it for us? You always compare having no keep alive at all to having XMPP ping. Why not compare XMPP ping to having a keep alive the normal way, which is sending a space? That *WILL* force TCP/IP to close the connection if it's dead.
I really wonder why every other client and all servers are fine with just sending a space and why we are not… And I wonder why nobody complained about dead connections not being detected by them… (Again: No keep alive is something completely different than sending a space. With no keep alive, it might really take 10 minutes)
-- Jonathan
Gajim-devel mailing list Gajim-devel@gajim.org http://lists.gajim.org/cgi-bin/listinfo/gajim-devel
I won't put oil on fire, just to tell that after private dicussion, there is indeed a problem with TCP timout, it lasts more than 10 minutes.
So tests are needed to improve that. But 0.12.1 should be released before that to fix filetransfer I think.
Any objection to release 0.12.1 now?
Am 21.12.2008 um 11:42 schrieb Yann Leboulanger:
I won't put oil on fire, just to tell that after private dicussion, there is indeed a problem with TCP timout, it lasts more than 10 minutes.
That is because Gajim doesn't call setsockopt().
So tests are needed to improve that. But 0.12.1 should be released before that to fix filetransfer I think.
Well, I have a fix for the timeout problem I guess. I'll outline it here:
• Use setsockopt() to enable TCP/IP keepalives. We can even adjust the time for those with setsockopt(). • Change the behaviour from sending pings every keep_alive_foo_secs to sending a space every keep_alive_foo_secs. • Keep the value for keep_alive_every_foo_secs at 55, so we send a space every 55 sec to prevent disconnection. • Remove time_for_keep_alive_answer. • Try if this is already enough - which is very likely, but if not: • Introduce ping_every_foo_secs and time_for_ping_reply with *SANE* values. Sane means much higher than the keepalives. Like every 120 sec a ping which needs to be answered in 60 sec.
Any objection to release 0.12.1 now?
Yes. Fixing file transfers is not as important as fixing stability issues IMO. Fixing the stability isssues should be our top priority atm.
What do you think about this: We implement those changes I suggest above and try if that fixes the issue. I'm pretty sure it will.
I think releasing a 0.12.1 without a fix for the stability issues will disappoint and upset our users a lot, as some were mad enough to change clients already (seems Psi is very popular among those). If we release a 0.12.1 without that fix, I fear many users will think we're unable to fix it and move to another client.
-- Jonathan
Jonathan Schleifer wrote:
Am 21.12.2008 um 11:42 schrieb Yann Leboulanger:
I won't put oil on fire, just to tell that after private dicussion, there is indeed a problem with TCP timout, it lasts more than 10 minutes.
That is because Gajim doesn't call setsockopt().
So tests are needed to improve that. But 0.12.1 should be released before that to fix filetransfer I think.
Well, I have a fix for the timeout problem I guess. I'll outline it here:
• Use setsockopt() to enable TCP/IP keepalives. We can even adjust the time for those with setsockopt(). • Change the behaviour from sending pings every keep_alive_foo_secs to sending a space every keep_alive_foo_secs. • Keep the value for keep_alive_every_foo_secs at 55, so we send a space every 55 sec to prevent disconnection. • Remove time_for_keep_alive_answer. • Try if this is already enough - which is very likely, but if not: • Introduce ping_every_foo_secs and time_for_ping_reply with *SANE* values. Sane means much higher than the keepalives. Like every 120 sec a ping which needs to be answered in 60 sec.
Any objection to release 0.12.1 now?
Yes. Fixing file transfers is not as important as fixing stability issues IMO. Fixing the stability isssues should be our top priority atm.
What do you think about this: We implement those changes I suggest above and try if that fixes the issue. I'm pretty sure it will.
I think releasing a 0.12.1 without a fix for the stability issues will disappoint and upset our users a lot, as some were mad enough to change clients already (seems Psi is very popular among those). If we release a 0.12.1 without that fix, I fear many users will think we're unable to fix it and move to another client.
-- Jonathan
You think more people are affected by this 30s timeout than by filetranfer? Really? I think more people use FT than are on a slow connection.
And I don't see the problem to release 0.12.1 now and 0.12.2 as soon as all those things are implemented and tested, which is not likely to happen before some weeks.
Am 21.12.2008 um 12:07 schrieb Yann Leboulanger:
You think more people are affected by this 30s timeout than by filetranfer? Really? I think more people use FT than are on a slow connection.
Yes, definitely. You don't send files all the time. Besides, which problem with file transfers? I haven't seen any yet. Everybody could send me files and receive them so far.
And please, stop saying that only a few people are affected by this and only those with a slow connection, because it's just not true. I got people with 16 MBit connection in my roster who get disconnected all the time etc. And half of those who updated to 0.12 have already complained to me, and all I could tell them was that it's not my fault and I was against relasing it like that.
And I don't see the problem to release 0.12.1 now and 0.12.2 as soon as all those things are implemented and tested, which is not likely to happen before some weeks.
"Hmm, I get disconnected all the time, maybe I should update to 0.12.1. No, doesn't seem to fix it. Seems like they can't get it fixed in the near future, so I'll change the client."
I already was asked "How could you release a 0.12 like that? And how can I be sure that 0.12.1 will not introduce other, even nastier bugs? I think I'm going to change the client". If we release a 0.12.1 that still has the bug, we lose the users' trust. Our 0.12.1 must be rock- solid, otherwise we'll use many users, I fear. We already lost enough users, I think (I know of some who didn't want to go back to 0.11.4 and for which disconnects were so unacceptable that they changed to Psi).
-- Jonathan
Jonathan Schleifer wrote:
Am 21.12.2008 um 12:07 schrieb Yann Leboulanger:
You think more people are affected by this 30s timeout than by filetranfer? Really? I think more people use FT than are on a slow connection.
Yes, definitely. You don't send files all the time. Besides, which problem with file transfers? I haven't seen any yet. Everybody could send me files and receive them so far.
I think you should read ticket, and test 0.12 branch. There is a missing import so sending file is just not possible.
And please, stop saying that only a few people are affected by this and only those with a slow connection, because it's just not true. I got people with 16 MBit connection in my roster who get disconnected all the time etc. And half of those who updated to 0.12 have already complained to me, and all I could tell them was that it's not my fault and I was against relasing it like that.
I say that because I got just 0 complaint for this problem except from you, no ticket, nothing in private mail, nothing in room (though I'm not always in front of my computer), and because svn is tested by a lot of users and none complain since it's implemented (11 monthes). I'm not saying we should not improve that, just that more people use filetransfer (already 3 tickets open for that in 2 days)
And I don't see the problem to release 0.12.1 now and 0.12.2 as soon as all those things are implemented and tested, which is not likely to happen before some weeks.
"Hmm, I get disconnected all the time, maybe I should update to 0.12.1. No, doesn't seem to fix it. Seems like they can't get it fixed in the near future, so I'll change the client."
I already was asked "How could you release a 0.12 like that? And how can I be sure that 0.12.1 will not introduce other, even nastier bugs? I think I'm going to change the client". If we release a 0.12.1 that still has the bug, we lose the users' trust. Our 0.12.1 must be rock-solid, otherwise we'll use many users, I fear. We already lost enough users, I think (I know of some who didn't want to go back to 0.11.4 and for which disconnects were so unacceptable that they changed to Psi).
My goal is not to have as much user as possible, but to have as much happy user as possible, and fixing filetransfer will make them more happy than if I say : "no no wait some weeks, we have another bug and we cannot release before it's fixed".
Am 21.12.2008 um 12:36 schrieb Yann Leboulanger:
I think you should read ticket, and test 0.12 branch. There is a missing import so sending file is just not possible.
Hm, maybe they're using trunk then. I'll have a look.
And please, stop saying that only a few people are affected by this and only those with a slow connection, because it's just not true. I got people with 16 MBit connection in my roster who get disconnected all the time etc. And half of those who updated to 0.12 have already complained to me, and all I could tell them was that it's not my fault and I was against relasing it like that.
I say that because I got just 0 complaint for this problem except from you, no ticket, nothing in private mail, nothing in room (though I'm not always in front of my computer), and because svn is tested by a lot of users and none complain since it's implemented (11 monthes). I'm not saying we should not improve that, just that more people use filetransfer (already 3 tickets open for that in 2 days)
That's strange, as it was even discussed in the MUC and reported there. You were even highlighted, IIRC. And I got lots of complaints in query, even in a social network in the Gajim group were a lot of them and I had to explain how to disable keepalives and all said it works much more stable since they disabled it.
If you like, I could forward you some. Many users don't seem to use the bug tracker, but complain to developers. When you tell them "File a ticket", you usually get only a "later" for an answer.
My goal is not to have as much user as possible, but to have as much happy user as possible, and fixing filetransfer will make them more happy than if I say : "no no wait some weeks, we have another bug and we cannot release before it's fixed".
If my proposed fix doesn't work, we can still release a 0.12.1 without a fix for the timeout. But first, I think we should try the proposed fix.
PS: Could we have a Reply-To:? I was used to just always add gajim-devel@gajim.org to the To: as it's never there, but as you saw lately, that can cause quite some confusion (private mail answered publically because of that habit etc.)
-- Jonathan
Jonathan Schleifer wrote:
Am 21.12.2008 um 12:36 schrieb Yann Leboulanger:
I think you should read ticket, and test 0.12 branch. There is a missing import so sending file is just not possible.
Hm, maybe they're using trunk then. I'll have a look.
in trunk ping timout is still 20seconds. So don't talk about 0.12 when the users you talk about use trunk ...
That's strange, as it was even discussed in the MUC and reported there. You were even highlighted, IIRC. And I got lots of complaints in query, even in a social network in the Gajim group were a lot of them and I had to explain how to disable keepalives and all said it works much more stable since they disabled it.
If you like, I could forward you some. Many users don't seem to use the bug tracker, but complain to developers. When you tell them "File a ticket", you usually get only a "later" for an answer.
If one dev get all complaints and don't forward them to bug tracker, I don't see how we could go forward ...
If my proposed fix doesn't work, we can still release a 0.12.1 without a fix for the timeout. But first, I think we should try the proposed fix.
Have you time to do that with christmas and new year time? I don't. But that should not prevent a bugfix release for FT.
PS: Could we have a Reply-To:? I was used to just always add gajim-devel@gajim.org to the To: as it's never there, but as you saw lately, that can cause quite some confusion (private mail answered publically because of that habit etc.)
Don't you have a reply to all or reply to list button in your mailer? Setting a reply to is most of the time considered as a bad idea: http://www.unicom.com/pw/reply-to-harmful.html And that fore sure won't help you to reply in private is by default it goes to the list !
Am 21.12.2008 um 12:53 schrieb Yann Leboulanger:
If one dev get all complaints and don't forward them to bug tracker, I don't see how we could go forward ...
I told you I got bug reports, but you always insisted that only I got the bug and the bug reports I received were bogus.
Have you time to do that with christmas and new year time? I don't. But that should not prevent a bugfix release for FT.
I could do that on 25C3, I guess.
Don't you have a reply to all or reply to list button in your mailer? Setting a reply to is most of the time considered as a bad idea: http://www.unicom.com/pw/reply-to-harmful.html And that fore sure won't help you to reply in private is by default it goes to the list !
Well, if you send me a mail in private, I won't have the Reply-To, so I will reply in private, whereas if it's from the ML, it will have a Reply-To and go back to the ML. That's how for example the XMPP MLs handle it as well :).
-- Jonathan
Jonathan Schleifer wrote:
I told you I got bug reports, but you always insisted that only I got the bug and the bug reports I received were bogus.
That's not another personal attack, no, of course. That said, I don't remeber having said that, and that doesn't prevent you to fix that.
Have you time to do that with christmas and new year time? I don't. But that should not prevent a bugfix release for FT.
I could do that on 25C3, I guess.
25c3? what's that?
Yann Leboulanger asterix@lagaule.org wrote:
That's not another personal attack, no, of course.
How is stating that you said a personal attack?
That said, I don't remeber having said that, and that doesn't prevent you to fix that.
You did it in the mail before. You said you only have heard from me about the problem, that I had bug reports from others is something you ignored.
25c3? what's that?
Jonathan Schleifer wrote:
That said, I don't remeber having said that, and that doesn't prevent you to fix that.
You did it in the mail before. You said you only have heard from me about the problem, that I had bug reports from others is something you ignored.
Where is it said that "[I] always insisted that only [you] got the bug and the bug reports [you] received were bogus." I never said you didn't got any complaints, just that *I* never got. And I never talked about the bugreports you got ... But maybe I don't speak english weel enough for you to understand.
25c3? what's that?
I don't need a URL, I asked you for a date.
Ok I'll release 0.12.1 with filetransfer fix and 0.12.2 as soon as your tests will be conclusive. Release more often if a good thing.
Am 21.12.2008 um 14:16 schrieb Yann Leboulanger:
Where is it said that "[I] always insisted that only [you] got the bug and the bug reports [you] received were bogus." I never said you didn't got any complaints, just that *I* never got. And I never talked about the bugreports you got ... But maybe I don't speak english weel enough for you to understand.
Sorry, then I got it wrong. Sounded to me like you think that this issue exists only for me, although I forwarded a bug report from OpenBSD etc.
25c3? what's that?
I don't need a URL, I asked you for a date.
Ah, so you want to know when it is and not what :). 27.12. - 30.12.
Ok I'll release 0.12.1 with filetransfer fix and 0.12.2 as soon as your tests will be conclusive. Release more often if a good thing.
Well, you definitely take a point with release often. But let's call it 0.12.0.1, ok? And announce that a fix for the disconnections is being investigated.
-- Jonathan
Jonathan Schleifer wrote:
Well, you definitely take a point with release often. But let's call it 0.12.0.1, ok? And announce that a fix for the disconnections is being investigated.
release name with 4 numbers are for svn. What's the problem with 0.12.1, it's a bugfix release, as 0.12.2 will be and 0.12.*
On 2008-12-21, 11:43 GMT, Jonathan Schleifer wrote:
PS: Could we have a Reply-To:? I was used to just always add gajim-devel@gajim.org to the To: as it's never there, but as you saw lately, that can cause quite some confusion (private mail answered publically because of that habit etc.)
Get a mail client which complies with RFC 2369 -- just from the top my head -- Thunderbird does with https://addons.mozilla.org/en-US/thunderbird/addon/4455
Matěj
Am 22.12.2008 um 00:12 schrieb Matej Cepl:
Get a mail client which complies with RFC 2369 -- just from the top my head -- Thunderbird does with https://addons.mozilla.org/en-US/thunderbird/addon/4455
This is not an option as I use different MUAs. Claws-Mail seems to handle it like expected, while Apple Mail doesn't. Thunderbird's too bloated IMO, especially on OS X where it feels slow and non-native (even worse than Gtk, so I'd even compile Claws-Mail for OS X Gtk before I'd use Thunderbird). Maybe there's a plugin for Mail.app as well?
-- Jonathan
On 2008-12-22, 01:28 GMT, Jonathan Schleifer wrote:
This is not an option as I use different MUAs. Claws-Mail seems to handle it like expected, while Apple Mail doesn't. Thunderbird's too bloated IMO, especially on OS X where it feels slow and non-native (even worse than Gtk, so I'd even compile Claws-Mail for OS X Gtk before I'd use Thunderbird). Maybe there's a plugin for Mail.app as well?
Sorry, no clue -- I am spoiled from Linux and haven't really used anything else seriously for many years.
Matěj
-
Jonathan Schleifer -
Matej Cepl -
Nikos Kouremenos -
Yann Leboulanger