KDE PIM/Meetings/Osnabrueck 2/Release Planning IRC Meeting Protocol

On Sunday we had an kdepim IRC meeting, mainly to discuss the separate kdepim release. This is the log of the meeting:

[10:21:45] cornelius has changed the topic on channel #kontact to "kdepim IRC Meeting"
[10:22:31] <Beineri> mahoutsukai: in the kdepim 3.3 release?
[10:22:58] <bo> beineri: No, must be done for 3.2
[10:23:10] <bo> If it's going to happen
[10:23:13] <marc> bo: I think so, too
[10:23:39] <Beineri> that would have to be suggested rather soon
[10:23:50] danimo just noticed KNode has no dcop interface when running as KPart, thus Kontact doesn't have a "New Article" action (opps)
[10:23:59] <bo> I did suggest it almost a year ago, but coolo wouldn't hear of it
[10:24:13] <sanders_> bo: did coolo say why?
[10:24:18] <bo> The reason for me suggesting it was to be able to run kdepim without kdebase
[10:24:18] <sanders_> i remember that discussion.
[10:24:43] <bo> I wanted the smtp slave in libs, and he feels libs are to big (which I don't take as a valid reason)
[10:25:18] <bo> The imap and pop slaves can be used by konqueror, so it must remain in base (and that's an even more lame reason)
[10:25:23] danimo just found a recommended patch
[10:25:23] <marc> bo: smtp isn't needed in libs anyway. We could move that one, too.
[10:25:32] <bo> marc: No
[10:25:37] <marc> bo: why not?
[10:25:42] <sanders_> soemthing uses it other than kmail?
[10:25:55] <marc> I don't think so.
[10:25:58] <Beineri> marc: isn't it used by "Report Bug..."?
[10:25:59] <bo> smtp is used for sending error reports for example
[10:26:05] <marc> The bug email interface surely doesn't.
[10:26:12] <marc> += need it.
[10:27:17] <marc> See kdelibs/kio/misc/ksendbugmail...
[10:27:32] <marc> has it's own smtp.cpp..
[10:28:19] <mahoutsukai> marc: hmm, then we have been misinformed and there shouldn't be a reason to also move it to kdepim.
[10:28:45] <srhaque> well, in that case, someone should write to kde-core-devel asking if there are reasons NOT to move them
[10:28:52] <srhaque> (for 3.2)
[10:28:54] <cornelius> We should propose the move of the kioslaves on kde-core-devel today.
[10:28:56] <mahoutsukai> marc: correction "not to move it"
[10:29:07] <bo> Lots of apps can send email, and having the smtp slave available for it is nice
[10:29:20] <bo> For imap and pop, I see no such reason
[10:29:32] <bo> Well, unless you want to write a kmail replacement
[10:29:36] <srhaque> bo: I agree, receivers only
[10:29:47] <bo> (I think that was another reason on coolos side)
[10:29:59] <cornelius> So the proposal is to move the pop and imap slaves to kdepim and the smtp slave to kdelibs?
[10:29:59] <srhaque> if required, smtp can come later :-)
[10:30:04] <bo> Yes
[10:30:07] <mahoutsukai> bo: so what? It's the packagers job to put the smtp slave in an installable package of it's own if it's needed.
[10:30:29] <srhaque> mahoutsukai: its not needed to have that argument right now.
[10:30:50] <srhaque> mahoutsukai: it is much more important for us to move pop and imap, th4e discussion will just get bogged down
[10:30:57] <cornelius> As fallback, if there are objections about moving smtp to kdelibs we could move smtp to kdepim?
[10:31:03] <mahoutsukai> srhaque: sure
[10:31:28] <srhaque> cornelius: I say just leave it. we have mere days before the release.
[10:31:41] <bo> There was an idea to make a kioslaves toplevel module, but that's just silly since it would be just as necessary as kdelibs
[10:31:43] <srhaque> cornelius: and smtp is probably the most stable right?
[10:32:16] <srhaque> cornelius: or rather "least in need of change"
[10:32:21] <bo> srhaque: The problem is our 3.3 release where we will release kdepim alone. This means that we really need control of all things that are supposed to be in kdepim
[10:32:35] <bo> And moving a dir of a slave is not a bug producing problem
[10:32:50] reinhold ([email protected]) has joined channel #kontact
[10:32:56] <sanders_> bo: have you considered including the ioslaves in the separate release if necessary?
[10:33:00] <bo> Good morning reinhold :-)
[10:33:06] <srhaque> bo: I understand the rationale, all I am saying is if it is going to cause a big discussion, we can leave smtp for now
[10:33:37] <bo> sanders_: Yes, but that is bad since we would have both an imap (for example) slave from base and from pim
[10:33:41] <sanders_> bo: i mean even if the move of the slaves out of kdebase isn't successful.
[10:33:42] <marc> bo, srhaque: and I probably want ot work more on the smtp slave, so I'd really like it in kdepim...
[10:33:51] <srhaque> bo: there is no difference in leaving it in kdebase or kdelibs, only if we get to move it to kdepim
[10:34:09] <[ade]> mogges
[10:34:17] <marc> ^^ that at least is correct
[10:34:41] <bo> srhaque: Not correct. If these three slaves are moved, kdepim will run without depending on kdebase being installed
[10:34:57] dfaure would prefer smtp in kdepim than in kdelibs (I don't see why it would need to be there)
[10:35:01] <reinhold> bo:morning
[10:35:13] <srhaque> bo: but if there arguments from the rest of the community that "xyz also needs smtp"?
[10:35:34] <marc> srhaque: define "xyz" before we go any further.
[10:35:39] <dfaure> bo: kdebase not installed means: no help system, no way to choose your language+country, etc.
[10:35:57] <dfaure> it's not really realistic, except for hardcore USA users :)
[10:35:57] <bo> srhaque: I agree - which is why I proposed smtp in libs and pop and imap in pim
[10:36:01] <srhaque> bo: some 3rd party application? Or the CDDB part of kscd etc. etc.
[10:36:55] <mahoutsukai> srhaque: As I wrote above, it doesn't matter. It's the packagers responsibility.
[10:37:01] <srhaque> ok, how about this. Propose to move imap and pop, and ask for reasons NOT to move smtp
[10:37:08] <Beineri> dfaure: no kcmshell for kalaram/kontact/korganizer :-)
[10:37:10] <srhaque> mahoutsukai: yes, but it is a pain already
[10:37:30] <srhaque> but if we do so, we will have toport at least all in-cvs users
[10:37:32] <dfaure> Beineri: ?? Those are accessible from the apps themselves, aren't they?
[10:38:27] <marc> srhaque: what porting could be invloved in apps when moving kioslaves around between modules?
[10:38:38] <Beineri> dfaure: didn't try, just grepped for "kcmshell" in kdepim/
[10:38:57] <marc> srhaque: there's not compile-time dependency at all when using slaves
[10:39:37] <cornelius> dfaure: the reason to move the iosaves is not because of run-time dependencies, but to be able to release an updated ioslave with a kdepim-only release.
[10:40:03] <bo> And because imap and pop really belong in pim
[10:40:18] <dfaure> cornelius: I know, I know. I'm only countering the vapour idea of "kdepim without kdebase" like bo emitted.
[10:40:34] <dfaure> but I agree with moving them, for development purposes
[10:41:36] <bo> I think the biggest reason against moving would be if someone runs KDE without pim and with another email client
[10:41:41] <srhaque> marc: ah,thanks, I did not know that
[10:41:51] <srhaque> bo: I simply don't care about that
[10:42:00] <bo> By moving pop and imap to pim, we say pim must always be installed
[10:42:40] bradh ([email protected]) has joined channel #kontact
[10:42:41] <bo> Of course, distros are free to split pim in pim and pim-ioslaves
[10:43:08] <srhaque> bo: especially if we make it simple for them
[10:43:39] <srhaque> bo: but I think it kind of defeats the purpose
[10:44:00] <agungl> If you use a distro like SuSE, there are lots of rpms for kdepim or even kdebase. You can combine what you want. For those users it's nt relevant where the source resides - like Ingo already has said.
[10:44:05] <bo> srhaque: Yes
[10:44:38] <dfaure> if we all agree about the moving I suggest to appoint someone for a post and to move on to another subject :)
[10:45:18] <dfaure> Beineri: you are correct, there's a runtime dependency on kcmshell. One more point for kdebase needed :)
[10:45:54] <Beineri> What about the HTML mail key feature? Sorry, I'm not up-to-date - does Komposer rely on KTextEditor interfaces (if yes, is the interface sufficient as in 3.2?) or can it only optionally make use of it?
[10:45:58] <cornelius> ok, I will write a mial to kde-core-devel proposing to move the imap and pop slaves to kdepim and asking what people think about also moving smtp to kdepim.
[10:46:33] <bernhard> cornelius: sounds good.
[10:46:45] <marc> cornelius: I'd word it more like "anyone has any reasons against moving smtp, too"?
[10:48:07] <cornelius> marc: ok
[10:48:35] <marc> cornelius: thx
[10:48:41] <sanders_> Beineri: html editing doesn't depend on the komposer, the patch JES and I worked on just needs some bug fixes and it should be ready to submit to the list for consideration to commit (IMO)
[10:49:33] <mahoutsukai> Beineri: Komposer is no key feature. So if Zack didn't make sure it works with current kdelibs it's no problem for us. It will just not be part of the separate release. But I'm pretty sure that Zack made sure that there won't be a problem.
[10:49:41] <cornelius> I commited the list of planned features to developer.kde.org/development-versions/kdepim-features.xml. Feel free to add missing information.
[10:50:52] <mahoutsukai> Beineri: I'm much more concerned about ksyntaxhighlighter etc. because it's impossible (or at least not easy) to make even simple improvements for the separate release.
[10:50:56] <cornelius> Is there anyone willing to add the corresponding kdepim-3.3-features.html?
[10:50:58] <bradh> marc: is there any API that allows sending emails without KMail? For example, does kbugbuster use SMTP? If so, SMTP might need to stay in a more central place
[10:51:17] <cornelius> bradh: KBugBuster uses the KMail DCOP interface.
[10:51:27] <mahoutsukai> Beineri: Komposer is completely orthogonal to HTML composing.
[10:52:40] <Beineri> mahoutsukai: Ok, mixed it up obviously. :-)
[10:53:17] <marc> bradh: look at kdelibs/kio/misc/ksendbugmail
[10:53:24] <till> sanders: Is there anything else apart from html composing and imap filtering you intend to work on, for 3.3?
[10:53:30] Signoff: [ade] (saberhagen.freenode.net irc.freenode.net)
[10:53:58] <mahoutsukai> bradh: People that install kbugbuster (from kdesdk) won't have a problem with also installing kioslaves/smtp from the kdepim package.
[10:54:02] [ade] ([email protected]) has joined channel #kontact
[10:54:05] <Beineri> Another problem while I see Tobias increasing the Kontact plugin version once more, what happens to kdeaddons/plugins/newsticker? Will the 3.2 version not work anymore with kdepim-3.3?
[10:54:06] <sanders_> till: a few things
[10:54:31] zecke ([email protected]) has joined channel #kontact
[10:55:05] <mahoutsukai> Beineri: That's a valid concern. I guess the plugin version has to stay stable for the separate release.
[10:55:23] <sanders_> till: can I write an email about that?
[10:55:26] <bradh> mahoutsukai: I was more thinking about the API, rather than the users. For example webservices normally runs over HTTP, but SMTP is often also quoted.
[10:55:54] <mahoutsukai> bradh: Which API? It's a kioslave. There's no API.
[10:56:41] <bradh> mahoutsukai: My original question was whether there was such an API.
[10:57:50] <zecke> cornelius: hi
[10:57:50] bradh is [email protected] (Kopete User)
[10:57:50] on channels: #kontact #kde-devel
[10:57:50] on IRC via server irc.freenode.net (http://freenode.net/)
[10:57:50] bradh has been 1 minutes and 8 seconds idle
[10:57:57] <dfaure> bradh: kioslaves are used through the generic KIO API.
[10:57:57] <sanders_> till: i'm kinda taking it easy at the moment, so I suspect time might slip by pretty quick and I won't commit much new code. rather complete html editing, and switch on the actionscheduler.
[10:57:59] <till> sanders: sure
[10:58:02] <cornelius> zecke: hi
[10:58:21] <sanders_> till: or help this JES guy with html editing if he has problems.
[10:58:22] <till> sanders: I was just wondering if you want us to put anything else on teh release plan.
[10:59:06] <zecke> cornelius: sorry I'm late but my coltis makes problems...
[10:59:45] <Beineri> Why is the newsticker plugin in kdeaddons at all? Don't you like it? Did you think that it would blow kdepim? :-) This/the optional summary could be a big point for Kontact now that Evolution is removing it.
[11:00:10] <sanders_> till: nah, it's ok, there's some pop things I want to work on like leave mail on server for x days before deleting, and asynchronous filtering for pop retrieval and normal sending, but I'd rather keep these off the list and eliminate any pressure for me to get them done quickly.
[11:00:45] <sanders_> till: multipart/related support also, just something I can experiment if I have time.
[11:00:56] <zecke> cornelius: is there a way when running in Kontact to get to know the used Resources?
[11:01:44] <zecke> cornelius: and could you comment on my mail complaining mixing SYNC and ASYNC loading in one resource?
[11:02:21] <till> sanders: cool.
[11:03:24] <mahoutsukai> bradh: Well, there's no compile-time dependency (e.g. no header files which need to be included). But of course the user needs to know how to pass some options to the smtp slave.
[11:03:46] <cornelius> zecke: knowing what resources from where?
[11:04:36] <sanders_> till: The main thing i'm focusing on currently is this commercial improvement system which is intended to be a database backed php website that allows users to encourage contributors to work on specific features, i can send an email about that if you like.
[11:04:48] <mahoutsukai> Beineri: The newsticker plugin has compile-time dependencies on knewsticker which is in kdenetwork.
[11:04:50] <cornelius> zecke: about the sync/async thing, Tobias should probably comment on this. He has written this code. In libkcal we do it differently, there is only one api for both sync and async.
[11:06:23] <mahoutsukai> Beineri: So the newsticker plugin had to be put into kdeaddons. (or knewsticker would have to be moved to kdepim)
[11:06:29] <zecke> cornelius: For syncing I would like to differentiate from running within kontact and external application
[11:06:34] <cornelius> I just send the mail about the slaves to kde-core-devel.
[11:06:43] <Beineri> mahoutsukai: I see. :-|
[11:07:03] <zecke> cornelius: first of all I would like to introduce pairing. Konnector to Konnector with parts
[11:07:29] <tokoe> cornelius: well, maby we should remove the whole resource stuff ;)
[11:07:40] <zecke> cornelius: for within kontact it should create a 'dynamic' sync part which uses the resources used by Addressbook and Korg
[11:08:17] <zecke> tokoe: I don't like that a KABC Resource needs to implement both interfaces. Synchronous and Asynchronous
[11:08:28] <tokoe> zecke: yes, i read your mail
[11:08:50] <tokoe> zecke: do you have an idea how to implement it in a sane way?
[11:10:45] <cornelius> zecke: I see, we probably should discuss this separately. I intend to mainly focus on KitchenSync for the next weeks.
[11:11:29] <zecke> tokoe: first ASYNC Resource API is the default base and then inherit a SyncInterface which implements the the async one which calls virtual functions
[11:11:44] <zecke> cornelius: yeah ok
[11:11:58] <cornelius> To come back to the purpose of this meeting: Are there any general comments about the release plan or any objections or are you all happy with it?
[11:12:22] <sanders_> cornelius: no objections here.
[11:12:27] <srhaque> cornelius: I cannot see it on the web URL you gave
[11:12:44] <srhaque> http://developer.kde.org/development-versions/kdepim-features.html
[11:12:45] <zecke> I'm fine with it
[11:12:57] <tokoe> zecke: you mean the sync iface should use the async iface internally?
[11:13:04] <agungl> I've a question regarding the status of Kandy. Is it usable? Are improvements planed or on the way?
[11:13:04] <glick> kdepim rules
[11:13:24] <srhaque> tokoe: yes, this is standard technique for such stuff
[11:13:25] <Beineri> srhaque: There isn't an html yet.
[11:13:49] <srhaque> Beineri: then what is the name again?
[11:14:10] <tokoe> zecke: is it what you mean with 'inherit' or do you mean real c++ inheritance?
[11:14:21] <cornelius> agungl: My intention is to integrate Kandy into KitchenSync and then fix the problems it has, but I probably won't be able to do this before the kdepim-3.3 release.
[11:14:23] <mahoutsukai> srhaque: It's in the cvs module developer.kde.org in the subdir development-versions.
[11:14:26] <zecke> tokoe: real OOP
[11:14:31] <Beineri> srhaque: .xml - but even that hasn't synced to http://developer.kde.org yet.
[11:14:33] <srhaque> mahoutsukai: ah. thanks.
[11:14:53] <agungl> cornelius: So it's basically the 2.x version plus some fixes in 3.2?
[11:14:59] <till> sanders: Sure, please mail me.
[11:15:10] <cornelius> agungl: It works ok with some Siemens phones (at least with all phones I have;-)
[11:15:17] <zecke> tokoe: Yeah Sync Should be an implementation detail. To KABC all resources would look ASYNC and could be treated like this
[11:15:45] <zecke> tokoe: the one that are not yet ASYNC can use the Sync Resource wrapper
[11:15:47] <agungl> cornelius: I can't get it to work with my Si35, but I don't bother...
[11:16:20] <tokoe> zecke: well, let's what i can do for 3.3/4.0
[11:16:45] <zecke> tokoe: the pros are: You don't need to implement two interfaces on the other hand I do not know how it interferes with the rest of KABC
[11:16:59] <zecke> tokoe: SYNC is a blocking case of ASYNC ;)
[11:17:56] <tokoe> zecke: it should work fine
[11:18:44] <sanders_> till: for the ghost messages in the outbox problem i am wondering if it makes sense to delay deletion of maildir messages until compaction of the index is performed.
[11:19:52] <cornelius> As everybody seems to be happy with the release planning, I think, we can now finish the official part of the meeting. Thanks to everybody for participating.
[11:19:55] <sanders_> i mean deletion of the maildir message file.
[11:20:17] <cornelius> Is it ok with all of you, if we put the log of the meeting on the pim.kde.org webpage?
[11:21:25] <bo> cornelius: Of course
[11:21:38] <[ade]> yup
[11:21:40] <glick> sanders_, you develop kmail?
[11:21:55] <marc> cornelius: yes
[11:22:12] <agungl> cornelius: no objections from my side
[11:22:40] <sanders_> cornelius: ok
[11:23:02] <sanders_> glick: yes.
[11:23:17] <glick> cool
[11:23:22] Signoff: srhaque ("using sirc version 2.211+KSIRC/1.3.9")
[11:23:50] <glick> sanders_, i have a quick question, whats the diff between using the crypt plugins and using the builtin crypt?
[11:24:34] <Beineri> mahoutsukai: There is no compile-time dependency of the newsticker plugin on knewsticker. Only a run-time on dcoprss?
[11:24:38] <till> sanders: Hm, how would that help?
[11:24:45] cornelius has changed the topic on channel #kontact to "back to bugfixing: still 486 kontact bugs left (framework+components)"