GNOME.org
 

[Evolution-hackers] [Fwd: Re: Merging work] was: Let the porting

Hi there Evo hackers,

My fellow Tinymail coder Jose Dapena Paz hinted me which pieces of
camel-lite's camel-mime-utils.c needed patching work and which pieces
could come from upstream to camel-lite.

This was one of the few remaining files that needed a synchronisation
between upstream Camel and camel-lite. You can see a changeset here:

http://tinymail.org/trac/tinymail/changeset/2828

All other files in the root directory of Camel's sources now only
contain for camel-lite necessary changes and now have all recent
upstream-Camel changes included. You can find this root dir here:

https://svn.tinymail.org/svn/tinymail/trunk/libtinymail-camel/camel-lite/camel/ 

versus

http://svn.gnome.org/viewcvs/evolution-data-server/trunk/camel/


I don't think a lot in upstream-Camel's providers has since changed, but
the code in the providers/ directory has not yet been synchronised with
upstream. Most of the changes in that directory are specific and related
to the new features in camel-lite.


-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog
--- Begin Message --- 
El lun, 08-10-2007 a las 00:15 +0200, Philip Van Hoof escribi� Hey Jose,
> 
> Would it be possible for you to check the differences of upstream
> Camel's camel-mime-utils.c with camel-lite's. I refrained from
> synchronising our camel-lite's camel-mime-utils.c with upstream Camel
> because there might have been changes that you made to support the
> attachment purging. I've found some changes that were unknown to me.

	I've been reviewing the svn log, and it seems I didn't make any change
in camel mime utils (and after reviewing the differences between
upstream camel and tinymail camel I still don't find anything I can
remember).

	Anyway, briefly, the changes are:
	* A lot of compilation warning fixes, using proper typecasts. They
should go upstream.
	* The change in parenthesis and conditions in line 795 present in
upstream camel seems to be interesting for us, as it seems an obvious
error.
	* Our fix for escaping ? seems ok at lines 1155 and 1168. Should go
upstream.
	* You changed CamelContentType instantiation to use g slice. Should be
upstream unless it breaks something there for backwards compatibility.
	* We should get the change at line 2097 upstream. But it seems even
upstream is not ok, as the *inptr validation should be 
		(*inptr && camel_mime_is_dtext(*inptr))
	instead of 
		(camel_mime_is_dtext(*inptr) && *inptr)

	In general there are no traumatic changes, and they are all more or
less wise both in our side and on camel upstream side. So I would say we
should make these changes go upstream in official camel (the only doubt
would be the GSlice issue).

-- 
Jose Dapena Paz <jdapena igalia com>
Igalia
_______________________________________________
tinymail-devel-list mailing list
tinymail-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/tinymail-devel-list

--- End Message ---
--- Begin Message --- 
Hey Jose,

Would it be possible for you to check the differences of upstream
Camel's camel-mime-utils.c with camel-lite's. I refrained from
synchronising our camel-lite's camel-mime-utils.c with upstream Camel
because there might have been changes that you made to support the
attachment purging. I've found some changes that were unknown to me.

This is the upstream version:
http://svn.gnome.org/viewcvs/evolution-data-server/trunk/camel/camel-mime-utils.c?view=log

I can recommend KDiff3 for this, but you can use any tool you like of
course.

Obviously would it be nice to keep your changes and merge any possible
new changes applied to the upstream version to our version. The idea is
to make it possible to get a clean and nice patch using just "diff -r".
That patch should then show which exact changes that we made to create
our features (like your attachment purger). That way upstream Evolution
can filter out what they like and bring it to Evolution too.


ps. I'm adding the Tinymail mailing list in CC to keep the rest of the
world updated on this.


-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog



Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog




_______________________________________________
tinymail-devel-list mailing list
tinymail-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/tinymail-devel-list

--- End Message ---
--- Begin Message --- 
Thanks

On Mon, 2007-10-08 at 08:15 +0200, Jose Dapena Paz wrote:
> El lun, 08-10-2007 a las 00:15 +0200, Philip Van Hoof escribi� > Hey Jose,
> > 
> > Would it be possible for you to check the differences of upstream
> > Camel's camel-mime-utils.c with camel-lite's. I refrained from
> > synchronising our camel-lite's camel-mime-utils.c with upstream Camel
> > because there might have been changes that you made to support the
> > attachment purging. I've found some changes that were unknown to me.
> 
> 	I've been reviewing the svn log, and it seems I didn't make any change
> in camel mime utils (and after reviewing the differences between
> upstream camel and tinymail camel I still don't find anything I can
> remember).
> 
> 	Anyway, briefly, the changes are:
> 	* A lot of compilation warning fixes, using proper typecasts. They
> should go upstream.
> 	* The change in parenthesis and conditions in line 795 present in
> upstream camel seems to be interesting for us, as it seems an obvious
> error.
> 	* Our fix for escaping ? seems ok at lines 1155 and 1168. Should go
> upstream.
> 	* You changed CamelContentType instantiation to use g slice. Should be
> upstream unless it breaks something there for backwards compatibility.
> 	* We should get the change at line 2097 upstream. But it seems even
> upstream is not ok, as the *inptr validation should be 
> 		(*inptr && camel_mime_is_dtext(*inptr))
> 	instead of 
> 		(camel_mime_is_dtext(*inptr) && *inptr)
> 
> 	In general there are no traumatic changes, and they are all more or
> less wise both in our side and on camel upstream side. So I would say we
> should make these changes go upstream in official camel (the only doubt
> would be the GSlice issue).
> 
-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog




_______________________________________________
tinymail-devel-list mailing list
tinymail-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/tinymail-devel-list

--- End Message ---
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]