[Evolution-hackers] New composer progress

2007-12-11 Thread Matthew Barnes
Several people have asked me about it, so I put together a wiki page
detailing my plan and progress on the new composer widget I'm trying to
finish for 2.22.  Feel free to add comments or try out the code.


Matthew Barnes

Evolution-hackers mailing list

Re: [Evolution-hackers] Post-release version incrementing

2007-12-11 Thread Srinivasa Ragavan

It may not work out here, since the micro version is what we bump during
release which is in sync with the GNOME Release micro version.
(Evolution 2.21.3 == GNOME 2.21.3)

Matt, I'm not against it, if it benefits hackers. Personally I don't use
2 versions and so It doesn't matter much to me. If I don't hear any
objections, I would be doing  it during the 2.21.4 release and make
trunk 2.21.5. 


On Tue, 2007-12-11 at 03:29 +0200, Tor Lillqvist wrote:
  I notice we've been doing pre-release version incrementing 
  I was wondering if the team would be open to switching to post-release 
  version incrementing 
 May I suggest a third, in my opinion superior, way: Both.
 That's what cairo uses, see
 http://cairographics.org/manual/cairo-Version-Information.html . The
 micro version number is even in released tarballs, and odd
 inbetween. The even number never exists in SVN. The micro number is
 bumped by the person doing a release, and then bumped again and
 committed after the tarball has been built. Thus there cannot be any
 confusion between official released versions and builds from SVN at
 least as far as version numbers are concerned.
 Evolution-hackers mailing list

Evolution-hackers mailing list

[Evolution-hackers] future of evolution user docs.

2007-12-11 Thread Andre Klapper
for a long time, several people have been unhappy with the current state
of the evolution user docs[1]. me too, but most of my rantings have been
on irc so i can't link to them. ;-)

when evolution 2.0 became an official part of GNOME 2.8, aaron was
working full-time on the evolution docs. now my impression is that
updates get written in a hurry without any proof-reading.

it has happened twice to me that svn changes have been overwritten[2,3],
because novell uses its own user documentation management for evolution
(read: apply changes to an adobe framemaker document and then try to get
them into svn. somehow). dropping code, instead of merging. cathedral,
instead of bazaar. that's not really how open source works.
it means that patches cannot get easily committed because they would get
overwritten by novell's next commit.
also, me and other folks have spent quite some time to discuss and
explain basic gnome doc workflow stuff to the assigned writers[4].

the docs are still very novell-specific. red carpet is still
mentioned, for additional help you are told to visit
http://support.novell.com, sometimes it is Novellreg;
Evolutiontrade; and in general the documentation conventions haven't
been changed to gnome's conventions (markup[5], terminology).
also, lots of explanations are just of the read the interface back to
you type (but this is not an evolution specific problem).

when i translated the majority of the evolution user guide to german, i
have found a lot of errors[6]. some of them have been fixed, some of the
fixes have introduced new errors (did i say proof-reading already?).

summary: there are two problems. ´╗┐the modus operandi of novell's doc
team and the quality of the docs.

1) novell's doc team shall use the gnome svn version as the base version
for changes and rework the doc to follow gnome's conventions. novell,
like any other distributor, may of course derivate from the gnome svn
doc as they wish to provide their own, enhanced evolution user
documentation that provides a much better desktop experience with
novell's/(open)suse's desktop.
2) if we cannot find a consensus, fork. novell may have its own branch
for the docs, and we can port and backport changes between branches.

the gnome documentation team does not have enough manpower to update the
user documentation by itself, so i would still prefer to see the first
proposal happen. the question is whether we want to have a clean and
typo-free (but obsolete) doc, or a more-or-less up-to-date (but
error-prone and non-gnome-compliant) doc. having both
would be the best choice, of course.


[1] http://mail.gnome.org/archives/gnome-doc-list/2007-August/msg00051.html
[2] http://bugzilla.gnome.org/show_bug.cgi?id=411255
[3] http://bugzilla.gnome.org/show_bug.cgi?id=56#c4
[4] http://bugzilla.gnome.org/show_bug.cgi?id=435942
[5] http://bugzilla.gnome.org/show_bug.cgi?id=404234
[6] http://bugzilla.gnome.org/show_bug.cgi?id=438479
 mailto:[EMAIL PROTECTED] | failed

Description: Dies ist ein digital signierter Nachrichtenteil
Evolution-hackers mailing list