While thinking about testability I also wondered about what we shall do with code that is not just a little bit buggy but worse.
Think of a house that was once nice and tidy and is now totally rotten. A window was smashed and nobody repaired it. It is the same with code and we have to fix broken windows when they occur.
A broken window is everything that nobody understands, doesn't work properly or simply is implemented in a very ugly fashion.
I propose to remove such code for now and to come back on it in a later release cycle (maybe as a plugin). Of course this is not always possible but we should really consider it, IMHO.
When I look at gajim, I see the following broken windows: - OSX integration - OTR-Encryption - GPG-Encryption
Nobody should feel accused or attacked, it is not meant personally but I only want you all think about what we have at the moment and what we really want or what our goals should be.
And hey, never forget, I smashed the biggest window - the roster....
What do you think?
Best, steve
Stephan Erb steve-e@h3c.de wrote:
When I look at gajim, I see the following broken windows:
- OSX integration
It's totally broken and I'm for reverting it and doing it from scratch.
- OTR-Encryption
We can keep that in trunk and just remove the line that loads the OTR module before release. It's possible that we get it fixed, but I really doubt it,
- GPG-Encryption
What's broken about GPG? Never had any issues with it.
But you forgot the biggest breakage: Session centric. Since the merge of session centric, nearly nothing works correctly anymore. I often have 5 chat tabs with one person, random crashes, etc. If we keep session centric in, I don't expect a release before 2009. There is still so much to fix. bct sure did a lot of great work here, but it looks to me that this is just too complex. And I don't see any advantage we get from it, besides tictactoe which isn't even a XEP and will never get one because it uses messages instead of iq, since there is no other client supporting it yet - and I guess for good reasons.
On Sun, May 25, 2008 at 12:55:07PM +0200, Jonathan Schleifer wrote:
I often have 5 chat tabs with one person,
That should be fixed since r9695.
And I don't see any advantage we get from it, besides tictactoe
(In my opinion) Gajim needs some refactoring. gajim.py and common/connection_handlers.py in particular are massive chunks of code with little structure.
Moving message handling into the session object seemed like a good way to start. It's a relatively small refactor that simplified both those files and also makes it easy to add new kinds of message handlers without having to hard-code them into those files. Tic-tac-toe is just a proof of concept, many more interesting things are possible.
If we keep session centric in, I don't expect a release before 2009.
I think you're being a bit overdramatic. I don't want to fight with you about this, js :(
imHo Gajim should release a good version this summer else it's likely it will lose users to other clients. And that means no refactoring it just means Release early, release often
On Mon, May 26, 2008 at 12:23 AM, Brendan Taylor whateley@gmail.com wrote:
On Sun, May 25, 2008 at 12:55:07PM +0200, Jonathan Schleifer wrote:
I often have 5 chat tabs with one person,
That should be fixed since r9695.
And I don't see any advantage we get from it, besides tictactoe
(In my opinion) Gajim needs some refactoring. gajim.py and common/connection_handlers.py in particular are massive chunks of code with little structure.
Moving message handling into the session object seemed like a good way to start. It's a relatively small refactor that simplified both those files and also makes it easy to add new kinds of message handlers without having to hard-code them into those files. Tic-tac-toe is just a proof of concept, many more interesting things are possible.
If we keep session centric in, I don't expect a release before 2009.
I think you're being a bit overdramatic. I don't want to fight with you about this, js :(
Gajim-devel mailing list Gajim-devel@gajim.org https://lists.gajim.org/cgi-bin/listinfo/gajim-devel
Am 26.05.2008 um 10:42 schrieb Nikos Kouremenos:
imHo Gajim should release a good version this summer else it's likely it will lose users to other clients. And that means no refactoring it just means Release early, release often
IMO, a buggy release is far more worse than an old release. When the users consider a client buggy, they'll change more likely than they will if there's just no new release. Stability is far more important that adding new features.
-- Jonathan
Jonathan Schleifer js-gajim@webkeks.org a écrit :
Am 26.05.2008 um 10:42 schrieb Nikos Kouremenos:
imHo Gajim should release a good version this summer else it's likely it will lose users to other clients. And that means no refactoring it just means Release early, release often
IMO, a buggy release is far more worse than an old release. When the users consider a client buggy, they'll change more likely than they will if there's just no new release. Stability is far more important that adding new features.
Of course nobody want a buggy release ! It's why we shoud definitly stop adding new features and focus on fixing everything. Main problems are in modelfilter, and OSX integration. That would be very nice if we could have a working OSX package ! But I can't help here, as I don't have such a machine.
Yann Le Boulanger asterix@lagaule.org wrote:
problems are in modelfilter, and OSX integration. That would be very nice if we could have a working OSX package ! But I can't help here, as I don't have such a machine.
Believe me, we definitely don't want OS X support for 0.12. It's so buggy, we will be flooded by bug reports of OS X users. There's no way we can include that in 0.12, sorry. That's maybe something for the 0.13 roadmap.
Maybe Gajim needs to attract some attention from the Mac Open Source community and get some help on that?
On Tue, May 27, 2008 at 5:43 PM, Jonathan Schleifer js-gajim@webkeks.org wrote:
Yann Le Boulanger asterix@lagaule.org wrote:
problems are in modelfilter, and OSX integration. That would be very nice if we could have a working OSX package ! But I can't help here, as I don't have such a machine.
Believe me, we definitely don't want OS X support for 0.12. It's so buggy, we will be flooded by bug reports of OS X users. There's no way we can include that in 0.12, sorry. That's maybe something for the 0.13 roadmap.
-- Jonathan
Gajim-devel mailing list Gajim-devel@gajim.org https://lists.gajim.org/cgi-bin/listinfo/gajim-devel
On 05/27/2008 10:05 AM, Nikos Kouremenos wrote:
Maybe Gajim needs to attract some attention from the Mac Open Source community and get some help on that?
I'm happy to test. :)
Peter
test yes it's one important thing. but I was thinking more like attracting a dev or at least an occasional patcher. else ok you find bug, but who will try to fix it and test it and close the ticket if noone from the devs cannot test on the platform?
IOW, Gajim needs *marketing* in the Mac floss devs.
On Tue, May 27, 2008 at 7:09 PM, Peter Saint-Andre stpeter@stpeter.im wrote:
On 05/27/2008 10:05 AM, Nikos Kouremenos wrote:
Maybe Gajim needs to attract some attention from the Mac Open Source community and get some help on that?
I'm happy to test. :)
Peter
-- Peter Saint-Andre https://stpeter.im/
"Nikos Kouremenos" kourem@gmail.com wrote:
test yes it's one important thing. but I was thinking more like attracting a dev or at least an occasional patcher. else ok you find bug, but who will try to fix it and test it and close the ticket if noone from the devs cannot test on the platform?
Well, I can test, I have an iBook with OS X on it. This is also where I tested Gajim on OS X the last time and deemed it unusable. It's already on my TODO do get it working there, though I start to like Adium. :) But Adium isn't very handy when it comes to server administration, which I need, so sooner or later, I will port Gajim to OS X.
On Mon, 2008-05-26 at 11:42 +0300, Nikos Kouremenos wrote:
imHo Gajim should release a good version this summer else it's likely it will lose users to other clients. And that means no refactoring it just means Release early, release often
Release early, release often... We are already beyond that point.
But we are aware that we must release ASAP. This means that started things need to be finished and new features must not be worked on. (That is why I disagreed merging otr)
We should decide know what needs to be done and what can be dropped. Finishing all is impossible regarding our very limited spare time. (:-/)
Kind Regards, Steve
I am of the opinion that we should remove code from gajim if we know that it is not fully functional.
Removing should be preferred over disabling it because we can never be sure that there aren't any uncaught side effects. It may also happen that some user enable it and report bugs in other areas (yes, code is that coupled) and we are unable to easily reproduce it.
After removal the patches could be applied to separate branches. Users who really want it can use it and we make sure that the patch doesn't get lost.
On Sun, 2008-05-25 at 12:55 +0200, Jonathan Schleifer wrote:
Stephan Erb steve-e@h3c.de wrote:
When I look at gajim, I see the following broken windows:
- OSX integration
It's totally broken and I'm for reverting it and doing it from scratch.
See above.
- OTR-Encryption
We can keep that in trunk and just remove the line that loads the OTR module before release. It's possible that we get it fixed, but I really doubt it,
See explanation above.
- GPG-Encryption
What's broken about GPG? Never had any issues with it.
I was not precise enough here. It is working but the implementation is very complex, so no refactoring for 0.12 is planned.
But you forgot the biggest breakage: Session centric.
I am OK with session centric and think we should definitely keep it. Things are shaping up and I haven't seen any big breakage in the last days. (Even unit tests are coming).
Best Regards, steve-e
I'd suggest that we branch in about 1 months and only add fixes to that branch then. If we'd use Mercurial instead of SVN, things would be much easier :/. A decentral VCS would be better anyway.
Hallöchen!
Jonathan Schleifer writes:
I'd suggest that we branch in about 1 months and only add fixes to that branch then.
Any reason for waiting another month?
Tschö, Torsten.
Torsten Bronger bronger@physik.rwth-aachen.de wrote:
Any reason for waiting another month?
Yes, it's not very useful to branch when it's not in a usable state. ATM, we need too fix a lot to make it usable again, too much was changed at once, for example the roster, session-centric, etc.
Hallöchen!
Jonathan Schleifer writes:
Torsten Bronger bronger@physik.rwth-aachen.de wrote:
Any reason for waiting another month?
Yes, it's not very useful to branch when it's not in a usable state. ATM, we need too fix a lot to make it usable again, too much was changed at once, for example the roster, session-centric, etc.
I use the SVN version and it is, well, not perfect but usable for everyday use.
I think that the decision for a clean-up towards a release is the perfect moment for creating a release branch. If sensible/necessary, you can merge the fixes of it back into the trunk after all.
Tschö, Torsten.
Jonathan Schleifer wrote:
Torsten Bronger bronger@physik.rwth-aachen.de wrote:
Any reason for waiting another month?
Yes, it's not very useful to branch when it's not in a usable state. ATM, we need too fix a lot to make it usable again, too much was changed at once, for example the roster, session-centric, etc.
I don't see any problem for now with session-centric things. But I see some with modelfilter. The major annoying thing for mw is that collapsed groups auto-expand .. I don't know why, when ..
I have 2 busy weeks, then it must be more quiet for me.
no svn is more than fine. centralization is good for managing software such as Gajim. Gajim is not Mozilla nor Apache
also on branching some features and then let the users follow that branch: I used to say and I really hope it's still that way: Gajim is for you grandma
On Thu, May 29, 2008 at 7:50 PM, Jonathan Schleifer js-gajim@webkeks.org wrote:
I'd suggest that we branch in about 1 months and only add fixes to that branch then. If we'd use Mercurial instead of SVN, things would be much easier :/. A decentral VCS would be better anyway.
-- Jonathan
Gajim-devel mailing list Gajim-devel@gajim.org https://lists.gajim.org/cgi-bin/listinfo/gajim-devel
"Nikos Kouremenos" kourem@gmail.com wrote:
no svn is more than fine. centralization is good for managing software such as Gajim. Gajim is not Mozilla nor Apache
I *STRONGLY* disagree. Ever tried to work with SVN when you're in a train with your laptop, without any WLAN? You're screwed then. With mercurial, no problem at all. Just commit offline and push (and merge, if needed) when you come online again, no problem at all. With svn, you can't work offline. So, centralized VCS are *BAD*, *BAD* and *BAD*!
It's ok to disagree and let's not go off topic. ;P I like SVN because it pushes you to commit online. I don't like keep branches for a long time either. I like all in one place. it works better because of psycology reasons I think :)
On Thu, May 29, 2008 at 11:40 PM, Jonathan Schleifer js-gajim@webkeks.org wrote:
"Nikos Kouremenos" kourem@gmail.com wrote:
no svn is more than fine. centralization is good for managing software such as Gajim. Gajim is not Mozilla nor Apache
I *STRONGLY* disagree. Ever tried to work with SVN when you're in a train with your laptop, without any WLAN? You're screwed then. With mercurial, no problem at all. Just commit offline and push (and merge, if needed) when you come online again, no problem at all. With svn, you can't work offline. So, centralized VCS are *BAD*, *BAD* and *BAD*!
-- Jonathan
Gajim-devel mailing list Gajim-devel@gajim.org https://lists.gajim.org/cgi-bin/listinfo/gajim-devel
Hallöchen!
Jonathan Schleifer writes:
"Nikos Kouremenos" kourem@gmail.com wrote:
no svn is more than fine. centralization is good for managing software such as Gajim. Gajim is not Mozilla nor Apache
I *STRONGLY* disagree. Ever tried to work with SVN when you're in a train with your laptop, without any WLAN? You're screwed then. With mercurial, no problem at all. Just commit offline and push (and merge, if needed) when you come online again, no problem at all.
Most DVCS's allow for pulling from an SVN as well as pushing to it. And then, there is SVK.
Tschö, Torsten.
On Thu, 2008-05-29 at 23:27 +0300, Nikos Kouremenos wrote:
than fine. centralization is good for managing software such as Gajim. Gajim is not Mozilla nor Apache
Even with DVCS you maintain a centralized repo. It is just that merging and branching is much easier. IMHO it would make it easier for new people to come on board but lets discuss this some other time.
also on branching some features and then let the users follow that branch: I used to say and I really hope it's still that way: Gajim is for you grandma
My grandma won't notice when a buggy feature that she would have never used is gone. But there are more advanced users that will notice.
We must not scare them away by simply dropping a patch that was once in trunk. We must provide options.
On Thu, May 29, 2008 at 06:50:40PM +0200, Jonathan Schleifer wrote:
If we'd use Mercurial instead of SVN, things would be mucheasier :/. A decentral VCS would be better anyway.
I'm also a big DVCS fan. SVN makes branching (and merging) very painful.
I'm using (and liking) git-svn with Gajim, but ideally it would be DVCS from end-to-end.
Brendan Taylor whateley@gmail.com wrote:
I'm using (and liking) git-svn with Gajim, but ideally it would be DVCS from end-to-end.
Git wouldn't be so good for Gajim since it doesn't run on all platforms Gajim runs on (git lacks Windows support - yes, I know of Cygwin, but that doesn't count since it's a PITA to use Cygwin just for git). Mercurial would be ideal, it's even written in the same language as Gajim :)
On Fri, May 30, 2008 at 7:21 AM, Jonathan Schleifer js-gajim@webkeks.org wrote:
Brendan Taylor whateley@gmail.com wrote:
I'm using (and liking) git-svn with Gajim, but ideally it would be DVCS from end-to-end.
Git wouldn't be so good for Gajim since it doesn't run on all platforms Gajim runs on (git lacks Windows support - yes, I know of Cygwin, but that doesn't count since it's a PITA to use Cygwin just for git). Mercurial would be ideal, it's even written in the same language as Gajim :)
Have you tried msysgit? I haven't tried it myself as I'm not a regular user of Windows.
http://code.google.com/p/msysgit/
Jeff
"Jeffrey Ollie" jeff@ocjtech.us wrote:
Have you tried msysgit? I haven't tried it myself as I'm not a regular user of Windows.
Doesn't sound too comfortable either. For Mercurial, there's even TortoiseHg which is as comfortable as TortoiseSvn :). And working with terminal apps on Windows is always a PITA due to the sucky shell.
Since we change subject, ok let's discuss a bit more. I *hate* git. Mercurial is very nice (and in python; bazaar is also DVCS and in Python btw) but I'm not sure if Trac intergrates nicely with those two. and I'm a huge fan of TRAC.
http://trac.edgewall.org/wiki/TracMercurial is experimental.
https://launchpad.net/trac-bzr is far from complete.. (read as doesn't work)
and yea there is also Darcs etc. Maybe if trac mercurial goes stable but I still wouldn't vote for it because it will make it a lot harder to manage releases.
For more on PITA managing the team and releasing, consider reading http://blog.assembla.com/assemblablog/tabid/12618/bid/2569/Mercurial-Distrib...
That's all
On 5/30/08, Jonathan Schleifer js-gajim@webkeks.org wrote:
"Jeffrey Ollie" jeff@ocjtech.us wrote:
Have you tried msysgit? I haven't tried it myself as I'm not a regular user of Windows.
Doesn't sound too comfortable either. For Mercurial, there's even TortoiseHg which is as comfortable as TortoiseSvn :). And working with terminal apps on Windows is always a PITA due to the sucky shell.
-- Jonathan
Gajim-devel mailing list Gajim-devel@gajim.org https://lists.gajim.org/cgi-bin/listinfo/gajim-devel
Nikos Kouremenos wrote:
Since we change subject, ok let's discuss a bit more. I *hate* git.
Why?
On Fri, May 30, 2008 at 4:28 PM, Josef Kufner jk@myserver.cz wrote:
Nikos Kouremenos wrote:
Since we change subject, ok let's discuss a bit more. I *hate* git.
Why?
http://en.wikipedia.org/wiki/Git_(software)#Criticisms + I feel I had enough with Linus
"Nikos Kouremenos" kourem@gmail.com wrote:
http://trac.edgewall.org/wiki/TracMercurial is experimental.
Officially, it's experimental, but it works quite well.
Maybe if trac mercurial goes stable but I still wouldn't vote for it because it will make it a lot harder to manage releases.
No, releasing doesn't get harder, it's much easier for us at audacious now that we swithed to Mercurial.
We should schedule a meeting to discuss actions. We must decide on what to do, who does it and when it should be done.
Proposal: Wed. 11.07.2008 - 22:00 GMT.
Any objections?
On Thu, 2008-05-29 at 17:06 +0200, Stephan Erb wrote:
I am of the opinion that we should remove code from gajim if we know that it is not fully functional.
Removing should be preferred over disabling it because we can never be sure that there aren't any uncaught side effects. It may also happen that some user enable it and report bugs in other areas (yes, code is that coupled) and we are unable to easily reproduce it.
After removal the patches could be applied to separate branches. Users who really want it can use it and we make sure that the patch doesn't get lost.
On Sun, 2008-05-25 at 12:55 +0200, Jonathan Schleifer wrote:
Stephan Erb steve-e@h3c.de wrote:
When I look at gajim, I see the following broken windows:
- OSX integration
It's totally broken and I'm for reverting it and doing it from scratch.
See above.
- OTR-Encryption
We can keep that in trunk and just remove the line that loads the OTR module before release. It's possible that we get it fixed, but I really doubt it,
See explanation above.
- GPG-Encryption
What's broken about GPG? Never had any issues with it.
I was not precise enough here. It is working but the implementation is very complex, so no refactoring for 0.12 is planned.
But you forgot the biggest breakage: Session centric.
I am OK with session centric and think we should definitely keep it. Things are shaping up and I haven't seen any big breakage in the last days. (Even unit tests are coming).
Best Regards, steve-e
Gajim-devel mailing list Gajim-devel@gajim.org https://lists.gajim.org/cgi-bin/listinfo/gajim-devel
I should have better used a more common timezone.
Wed. 11.07.2008 20:00 UTC (22:00 CEST)
For those people like me see [1] :-)
Thanks js.
[1] http://www.timeanddate.com/worldclock/converter.html
On Thu, 2008-06-05 at 10:08 +0200, Stephan Erb wrote:
We should schedule a meeting to discuss actions. We must decide on what to do, who does it and when it should be done.
Proposal: Wed. 11.07.2008 - 22:00 GMT.
Any objections?
Well, you know that you moved the time now? Was that intended? 22 GMT is not 22 CEST :D.
On Thu, Jun 5, 2008 at 10:08 AM, Stephan Erb steve-e@h3c.de wrote:
We should schedule a meeting to discuss actions. We must decide on what to do, who does it and when it should be done.
Proposal: Wed. 11.07.2008 - 22:00 GMT.
Any objections?
Steve-e, you really mean 11th of July 2008? It's not Wednesday, it's Friday then. But 11th of June is Wednesday...
2008/6/6 Mateusz Biliński mateusz.bilinski@gmail.com:
On Thu, Jun 5, 2008 at 10:08 AM, Stephan Erb steve-e@h3c.de wrote:
We should schedule a meeting to discuss actions. We must decide on what to do, who does it and when it should be done.
Proposal: Wed. 11.07.2008 - 22:00 GMT.
Any objections?
Steve-e, you really mean 11th of July 2008? It's not Wednesday, it's Friday then. But 11th of June is Wednesday...
Here's reply from Steve-e:
--- From: Stephan Erb steve-e@h3c.de Subject: Re: [Gajim-devel] "Fixing Broken Windows" Date: Fri, 06 Jun 2008 08:31:47 +0200
Ahhhhh, well ....
Yes I meant June, and yes it was intended to move the time. But this is only a proposal, I just wanted to get things going. ---
Mateusz Biliński wrote:
2008/6/6 Mateusz Biliński mateusz.bilinski@gmail.com:
On Thu, Jun 5, 2008 at 10:08 AM, Stephan Erb steve-e@h3c.de wrote:
We should schedule a meeting to discuss actions. We must decide on what to do, who does it and when it should be done.
Proposal: Wed. 11.07.2008 - 22:00 GMT.
Any objections?
Steve-e, you really mean 11th of July 2008? It's not Wednesday, it's Friday then. But 11th of June is Wednesday...
Here's reply from Steve-e:
From: Stephan Erb steve-e@h3c.de Subject: Re: [Gajim-devel] "Fixing Broken Windows" Date: Fri, 06 Jun 2008 08:31:47 +0200
Ahhhhh, well ....
Yes I meant June, and yes it was intended to move the time. But this is only a proposal, I just wanted to get things going.
ok 11yh of June is ok for me, 8pm GMT, 10pm CET
-
Brendan Taylor -
Jeffrey Ollie -
Jonathan Schleifer -
Josef Kufner -
Mateusz Biliński -
Nikos Kouremenos -
Peter Saint-Andre -
Stephan Erb -
Torsten Bronger -
Yann Le Boulanger -
Yann Leboulanger