Fwd: Hayes

[Charles Samuels]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Please continue to CC me.

Now, Neil, I ask you kindly to not twist my words.  You rephrase what I said 
in the hopes that it'd come out to your benefit.

And I come off hostile in this email because I have spent almost 3 years 
developing Noatun.  I wish for nothing but the best for noatun and I feel 
it's reasonable to take everything that happens with it rather personally.  
Neil has done little to make my work feel appreciated.

On Monday 27 January 2003 3:16, you wrote:
> On Monday January 27, 2003 12:55, Rob Kaper wrote:
> > Neil wrote Hayes without implementing a part of the API completely,
> > properties, because he's he claims he  doesn't like the concept of
> > properties.  Properties are like X-atoms.  Any plugin should be able to
> > set a key-value pair, like "copyright"->"Virgin Schallplatten GmbH".
> > Neil decided that he doesn't like this, so basically, setting a property
> > results in nothing happening.
>
> This is only half-true.  Previously, in an attempt to compromise, I
> implemented these dictionaries so that they would be saved for the life of
> the application.  They just wouldn't be saved after the app quit.

The next paragraph begins with: "So then, I finally get Neil to make property 
support optional"

>
> Charles disabled Hayes from release even after this.

No, I disabled it for a different reason entirely.  Popular to the rumors you 
may be spreading, I don't have a vendetta against Hayes, I just don't want to 
get bug reports for the code of others.

>
> > So then, I finally get Neil to make property support optional, and he
> > implements another feature, which allows you to add a file to Hayes
> > right from a Konqueror context menu (indeed a nice feature!).  It
> > communicates to Hayes via its own DCOP interface, rather than using
> > Noatun's own dcop interface function "addFile".  Mind you this item
> > appears on the Konqueror context menu even if Hayes isn't loaded. Ok,
> > very well, I'll just ask Neil to change it to use the noatun function.
> > Turns out he didn't implement the noatun function, because he didn't
> > like the *name* of the function addFile. Not only this, but he wrote
> > hayes before we released 3.0 (and hence before I started keeping Binary
> > Compat), so he had ample time to tell me he didn't like the name
> > "addFile" and to suggest an alternative.
>
> Adding a file and playing a file are two completely different things.
> That's why I "didn't like the name."

Yes, indeed, you didn't like the name, and as I said, you had ample time to 
suggest an alternative.

You could have, very reasonably, used the name addFile, accepted me to update 
the documentation to refer to the behavior that you desire (which is 
basically what I intended when I wrote the API), with the promise that the 
function name would change when we break BC again.  Instead you wanted all or 
nothing.

>
> But here's the issue Charles seems to have forgotten to bring up:  Hayes
> was created and developed in CVS, in kdemultimedia.  But Charles, as
> Noatun maintainer, decided it was unfit for release.  So we moved it to
> kdeaddons.  But Charles also claims that as Noatun maintainer, he decides
> what goes there and what doesn't.  So I cvs removed the app, because after
> three people enabling the app (me, Rob Kaper, Kevin Puetz) it was clear
> that Charles was decided on the matter.  And with the option of separate
> releases available, it wasn't worth it to me to fight.
Well, I believe that kdeaddons isn't any different from a development point of 
view, it's just, when the user installs the software a note that "This is 
even more optional than the optional packages like kdemultimedia and 
kdenetwork"

>
> So, then comes Hayes 1.2, which included some very nice optimizations by
> Carsten Pfeiffer.  Carsten has asked me to return Hayes to CVS, giving me

You saying that Hayes 1.2 has very nice optimizations doesn't change any fact.

> his opinion that Charles doesn't have control over kdeaddons.  Not knowing
> what people think, I asked kde-multimedia for opinions.

And I did not respond because I knew that, for one thing, kde-multimedia has a 
low readership, especially amongst the policy-makers.  We would end up 
arguing about this like we have time and again on IRC.

> So now here we are in kde-policies, with a simple question:  Does the
> maintainer of a plugin-based application have veto power over what plugins
> get included in the release?  And does that veto power carry over to the
> kdeaddons package of extra plugins, too?

And also, how does a kdeaddons module differ from its application's actual 
module?

- -Charles

- -- 
Charles Samuels <charles@kde.org>
"Pacifism implies quite a bit of wisdom" -- Maksim Orlovich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+NcgPWS4Pv66UcxkRAjatAKDF6YZXK2QM9AcO2VEwD6oz4lf0jACgyVZf
lbH4Ph5txri2prrgpoWReeU=
=OypT
-----END PGP SIGNATURE-----