Re: [Evolution-hackers] Evolution thoughts for GNOME 3.0

[Chenthill <pchenthill novell com>]

On Thu, 2009-06-18 at 02:21 +0200, Andre Klapper wrote:
> Am Mittwoch, den 17.06.2009, 23:50 +0530 schrieb Srinivasa Ragavan:
> > - Continue Evolution 2.26 as stable series till 3.0 comes out.
> > - Treat Evolution 2.28 as a intermediate milestone for GNOME/Evolution
> > 3.0
> > - Continue releasing Evolution 2.26.x  (Evolution 2.26.5/6/7...) series
> > as stable releases for GNOME 2.28.1/2/3 instead of releasing Evolution
> > 2.28.1/2/3.
> 
> You might call the stable Evolution releases "2.28.x" but create them
> from the gnome-2-26 branch. On the other hand that is confusing if you
> were up to continue calling the unstable series for 3.0 "2.27.x".
> So we ship e.g. Evolution 2.26.6/.7 for GNOME 2.28.1/.2?
> 
> 
> r-t: Having GNOME releases in mind I wonder which release suite an
> Evolution 2.27.13 release would be part of in the last weeks of GNOME
> 2.27.x - I don't think we should include a 2.27.13 Evolution release in
> e.g. GNOME 2.27.92. People expect components of a release candidate (two
> weeks before a major release) to be way more stable than Evolution
> 2.27.13 at that time (6 months before a major release).
> So how to ensure testing of the continued unstable branch in the last
> weeks before 2.28.0?
> r-t could think of an additional 2.29.0 release (shipping all modules
> that have branched for gnome-3-0 already before 2.28 release) maybe one
> week before 2.28.0?
I somehow miss the last reply from Srini on this thread though I see it
in web. So replying back to this. I like the idea of not branching and
continue to port the code for killing bonobo from eds and evolution.

But we also need to consider some patches which have added API and some
string changes. There might not be many UI changes, but still there
might be some useful ones. I don have the entire list now as we have not
discussed/looked over them yet. I have not yet got the GSoc EDS
optimization patches, but if I can get them over soon and if its good
enough I would love to push them to stable branch along with calendar
cache rewrite (http://www.go-evolution.org/Evo2.28) (quoting one case).

Thinking about the freezes API/ABI/Feature freezes coming along in a
months time. What about branching for gnome-2-27 immediately after that
and starting to merge the kill bonobo stuffs ? This would mean we will
not need to think about the merging important patches with freeze breaks
into stable. So instead of 9 months we would have 8 months.

- Chenthill.
> 
> > I expect lot of rewrites, dbus port merge, bonobo deprecation (kill
> > bonobo merge). etc. I don't think, Evolution 2.28 can be stable, unless
> > I postpone these tasks which might merge late in 2.28 cycle to really
> > 2.29.x.
> [...]
> > Thoughts on this? 
> 
> After some bad experiences with kill-summary bugs in 2.24.x I agree with
> your proposal to continue 2.27.x for the next 9 months and kind of drop
> 2.28.x.
> 
> > Secondly, Evolution uses GNOME canvas in and around every UI. I wanted
> > to know the future direction/migration path, haven't seen one before.
> > Its gonna be another painful task like deprecating bonobo with in
> > Evolution :/. I would like to vote against this, if there is a
> > possibility.
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=571742
> 
> I still have not found out when and why libgnomecanvas was deprecated by
> the release-team. Maybe someone remembers?
> 
> According to http://www.gnome.org/~fpeters/299.html Evolution, planner
> and gthumb use libgnomecanvas.
> 
> andre