Re: [evolution-patches] Warning fixes

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2006-10-17 at 11:54 -0400, Pavel Roskin wrote:
> On Tue, 2006-10-17 at 09:58 +0200, Philip Van Hoof wrote:

> I'm not planning to do any more work on Evolution.  As far as I know, my
> patches haven't been accepted.  Perhaps my karma is not positive enough.
> In this case, you should probably do everything from scratch, since my
> patch is not likely to overlap with anything.

Pavel,

That probably says more about Novell's staffing problems than anything
about your karma. Your karma, the first time you sent a patch, was 100%
healthy. I assure you that.

Sadly something like that makes you, and many many other good hackers in
our community, decide that the Evolution project isn't worth contrib-
uting to anymore.

I more or less made a similar decision by no longer caring about
whatever upstream does with Camel: I will use my own version for my
project anyway. This doesn't mean that I will not submit my patches to
the mailing list. It does, however, mean that I don't care about the
patches going in the main repository or not. 

I'm sure the developers themselves at Novell aren't to blame. I'm
confident that they have huge todo lists too (we all have).

Karma and ego are often a problem in our community (I think it's
exceptionally underestimated). I don't know whether ego or karma issues
have something to do with this. I'm not ruling it out, but I pretty sure
that your personal karma isn't to blame here.

My personal subjective opinion (and all what I will write now is 100%
subjective, like: "free opinion", etc etc) is that or Novell should put
(a lot) more energy in the projects staffing or Novell should much more
intensively open the project to the community.

For example by allowing community members to maintain components like
Camel and others, by no longer requiring copyright reassignment, by
splitting the project up in a lot reusable components that don't
necessarily have a lot to do with the Evolution application suite as a
monolithic entity, etcetera

Its size is definitely a factor that defines the non-success of
"Evolution as a GNOME community project" (it has never felt nor feels
like a true GNOME community project)

End of my subjective opinion.


> Just one suggestion.  You may discover that there are too many warnings
> to deal with all of them at once.  So you could split patches by the
> topic.  for instance, one patch could deal with "()" in places where
> "(void)" should be.  Next patch for all other prototype problems. One
> more to deal with the warnings seen on 32-bit systems.  Then one or two
> to deal with the warnings that only 64-bit systems exhibit.  Then a
> patch for problems found by Valgrind on 32-bit systems.  Then the same
> for the 64-bit systems.

I just fix everything and don't care about what upstream does with it.
If they don't like it, well I did what was morally and legally the right
thing to do for a LGPL project: I submitted my changes in a for the
project maintainer usable format (unified diff) and I make all the
sources of my own project LGPL too. Including my changes to Camel.

The first part being the moral part and the second part being the legal
one.

Please don't stop contributing to the project. Your contributions will
be used by other projects too. For example SyncML, Brutus, Tinymail, etc



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