Re: [Evolution-hackers] Camel calls causing hangs?

2009-06-24 Thread Milan Crha
On Tue, 2009-06-23 at 22:43 +0200, Filipe Nepomuceno wrote:
>for(j = 0; j < uids->len; i++)
  ^^^ use 'j' here?

Try to differentiate between "hang" and "busy loop", there is a little
difference between them :)

Also, those returned CamelObjects are supposed to be unreffed too, not
just free your array. Even I cannot tell you from this code part, as
it's not complete. (Those mail-ops functions I pointed you earlier are
unreffing arguments itself, at the end, thus in the best you should ref
them, and when done with them unref them. There is no reffing necessary
when you use it in the "done" callback only, but when you left the
callback and still need the pointer, then there should be a ref and
unref done. Just to ensure you'll not lose the pointer before you are
done with it. I think. Check the code where those are used in
evolution.)
Bye,
Milan

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] GNOME 3.0 - Evolution plans & IRC team meeting

2009-06-24 Thread P Chenthill
I will not be able to attend the irc meeting today. But the following
log has the discussion we had on Wednesday night in the channel. My
opinions are put in there. It would be good if its taken into account
while discussing this in the meeting.


- Chenthill.
On Tue, 2009-06-23 at 22:47 +0530, Srinivasa Ragavan wrote:
> Guys,
> 
> We have made some proposals to the release-team on GNOME 3.0 plans for
> Evolution. Specially release/scheduling specifics. Read through the
> thread.
> 
> http://mail.gnome.org/archives/release-team/2009-June/msg00018.html
> 
> We'll probably workout the exact schedule/decision.
> 
> I wanted to discuss this in tomorrow irc team meeting. But due to my
> busy schedule and tight meetings tomorrow, I won't be able to make it,
> and I want to post-pone the team meeting to thursday (UTC 10:00) just
> this time. Sorry, if this is a late notice.
> 
> Try to make it or keep me informed if you have some
> suggestions/thoughts. TIA.
> 
> -Srini.
> 
> 
> 
> 
> 
> 
> ___
> Evolution-hackers mailing list
> Evolution-hackers@gnome.org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers


 srag: hi
 srag: you 2.26 to be 2.28 and 2.27 to be unstable is a very not cool 
idea!
 your 
 srag: it basically means "let's screw all those who track GNOME 2.27 
and have already updated to 2.27.n"
 !  The final composer addressbook bug seems to be related to whether 
the data has finished loading when you press enter.
* nxvl has quit (leaving)
 hey seb128 
* cosimoc (~cosi...@jalfrezi.collabora.co.uk) has joined #evolution
 no...  I can't reproduce...
 :(
 but do you think 2.28 will be stable with eds/dbus port and KB merging? 
or delaying that would stabilize 3.0 ?
* nxvl (~n...@200.106.87.231) has joined #evolution
* tbf__ has quit (Read error: 145 (Connection timed out))
* nxvl has quit (leaving)
 seb128, but do you think 2.28 will be stable with eds/dbus port and KB 
merging? or delaying that would stabilize 3.0 ?
* You are now known as chen
* nxvl (~n...@200.106.87.231) has joined #evolution
 if current 2.27.x is stable enough and does not contain dbus-port and 
kill-bonobo it should become 2.28. evo should branch very early (soon) for 
2.29.x and get dbus and kill-bonobo in.
 but i think that's discussed by the evo team
 seb128, ^^
 yes, i would like to see if we can get a window for three major things 
lined up for calendar along with older patches (which I have noted in my 
release machine),
* tbf (~math...@dslb-088-067-108-091.pools.arcor-ip.net) has joined #evolution
 * cache rewrite - http://www.go-evolution.org/CalendarStore ,
 Gsoc eds optimization patches and google calendar replaced by caldav at 
the backend 
 so who maintains the addressbook and can finally review 556061?
 andre, chen but that leaves master out of testing for quite some time.
 my other worry is many good patches which inbolves more changes have not 
been taken into trunk. i just heard from mcrha early w.r.t caldav which we need 
to look at..
 its as simple as merging late.
 srag, so if these are covered, i have no issues :)
 srag: well, distros are free to package master for testing
 chen, the patches ?
 kill-bonobo is available for fedora
 ubuntu can also package it
 er
 er?
 srag, i have noted some which break freezes, but really good to have. I 
have the list on another system in office. i can mail them across
 as a reply back to thread..
 andre, but honestly, people won't use it, unless its the *official* 
version
 andre, yes, I guess we could. But it will be a PPA release, not a main
 chen, we can take up that.. not a problem.
 hggdh, sure
 andre, Im fine to have both 2.27.x and 2.26.x released till 3.0 comes 
out..
 but have not covered the patches which have not committed in stable. i 
think all individual maintainers have to look at the patches on the components 
to just ensure..
 srag, encourage people to do so
 srag, the issue is we already delivered 2.27.3 to Karmic, going back 
will be a pain
 there's blogs and mailing lists.
 hggdh, if its a matter of version, we can work that out.. cache 
shouldn't be a problem.
 hggdh, but I understand your issue 
 that's why i currently also favor making 2.27.x -> 2.28.x and branch 
very early (and to be very conservative for 2.27.x for the rest of the time)
 andre, right, I love that proposal really, but Im afraid, it would miss 
the good amount of testing that can happen if its called 2.27.x :(
 andre, +1
 srag, what is "it"?
 the master branch 
 Im trying to recall something that happened with gdm, dont know the 
exact releases/numbers
 archlinux and debian still ship gdm 2.20 in their current unstable
 i don't think it's that similar though
 not similar, but would be great, if distros ship 2.27.x and together 
with 2.26.0 for stability reasons
 It could be stupid though, but I think just a discussion could point out 
some new direction, where the master gets tested well.
 i may be wrong in the following perspective but