Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2007-05-21 Thread Srinivasa Ragavan
On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote:
 On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote:
  Hi,
  
  I discovered last week that there is an attempt to resurrect libical
  from non-maintainership, merge all of the patches from various forks,
  and start making sane releases again[1].  Are the evolution team as
  whole interested in merging their changes to libical upstream and
  depending on it to be installed when a release is made with all of the
  relevant changes?  libical isn't exactly a small library, and statically
  linking it is a waste of memory for everyone.
 
 I vaguely recall the biggest diff being timezone handling.
 
  I'll happily start working on extracting the changes to EDS and pushing
  them into the new libical repository, if the Evolution team as a whole
  agrees that the fork of libical will be dropped.
 
 I'd suggested waiting to see a pattern of stable releases before moving
 externally, but getting the patches upstream would be good.

Sounds very reasonable to me. 

-Srini.

 
 -JP

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


Re: [Evolution-hackers] Removal of implementation details from public API, any breakages?

2007-05-21 Thread Srinivasa Ragavan
Ross,

It will be great if you can mail the details on the address book stuff
as well. I would like the libebook clients like OOo, etc to comment on
this. 

-Srini.

On Sun, 2007-05-20 at 11:29 +0100, Ross Burton wrote:
 Hi,
 
 Last week I committed a patch to libebook, and want to commit a patch to
 libecal[1], which removes private functions and types from the installed
 headers.  This has several consequences:
 
 - e_cal_view_new() is removed
 - ECalListener is removed
 - ECalViewListener is removed
 
 I believe that nobody is using these functions apart from libecal
 itself, so this removal is safe.  However, I'd appreciate it if anyone
 writing advanced clients to EDS (like Zimbra or Brutas) remove their
 currently installed headers, apply the patch, and rebuild.
 
 Thanks,
 Ross
 
 [1] http://bugzilla.gnome.org/show_bug.cgi?id=438727
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

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


Re: [Evolution-hackers] Removal of implementation details from public API, any breakages?

2007-05-21 Thread Jules Colding
On Sun, 2007-05-20 at 11:29 +0100, Ross Burton wrote:
 Hi,
 
 Last week I committed a patch to libebook, and want to commit a patch to
 libecal[1], which removes private functions and types from the installed
 headers.  This has several consequences:
 
 - e_cal_view_new() is removed
 - ECalListener is removed
 - ECalViewListener is removed
 
 I believe that nobody is using these functions apart from libecal
 itself, so this removal is safe.  However, I'd appreciate it if anyone
 writing advanced clients to EDS (like Zimbra or Brutas) remove their
 currently installed headers, apply the patch, and rebuild.

Brutus is safe.

Thanks for the notice,
  jules


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


Re: [Evolution-hackers] Removal of implementation details from public API, any breakages?

2007-05-21 Thread Srinivasa Ragavan
Ross,

From the current discussion, it looks like we are safe. Can we do
something like this for this release before we dung them out?

#ifdef E_D_S_DEPRECATED
#include bonobo/bonobo-object.h
#endif

-Srini.

On Mon, 2007-05-21 at 10:32 +0100, Ross Burton wrote:
 On Mon, 2007-05-21 at 12:15 +0530, Srinivasa Ragavan wrote:
  It will be great if you can mail the details on the address book stuff
  as well. I would like the libebook clients like OOo, etc to comment on
  this. 
 
 The addressbook changes are very similar:
 
 - e_book_view_new() is not public
 - EBookListener and EBookViewListener are not public
 
 As before, these are not usable outside of libedata-book, so clients
 should not be aware of their existence.
 
 I've had a quick look at the Zimbra Evolution code and it appears to not
 use these either.
 
 Ross

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


Re: [Evolution-hackers] Removal of implementation details from public API, any breakages?

2007-05-21 Thread Ross Burton
On Mon, 2007-05-21 at 11:33 +, Srinivasa Ragavan wrote:
 From the current discussion, it looks like we are safe. Can we do
 something like this for this release before we dung them out?
 
 #ifdef E_D_S_DEPRECATED
 #include bonobo/bonobo-object.h
 #endif

The patches consist of removing functions or headers from the install,
these cannot be deprecated because they are still used by EDS itself.

I don't think there needs to be any notice: the headers and functions
are implementation details of libebook and libecal, and are not possible
to use outside of the implementation of libebook/libecal.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Removal of implementation details from public API, any breakages?

2007-05-21 Thread Matthew Barnes
On Mon, 2007-05-21 at 11:33 +, Srinivasa Ragavan wrote:
 #ifdef E_D_S_DEPRECATED
 #include bonobo/bonobo-object.h
 #endif

Just FYI, EDS_DISABLE_DEPRECATED is what Gtk-Doc looks for.

Matthew Barnes

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


[Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Frederic Crozat
Hi Evolution / E-D-S maintainers,

it appears that since CVS to SVN migration, no evolution / e-d-s release
was followed by a SVN tag creation in module_name/tags.

These tags are very useful for you, maintainers but also for
contributors and vendors when they try to search for changes between
releases.

Could you try to create those missing tags and make sure they are
created when releasing new tarballs in the future (I guess somebody
script was not migrated correctly to SVN ;) ?

Thanks you in advance.
-- 
Frederic Crozat [EMAIL PROTECTED]
Mandriva

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


Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Gilles Dartiguelongue
Le lundi 21 mai 2007 à 17:19 +0200, Frederic Crozat a écrit :
 Hi Evolution / E-D-S maintainers,
 
 it appears that since CVS to SVN migration, no evolution / e-d-s release
 was followed by a SVN tag creation in module_name/tags.
 
 These tags are very useful for you, maintainers but also for
 contributors and vendors when they try to search for changes between
 releases.
 
 Could you try to create those missing tags and make sure they are
 created when releasing new tarballs in the future (I guess somebody
 script was not migrated correctly to SVN ;) ?
 
 Thanks you in advance.

in fact it seems evolution uses branches over tags

evolution stable branch can be found at :
 http://svn.gnome.org/svn/evolution/branches/gnome-2-18

-- 
Gilles Dartiguelongue [EMAIL PROTECTED]

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


Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Frederic Crozat
Le lundi 21 mai 2007 à 19:24 +0200, Gilles Dartiguelongue a écrit :
 Le lundi 21 mai 2007 à 17:19 +0200, Frederic Crozat a écrit :
  Hi Evolution / E-D-S maintainers,
  
  it appears that since CVS to SVN migration, no evolution / e-d-s release
  was followed by a SVN tag creation in module_name/tags.
  
  These tags are very useful for you, maintainers but also for
  contributors and vendors when they try to search for changes between
  releases.
  
  Could you try to create those missing tags and make sure they are
  created when releasing new tarballs in the future (I guess somebody
  script was not migrated correctly to SVN ;) ?
  
  Thanks you in advance.
 
 in fact it seems evolution uses branches over tags
 
 evolution stable branch can be found at :
  http://svn.gnome.org/svn/evolution/branches/gnome-2-18

Branches and tags are different beast :
-branches are used to do developement for a particular release of GNOME
(here 2.18.x series)
-tags are pointing each release (ie tarball generation), regardless of
branches.

-- 
Frederic Crozat [EMAIL PROTECTED]
Mandriva

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


Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Gilles Dartiguelongue
Le lundi 21 mai 2007 à 18:03 +0200, Frederic Crozat a écrit :
 Le lundi 21 mai 2007 à 19:24 +0200, Gilles Dartiguelongue a écrit :
  Le lundi 21 mai 2007 à 17:19 +0200, Frederic Crozat a écrit :
   Hi Evolution / E-D-S maintainers,
   
   it appears that since CVS to SVN migration, no evolution / e-d-s release
   was followed by a SVN tag creation in module_name/tags.
   
   These tags are very useful for you, maintainers but also for
   contributors and vendors when they try to search for changes between
   releases.
   
   Could you try to create those missing tags and make sure they are
   created when releasing new tarballs in the future (I guess somebody
   script was not migrated correctly to SVN ;) ?
   
   Thanks you in advance.
  
  in fact it seems evolution uses branches over tags
  
  evolution stable branch can be found at :
   http://svn.gnome.org/svn/evolution/branches/gnome-2-18
 
 Branches and tags are different beast :
 -branches are used to do developement for a particular release of GNOME
 (here 2.18.x series)
 -tags are pointing each release (ie tarball generation), regardless of
 branches.
 
sorry I was unclear. I meant that afaics, evolution never tagged
releases, or something definitely got lost in the cvs-svn transition.
-- 
Gilles Dartiguelongue [EMAIL PROTECTED]

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


Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Frederic Crozat
Le lundi 21 mai 2007 à 20:21 +0200, Gilles Dartiguelongue a écrit :
 Le lundi 21 mai 2007 à 18:03 +0200, Frederic Crozat a écrit :
  Le lundi 21 mai 2007 à 19:24 +0200, Gilles Dartiguelongue a écrit :
   Le lundi 21 mai 2007 à 17:19 +0200, Frederic Crozat a écrit :
Hi Evolution / E-D-S maintainers,

it appears that since CVS to SVN migration, no evolution / e-d-s release
was followed by a SVN tag creation in module_name/tags.

These tags are very useful for you, maintainers but also for
contributors and vendors when they try to search for changes between
releases.

Could you try to create those missing tags and make sure they are
created when releasing new tarballs in the future (I guess somebody
script was not migrated correctly to SVN ;) ?

Thanks you in advance.
   
   in fact it seems evolution uses branches over tags
   
   evolution stable branch can be found at :
http://svn.gnome.org/svn/evolution/branches/gnome-2-18
  
  Branches and tags are different beast :
  -branches are used to do developement for a particular release of GNOME
  (here 2.18.x series)
  -tags are pointing each release (ie tarball generation), regardless of
  branches.
  
 sorry I was unclear. I meant that afaics, evolution never tagged
 releases, or something definitely got lost in the cvs-svn transition.

They did, check :
svn ls http://svn.gnome.org/svn/evolution/tags/ | grep EVOL 

-- 
Frederic Crozat [EMAIL PROTECTED]
Mandriva

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


Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Srinivasa Ragavan
Frederic,

One reason why me and Harish didn't want to tag is that we are able to
map the svn revision number to a particular release. I hope isn't so
difficult to get that from the ChangeLog/configure.in/NEWS commit logs.
At least that is how we do while preparing NEWS file for a dot release
to know what went in since the last release.

If you have better points, We are open for it. Nothing against it :)

-Srini.


On Mon, 2007-05-21 at 17:19 +0200, Frederic Crozat wrote:
 Hi Evolution / E-D-S maintainers,
 
 it appears that since CVS to SVN migration, no evolution / e-d-s release
 was followed by a SVN tag creation in module_name/tags.
 
 These tags are very useful for you, maintainers but also for
 contributors and vendors when they try to search for changes between
 releases.
 
 Could you try to create those missing tags and make sure they are
 created when releasing new tarballs in the future (I guess somebody
 script was not migrated correctly to SVN ;) ?
 
 Thanks you in advance.

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


Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Gilles Dartiguelongue
Le lundi 21 mai 2007 à 18:39 +0200, Frederic Crozat a écrit :
 Le lundi 21 mai 2007 à 20:21 +0200, Gilles Dartiguelongue a écrit :
  Le lundi 21 mai 2007 à 18:03 +0200, Frederic Crozat a écrit :
   Le lundi 21 mai 2007 à 19:24 +0200, Gilles Dartiguelongue a écrit :
Le lundi 21 mai 2007 à 17:19 +0200, Frederic Crozat a écrit :
 Hi Evolution / E-D-S maintainers,
 
 it appears that since CVS to SVN migration, no evolution / e-d-s 
 release
 was followed by a SVN tag creation in module_name/tags.
 
 These tags are very useful for you, maintainers but also for
 contributors and vendors when they try to search for changes between
 releases.
 
 Could you try to create those missing tags and make sure they are
 created when releasing new tarballs in the future (I guess somebody
 script was not migrated correctly to SVN ;) ?
 
 Thanks you in advance.

in fact it seems evolution uses branches over tags

evolution stable branch can be found at :
 http://svn.gnome.org/svn/evolution/branches/gnome-2-18
   
   Branches and tags are different beast :
   -branches are used to do developement for a particular release of GNOME
   (here 2.18.x series)
   -tags are pointing each release (ie tarball generation), regardless of
   branches.
   
  sorry I was unclear. I meant that afaics, evolution never tagged
  releases, or something definitely got lost in the cvs-svn transition.
 
 They did, check :
 svn ls http://svn.gnome.org/svn/evolution/tags/ | grep EVOL 
 
indeed, case sensitivity got me :)

sorry for the confusion
-- 
Gilles Dartiguelongue [EMAIL PROTECTED]

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


Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Frederic Crozat
Le lundi 21 mai 2007 à 16:36 +, Srinivasa Ragavan a écrit :
 Frederic,
 
 One reason why me and Harish didn't want to tag is that we are able to
 map the svn revision number to a particular release. I hope isn't so
 difficult to get that from the ChangeLog/configure.in/NEWS commit logs.
 At least that is how we do while preparing NEWS file for a dot release
 to know what went in since the last release.
 
 If you have better points, We are open for it. Nothing against it :)

I don't really see what it causing problem here : just tags the release
corresponding to the commit for configure.in / NEWS / Changelog. It
isn't really a big problem if there is another commit for the tag
operation in SVN.

Or am I missing something ?
-- 
Frederic Crozat [EMAIL PROTECTED]
Mandriva

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


Re: [Evolution-hackers] Removal of implementation details from public API, any breakages?

2007-05-21 Thread Srinivasa Ragavan
On Mon, 2007-05-21 at 12:38 +0100, Ross Burton wrote:
 On Mon, 2007-05-21 at 11:33 +, Srinivasa Ragavan wrote:
  From the current discussion, it looks like we are safe. Can we do
  something like this for this release before we dung them out?
  
  #ifdef E_D_S_DEPRECATED
  #include bonobo/bonobo-object.h
  #endif
 
 The patches consist of removing functions or headers from the install,
 these cannot be deprecated because they are still used by EDS itself.

Hmm. Fine. Just go ahead then :)  

-Srini.
 
 I don't think there needs to be any notice: the headers and functions
 are implementation details of libebook and libecal, and are not possible
 to use outside of the implementation of libebook/libecal.
 
 Ross

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


Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Srinivasa Ragavan
On Mon, 2007-05-21 at 18:57 +0200, Frederic Crozat wrote:
 Le lundi 21 mai 2007 à 16:36 +, Srinivasa Ragavan a écrit :
  Frederic,
  
  One reason why me and Harish didn't want to tag is that we are able to
  map the svn revision number to a particular release. I hope isn't so
  difficult to get that from the ChangeLog/configure.in/NEWS commit logs.
  At least that is how we do while preparing NEWS file for a dot release
  to know what went in since the last release.
  
  If you have better points, We are open for it. Nothing against it :)
 
 I don't really see what it causing problem here : just tags the release
 corresponding to the commit for configure.in / NEWS / Changelog. It
 isn't really a big problem if there is another commit for the tag
 operation in SVN.

I didn't say it a problem. I'm saying that the TAG would map directly to
a revision in svn which would be the revision of the commit of those
files. You can achieve what you want with tag with just revision number
itself. In case of CVS, you can't do this. If it is of difficulty to map
to a revision, no problem in resuming that again. 

-Srini.

 
 Or am I missing something ?

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


Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Frederic Crozat
Le lundi 21 mai 2007 à 16:57 +, Srinivasa Ragavan a écrit :
 On Mon, 2007-05-21 at 18:57 +0200, Frederic Crozat wrote:
  Le lundi 21 mai 2007 à 16:36 +, Srinivasa Ragavan a écrit :
   Frederic,
   
   One reason why me and Harish didn't want to tag is that we are able to
   map the svn revision number to a particular release. I hope isn't so
   difficult to get that from the ChangeLog/configure.in/NEWS commit logs.
   At least that is how we do while preparing NEWS file for a dot release
   to know what went in since the last release.
   
   If you have better points, We are open for it. Nothing against it :)
  
  I don't really see what it causing problem here : just tags the release
  corresponding to the commit for configure.in / NEWS / Changelog. It
  isn't really a big problem if there is another commit for the tag
  operation in SVN.
 
 I didn't say it a problem. I'm saying that the TAG would map directly to
 a revision in svn which would be the revision of the commit of those
 files. You can achieve what you want with tag with just revision number
 itself. In case of CVS, you can't do this. If it is of difficulty to map
 to a revision, no problem in resuming that again. 

So, I've just discussed with sri over IRC :
-we agreed tagging is less needed now we have SVN than years ago, in the
CVS days.
-nevertheless, since other GNOME modules are following the tagging
convention and since it can be often more convenient to rely on tags
when doing diff than digging into svn log, sri agreed to start back
tagging evolution tree when doing releases.
-in short, we are in agreement ;)

Thanks again to Evolution team !

-- 
Frederic Crozat [EMAIL PROTECTED]
Mandriva

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


Re: [Evolution-hackers] e_contact_get_const api doesn't work anymore since a few weeks on debian/unstable

2007-05-21 Thread Julien Puydt
Srinivasa Ragavan a écrit :
 On Tue, 2007-05-01 at 20:35 +0200, Julien Puydt wrote:
  TEL;TYPE=Home:sip:[EMAIL PROTECTED]
  TEL;TYPE=Home;TYPE=VOICE:sip:[EMAIL PROTECTED]
  TEL;TYPE=CELL:123.123.123.123\n
 
 See it works now.

Ok, reported to the contacts developers, since it was using their 
program that I got the dysfunctional vCard :
http://bugzilla.o-hand.com/show_bug.cgi?id=298

Thanks,

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