Jun 25 06:06 <srag> so, here we go :-)
Jun 25 06:06 <mbarnes> hope ya'll weren't waiting on me :)
Jun 25 06:07 <srag> mbarnes, we were ;-)
Jun 25 06:07 <srag> First the agenda and then the status.
Jun 25 06:07 <srag> so, I had a proposal to handle the dbus merge (kb and dbus-hybrid)
Jun 25 06:07 <srag> there were couple of options
Jun 25 06:08 <srag> 1, continue 2.26.x as stable till 3.0 and break and fix 2.27.x till 3.0
Jun 25 06:08 <seb128> --
Jun 25 06:08 <srag> 2. branch out 2.27.x right away and do the merge of dbus kill in the master
Jun 25 06:09 <srag> both has its pros and cons.. and I guess we need to decide fast on this and communicate iwth the release-team
Jun 25 06:10 <srag> the main reason, I brought this out is that,
Jun 25 06:10 <EvaSDK> before doing that I strongly suggest to look at what went wrong for gnome-session and gnome-power-manager debacle
Jun 25 06:10 <srag> k-b and dbus-hybrid are big stuff and may need more than a release cycle to stabilize
Jun 25 06:10 <seb128> is that about dbus or bonobo-slay or both?
Jun 25 06:10 <seb128> do you think you can get any of those stable for 2.28?
Jun 25 06:10 <srag> seb128, both. the eds-dbus and kill-bonobo
Jun 25 06:10 <seb128> you want to mix both transitions?
Jun 25 06:11 <srag> EvaSDK, sure. I need to look.
Jun 25 06:11 <srag> seb128, yep.
Jun 25 06:11 <srag> seb128, they should be fairly independent, interms of code/etc
Jun 25 06:11 <seb128> and you don't think you can't get any of those stable for 2.28?
Jun 25 06:12 <srag> seb128, I wont say that it will be rock solid.
Jun 25 06:12 <srag> we can make it work well.. but definietly not regression free or bug free.
Jun 25 06:12 <srag> I really want to avoid what happened with disk-summary branch..
Jun 25 06:12 <seb128> you aim to have those stable by 2.30 but you will rely only on unstable users feedback then
Jun 25 06:12 <srag> I really take that as a lesson, it took more than a 6month cycle to get better
Jun 25 06:13 <seb128> well having 2.28 a bit less stable would give you extra feedback
Jun 25 06:13 <seb128> you will not get real world feedback until those changes are pushed to users
Jun 25 06:13 <seb128> ie GNOME 2.30 == GNOME 3
Jun 25 06:13 <srag> seb128, I honestly want that feedback, but I know users might be pissed of if it gets breka for them, the I have 2.26, supported longer than ever
Jun 25 06:13 <seb128> they will be rather pissed if the GNOME 3 version is buggy
Jun 25 06:14 <srag> which is something I really really want to avoid.
Jun 25 06:14 <seb128> you will have to land an unstable version to users at some point to get this feedback and fix issues
Jun 25 06:14 <srag> taking this 9 month focussed cycle for evo/eds should help realy
Jun 25 06:14 <EvaSDK> in the meantime, 2.26 is still not perfectly stable with sqlite stuff
Jun 25 06:14 <srag> seb128, didn't get you
Jun 25 06:15 <seb128> well if you say you aim at landing all the change stable for 2.30
Jun 25 06:15 <mbarnes> fact of the matter is I doubt either branch will be ready for merging in time for 2.28
Jun 25 06:15 <seb128> when do you get the real world feedback before 2.30?
Jun 25 06:15 <jony> seb128: the developers will be running master (kill-bonobo and dbus-hybrid ) that should help spot most of the issues.
Jun 25 06:15 <seb128> I doubt that will
Jun 25 06:15 <seb128> experience show that developers only user part of the protocols, features, etc
Jun 25 06:15 <srag> seb128, , also, if you ship 2.27.x series, that surely gonna help
Jun 25 06:16 <seb128> srag, I'm not going to ship 2.27 if that will not be the 2.28 codebase
Jun 25 06:16 <seb128> I mean it's a chicken egg problem
Jun 25 06:16 <srag> hmm
Jun 25 06:16 <seb128> we want the next ubuntu version to use what GNOME 2.28 will use
Jun 25 06:16 <seb128> ie ship something usable to users
Jun 25 06:17 <EvaSDK> seb128: do you guys ship g-p-m-2.26 ?
Jun 25 06:17 <seb128> but it means the dbus and bonobo-slay will get no testing
Jun 25 06:17 <seb128> EvaSDK, yes with karmic, we didn't for jaunty (ie we had GNOME 2.26 and gpm 2.24)
Jun 25 06:17 <srag> if it doesn't get shipped then, its almost same as branching now..
Jun 25 06:17 <EvaSDK> ok, so do we
Jun 25 06:17 <seb128> "we" being?
Jun 25 06:17 <EvaSDK> gentoo
Jun 25 06:17 <seb128> ok
Jun 25 06:18 <seb128> srag, I appreciate that you will not manage to get those transitions for 2.28
Jun 25 06:18 <seb128> but that means you will not get the new codebase stable for GNOME 2.30
Jun 25 06:19 <srag> I think Im getting closer to the second approach
Jun 25 06:19 <seb128> I don't see something being stable without one cycle of bug fixing
Jun 25 06:19 <seb128> something with such magnitude of changes
Jun 25 06:19 <seb128> you need a drop to real world users to get proper feedback and work at least 6 months on that
Jun 25 06:19 <EvaSDK> I'm confident that eds-dbus could be done this cycle, but both seems it bit too much
Jun 25 06:20 <seb128> ie the evo hackers are probably having a specific workflow, most using imap and not pop for example
Jun 25 06:20 <seb128> which means pop will not get lot of testing until you install it for users out of the hacker team for example
Jun 25 06:20 <srag> seb128, perfect, devs can't replace real users any point.
Jun 25 06:20 <mbarnes> srag: as a fedora maintainer, I'm -strongly- in favor of the second approach, given that I've already packaged 2.27 releases for Fedora 12
Jun 25 06:20 <seb128> I've already packaged 2.27 for ubuntu too
Jun 25 06:21 <srag> cool.
Jun 25 06:21 <seb128> which means I'm in favor of anything which base 2.28 on the current 2.27.3 codebase
Jun 25 06:21 <srag> any other comments from any one else ?
Jun 25 06:21 <jony> nope. fine with this.
Jun 25 06:21 <seb128> and not using 2.26 for 2.28
Jun 25 06:21 <seb128> but that's orthogonal with trying to land the dbus switch for 2.28
Jun 25 06:21 <mbarnes> seb128: also, fwiw, I've been furiously cherry-pick changes from the kill-bonobo branch for 2.27 so it's gets early testing
Jun 25 06:21 <mcrha> how much time for a branch, approximately?
Jun 25 06:22 <srag> mcrha, meaning ?
Jun 25 06:22 <seb128> mbarnes, is there a gap to jump at some point or while you converge by incremental changes?
Jun 25 06:22 <mcrha> what do you mean "meaning"? :) I commit to master only, the new things, so how much time I have for some work I want to break caldav?
Jun 25 06:22 <lakhil> same with OpenSUSE factory also but i would go for 2.26.x , instead of shipping half cooked 2.27.x
Jun 25 06:23 <seb128> dunno how opensuse work but downgrading versions in ubuntu would not be easy
Jun 25 06:23 <mbarnes> seb128: yes, at some point I have to drop a nuke on the codebase, so to speak
Jun 25 06:23 <srag> mcrha, caldav should be a smaller task compared to others
Jun 25 06:23 <srag> mcrha, so you can work on trunk and back port or
Jun 25 06:23 <srag> do the other way also
Jun 25 06:23 <seb128> discussion seems to divert there
Jun 25 06:23 <seb128> I see several topics
Jun 25 06:23 <srag> seb128, Im not speaking about downgrading.. its tough in openSUSE also
Jun 25 06:24 <seb128> - whether 2.26 or 2.27.3 should be use to go to 2.28
Jun 25 06:24 <seb128> - when and where should land dbus and bonobo-slay
Jun 25 06:24 <mcrha> srag, sure, that's nothing with compere to both others, just that I rather like to commit to development branch than to stable
Jun 25 06:24 <seb128> it seems consensus is that whatever is in 2.27 now should be used to roll 2.28?
Jun 25 06:25 <srag> seb128, right. thatz where we are tending more towards
Jun 25 06:25 <seb128> then we can discuss when 2.29 open and where dbus and bonobo-slay land and when
Jun 25 06:25 <srag> branchout now.. and merge dbus ports to master
Jun 25 06:25 <seb128> there is no chance you can manage dbus switch to 2.28 you think?
Jun 25 06:25 <seb128> it's only a framework change it should not impact on user experience much
Jun 25 06:26 <srag> seb128, the e-d-s thing or the evolution-killbonobo ?
Jun 25 06:26 <seb128> e-d-s over dbus
Jun 25 06:27 <srag> e-d-s over dbus, the addressbook part is more or less complete
Jun 25 06:27 <srag> calendar needs good amount of work
Jun 25 06:27 <srag> ross, ?
Jun 25 06:27 <srag> I'm looking forward Chen to work close with ross and close that.
Jun 25 06:27 <srag> but one option we have is have eds use dbus for addressbook and bonobo for cal for now and fix calendar later...
Jun 25 06:28 <srag> iirc, chen wasn't in favour of that... I dont remember the reasons for htat
Jun 25 06:28 <srag> poor of my memory.
Jun 25 06:28 <seb128> using 2 mixed technologies seem suboptimal
Jun 25 06:29 <srag> seb128, but it should be totally independent
Jun 25 06:29 <srag> so, lemme try to conclude...
Jun 25 06:29 <srag> we gonna branch *soon*, <ok. not today/tomorrow>
Jun 25 06:30 <srag> once we feel one of them is ready to be merged.. we branch out <before the freezes starts>
Jun 25 06:30 <srag> and use gnome-2-28 code base for 2.28 as usual..
Jun 25 06:30 <srag> and give way for the kb and dbus-hybrid to mix & work in master
Jun 25 06:31 <srag> 2.29.x is when its gonna be hard tested by the users
Jun 25 06:31 <srag> sounds fine ?
Jun 25 06:32 <mbarnes> I'd suggest delaying the branch as long as possible to save ourselves the added maintenance
Jun 25 06:32 <seb128> somewhat
Jun 25 06:32 <seb128> what mbarnes says
Jun 25 06:32 <seb128> + I think it would be nice to be able to land the e-d-s over dbus switch this cycle
Jun 25 06:33 <srag> seb128, right... but you can't have the stability you are looking for... it *could* be bit broken
Jun 25 06:33 <seb128> well that's not much change to user features
Jun 25 06:33 <seb128> it's mainly the underline technology
Jun 25 06:33 <mbarnes> srag: we'll also need to make it clear to the translation teams what we're doing, as the freeze won't apply to master (post-branching) this cycle
Jun 25 06:33 <seb128> so it should not impact much of user experience
Jun 25 06:34 <seb128> on
Jun 25 06:34 <srag> mbarnes, I'll take care
Jun 25 06:34 <srag> seb128, the same would then apply for kill-bonobo.. *honestly*
Jun 25 06:34 <seb128> well you can't handle that much change in one cycle
Jun 25 06:34 *knirav (~email@example.com) has joined #evolution-meet
Jun 25 06:34 <srag> its not about a major UI revamp.. its just the way modules intereact with shell etc
Jun 25 06:35 <seb128> it's another reason it would be nice to land one of the 2 rewrites this cycle
Jun 25 06:35 <seb128> and not land both in the 2.29 cycle to expect 2.30 to be stable
Jun 25 06:35 <lakhil> -1
Jun 25 06:35 <seb128> I don't see that happening
Jun 25 06:35 <srag> lakhil, -1 ?
Jun 25 06:35 <jony> seb128: hmm .. not really .. may not have enough ppl to fix bugs on both :)
Jun 25 06:35 <seb128> 2.29 having so much changes and 2.30 being stable
Jun 25 06:35 <lakhil> srag, for merging dbus in 2.28
Jun 25 06:35 <seb128> jony, well they land eds-dbus now, focus on getting to in shape for 2.28
Jun 25 06:36 <seb128> land bonobo-slay in 2.29 and get it stable for 2.30
Jun 25 06:36 <seb128> and you have 2.30 somewhat stable
Jun 25 06:36 <srag> seb128, I seem to like what you say, honestly
Jun 25 06:36 <seb128> if you wait for 2.29 and land everything I fail to see you success at stabilizing all the changes
Jun 25 06:36 <seb128> at least not for 2.30
Jun 25 06:36 <lakhil> may be ship dbus only for ubuntu ;-)
Jun 25 06:37 <srag> seb128, I think I get a plan now. I need to work with ross/chen to see, if I can get it in for 2.28
Jun 25 06:38 <seb128> cool
Jun 25 06:38 <srag> its almost same as what I proposed, but yeah, its a bit less, doesn't include kill-bonobo
Jun 25 06:38 <abharath> srag: :)
Jun 25 06:38 <lakhil> if calendar doesn't work due to dbus, it will be a trouble
Jun 25 06:39 <seb128> srag, ie land eds-dbus in master and use that for 2.28 if it stabilize enough?
Jun 25 06:39 <srag> lakhil, we would take care of that
Jun 25 06:39 <mbarnes> srag: does eds-dbus change API at all? squeezing it in at the last moment may mean committing to the API prematurely
Jun 25 06:39 <srag> mbarnes, I dont think it breaks ABI/ABI by design
Jun 25 06:39 <EvaSDK> the advantage of doing that in two steps is that it let mbarnes enough time to rething the GnomeCalendar stuff :)
Jun 25 06:40 <srag> EvaSDK, no, please don't add more to kill-bonobo :-)
Jun 25 06:40 <srag> I wanted it to merge very soon :-)
Jun 25 06:40 <EvaSDK> hum
Jun 25 06:40 <srag> its the one, which would be closer to the user and needs more QA
Jun 25 06:40 <mbarnes> EvaSDK: Evolution Exchange is actually my biggest concern
Jun 25 06:40 <EvaSDK> right
Jun 25 06:41 *andre (~firstname.lastname@example.org) has joined #evolution-meet
Jun 25 06:41 *monkey|bot gives channel operator status to andre
Jun 25 06:41 <EvaSDK> but if you get a longer dev-cycle, it would maybe be best to take advantage of that to clean up the calendar stuff as well
Jun 25 06:41 <lakhil> hey andre
Jun 25 06:41 <jony> mbarnes: right ... :)
Jun 25 06:41 <srag> mbarnes, true.. lets tackle it. we now have more time in k-b
Jun 25 06:42 <andre> hi
Jun 25 06:42 <srag> hey andre
Jun 25 06:42 <srag> are we done.. shall we move ahead to the status ?
Jun 25 06:42 <EvaSDK> I think so
Jun 25 06:42 <seb128> nothing else to add from me there
Jun 25 06:42 <srag> cool
Jun 25 06:42 <srag> andre, anything to share with us ?
Jun 25 06:43 <andre> nope. but meeting log forwarding welcome :-)
Jun 25 06:43 <abharath> :)
Jun 25 06:43 <srag> andre, sure :)
Jun 25 06:43 <srag> abharath, anything to share with us ?
Jun 25 06:43 <jony> srag: summary please .
Jun 25 06:43 <abharath> srag: some upstream fixes, and a couple of days back have started on a Native GAL implementation for MAPI
Jun 25 06:44 <srag> jony, sure. I will be posting a mail on e-h today.. no tomorrow :-)
Jun 25 06:44 <srag> abharath, awesome.
Jun 25 06:44 <jony> srag: cool.
Jun 25 06:44 <srag> EvaSDK, anything to share with us ?
Jun 25 06:44 <EvaSDK> no
Jun 25 06:44 <srag> jony, anything to share with us ?
Jun 25 06:45 <jony> srag: mapi bug.
Jun 25 06:45 <jony> srag: and got threading (partially working)
Jun 25 06:45 <jony> and wrt to this evolution branching ..
Jun 25 06:45 <srag> jony, nice. any thing on oof ?
Jun 25 06:45 <mbarnes> andre: I'll be posting the log to the website immediately after the meeting
Jun 25 06:45 <jony> evo-mapi wont have much impact.
Jun 25 06:45 <srag> jony, cool.
Jun 25 06:46 <srag> knirav, anything to share with us ?
Jun 25 06:46 <jony> srag: OOF (out of office) . not yet . but would probably try it for next week.
Jun 25 06:46 <jony> and more thing.
Jun 25 06:46 <knirav> srag, nothing from my side
Jun 25 06:46 <jony> libmapi minimum deps is moved to 0.8.2
Jun 25 06:46 <srag> jony, ok.
Jun 25 06:47 <srag> knirav, we should have dbus-hybrid tested for addressbook asap and look at the calendar work with more prio
Jun 25 06:47 <srag> knirav, Im already reading the code bits as a review.. but real testing is a must thing
Jun 25 06:47 <knirav> srag,ok
Jun 25 06:47 <srag> lakhil, anything to share with us ?>
Jun 25 06:47 <lakhil> srag, mostly on mapi testing and bug triaging
Jun 25 06:47 <jony> thanks lakhil !
Jun 25 06:48 <lakhil> welcome
Jun 25 06:48 *ross finally arrives
Jun 25 06:48 <srag> lakhil, cool. lakhil would be great, if you can see how you can get dbus-hybrid on to your box for testing.
Jun 25 06:48 <srag> welcome ross
Jun 25 06:48 <jony> heya ross :)
Jun 25 06:48 <ross> sorry, had to put the baby to sleep :)
Jun 25 06:48 <seb128> hey ross
Jun 25 06:48 <ross> hi seb128
Jun 25 06:48 <lakhil> srag, may be we can discuss later about dbus testing
Jun 25 06:49 <srag> lakhil, anything you wanna say ?
Jun 25 06:49 <srag> mbarnes, anything to share with us ?
Jun 25 06:49 <mbarnes> nothing beyond what I've already blogged about. had a few bugs trickle in from k-b testers
Jun 25 06:49 <lakhil> srag, i may not be able to do due to sle release, that's all
Jun 25 06:50 <srag> mbarnes, we need to break down calendar and move forward there. expect some helping hand from me/others :-)
Jun 25 06:50 <srag> lakhil, ok.
Jun 25 06:50 <mbarnes> srag: sweet, appreciated
Jun 25 06:50 <srag> mcrha, anything to share with us ?
Jun 25 06:50 <mcrha> nothing interesting, just I did and plan to do some tweaks in caldav, as I mentioned above. Otherwise on calendar bugs, filling Chen's patch review quota.
Jun 25 06:50 <srag> mbarnes, only after you tell me a list of todos that can be done in parallel ;-)
Jun 25 06:51 <srag> mcrha, thanks
Jun 25 06:51 <srag> partha, anything to share with us ?
Jun 25 06:51 <partha> nothing for now. i'll pass. Thanks :)
Jun 25 06:52 <srag> partha, you gonna give share me your Anjal build ? :-)
Jun 25 06:52 <abharath> partha: make a deal :D
Jun 25 06:52 <srag> ross, anything to share with us ?
Jun 25 06:52 <abharath> this is the chance :D
Jun 25 06:53 <partha> yeah! sure that will be done.
Jun 25 06:53 <ross> the aggressive plan to land eds-dbus for 2.28 is cool but ideally i'll get more work time to sort it out. let me speak to my manager
Jun 25 06:53 <ross> note that eds-dbus *will break evolution*
Jun 25 06:53 <ross> because evolution uses some of the corba fu directly
Jun 25 06:54 <ross> i was hoping on kill-bonobo landing in sync, if that doesn't happen then we'll probably need to merge bits of it early
Jun 25 06:55 <srag> oh
Jun 25 06:55 <mbarnes> alarm-notify, for example. right?
Jun 25 06:56 <ross> exactly
Jun 25 06:56 <ross> there isn't a lot of breakage
Jun 25 06:56 <ross> but there is some
Jun 25 06:57 <srag> if its just alarm, its a very much independent piece, we can handle that
Jun 25 06:57 <mbarnes> ross: is evo still going be killing the e-d-s daemon on startup?
Jun 25 06:57 <ross> i certainly hope not
Jun 25 06:57 <ross> silly thing to do :)
Jun 25 06:58 <mbarnes> good, I'd like to ditch that junk in main()
Jun 25 06:58 <srag> specially when its being used by more than evo
Jun 25 06:58 <ross> how does that currently work with the panel? does the panel reconnect when eds dies, or does it not really die?
Jun 25 06:59 <jony> panel respawns eds .
Jun 25 06:59 <mbarnes> we literally kill the process, so I assume it reconnects
Jun 25 06:59 *srag haven't debugged that much.. so no idea honestly
Jun 25 07:00 <ross> best make sure eds-dbus handles that case then :)
Jun 25 07:00 <srag> ross, are you aware of anything big than the alarm stuff ?
Jun 25 07:00 <srag> :)
Jun 25 07:01 <ross> srag: honestly, i can't recall. i think it was mainly the use of orbit typedefs which are not part of the libecal api
Jun 25 07:01 <srag> ross, oh, are we expecting some API breakage ?
Jun 25 07:02 *srag just recalled that he, ross needs to close some api compliance
Jun 25 07:02 <ross> eds-dbus and eds have identical client side libebook/libecal API
Jun 25 07:02 <srag> that makes it pretty safe.
Jun 25 07:02 <ross> the IDL obviously disappears, but that is an implementaiton detail imho and shouldn't be used
Jun 25 07:02 <srag> cool.
Jun 25 07:02 <ross> the libedata-* APIs have changed slightly
Jun 25 07:02 <ross> very slightly, iirc
Jun 25 07:03 <srag> but thatz interenal to the backend which is easier to handle internally
Jun 25 07:03 *ross curses the damn americans flying over his house
Jun 25 07:03 <ross> srag: yeah, only really effects out-of-tree backends (-exchange, -mapi, etc)
Jun 25 07:04 <ross> speaking of which, can we move everything with "exchange" in its name from eds into evo-exchange?
Jun 25 07:04 <ross> or -mapi or whatever
Jun 25 07:04 <srag> ross, how much effort or what is pending / do you force on finishing off the calendar stuff
Jun 25 07:04 <jony> ross: hmm .. for -mapi , licensing issues. so gotta look at that part (not sure )
Jun 25 07:05 <ross> the calendar port really needs to be rewritten. probably about a week of work fulltime
Jun 25 07:05 <srag> ross, cool.
Jun 25 07:06 <srag> ross, will be great if you put that week over eds-dbus for calendar and get it in asap.
Jun 25 07:06 <mbarnes> ross: +1 on cleansing e-d-s of exchange
Jun 25 07:06 <ross> srag: i'll speak to the bosses and see if i can get the time
Jun 25 07:06 <ross> obviously we're rather busy atm
Jun 25 07:06 <srag> ross, sure. I understand.
Jun 25 07:06 <srag> mbarnes, ross we can look at it surely.
Jun 25 07:07 <mcrha> jony, I do not remember any ema pieces in eds, do you?
Jun 25 07:07 <srag> mcrha, some bits in servers/mapi
Jun 25 07:07 <srag> iirc
Jun 25 07:07 <jony> mcrha: nope. there is nothing
Jun 25 07:07 <jony> srag: nope. we have that in evo-mapi.
Jun 25 07:07 <srag> thanks a lot ross for the great updates and data. honestly, I feel more confident on eds-dbus for 2.28.. but lets see how we can merge fast.
Jun 25 07:08 <srag> jony, cool. so nothing then :)
Jun 25 07:08 <jony> (i think i misunderstood ross's line .. sorry about that )
Jun 25 07:08 <srag> seb128, anything ot share with us ?
Jun 25 07:08 <seb128> not a lot, evo 2.27 is in ubuntu karmic now, we can do ppa builds for eds-dbus and evolution-bonobo-slay if that's useful
Jun 25 07:09 <srag> seb128, thatz gonna be very useful. I want more hands on eds-dbus and kill bonobo
Jun 25 07:09 <mbarnes> seb128: yes it would be, even if we can pick up just a few extra testers
Jun 25 07:09 <seb128> ok, I will look at that then should be easy to do
Jun 25 07:10 <srag> cool.
Jun 25 07:10 <srag> anything else to discuss ?
Jun 25 07:10 <seb128> no
Jun 25 07:10 <jony> nope.
Jun 25 07:10 <mbarnes> k-b distchecks. I've just been snapshotting HEAD regularly
Jun 25 07:11 <srag> Ok guys, see you all next week