3.2 issues :(
Frans Englich
frans.englich at telia.com
Sun Jan 18 09:52:20 GMT 2004
On Sunday 18 January 2004 10:26, Chris Lee wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sunday 18 January 2004 1:59 am, Frans Englich wrote:
> > On Sunday 18 January 2004 08:33, Dawit A. wrote:
> > > On Sunday 18 January 2004 02:10, Frans Englich wrote:
> > > > On Sunday 18 January 2004 08:01, George Staikos wrote:
> > > > > For some reason in HEAD the kicker clock (don't know when this
> > > > > changed) has lost track of the fact that I like to see the date
> > > > > along with the time.
> > > >
> > > > Yupp, that's a feature not a bug, some people would say. I
> > > > changed(with consensus on kde-usability) a couple of weeks ago since
> > > > it was too small and cluttered on 800x600 displays. BTW, you have the
> > > > date as tooltip on clock.
> > >
> > > Please note that not everyone is subscribed to kde-usability.
> >
> > Keeping the maintainer informed is one thing but kde-usability exists for
> > usability issues. If someone is not subscribed for whatever reasons, then
> > that person simply misses the usability discussions, unfortunately. If
> > kde-usability is not ment to be used for its purpose, it should be
> > closed.
>
> Frans,
>
> If you think that you can have a discussion on kde-usability and commit
> based on a consensus there, without discussing the commit with an
> application's maintainer, you are seriously mistaken.
>
> There is no "sick hierarchy" or "corrupted power" involved, it's simply a
> matter of respect which you seem to be lacking here. Changing defaults is
> ok, assuming agreement on the usability list and permission from the
> maintainer to commit, but changing existing settings is not to be done.
> There is a technical framework that exists for this sort of change as well,
> in kconf_update.
Sorry, you're wrong AFAICT. I didn't change the entry's name - only it's
default /value/. I don't know why George's old settings was not kept, perhaps
he started on a fresh .kde, dunno.
>
> You get into a much more difficult situation with unmaintained or
> infrequently maintained applications - much of the apps in kdenonbeta, for
> example - but Kicker is far from unmaintained. And I for one would revoke
> any commits made to a module of mine if people just started committing to
> it without even bothering to point me to discussion about potential
> changes.
>
> This particular example shows a stunning lack of communication with the
> application maintainer, and this is why you are lacking the "respect" that
> you think you deserve. Unless you are the maintainer of the application,
> you should not be committing to it without first at least notifying the
> maintainer, let alone getting their approval. This is nothing new and it
> has been standard practice for as long as I've been involved in KDE (and
> I've violated it a couple of times myself and been rightfully blasted as
> well).
No. Sorry, you misunderstand. I don't think the standard practices of KDE is
wrong, they are fully reasonable. But Dawit says I didn't follow them, which
I clearly did, but most important - he does so on no grounds. My decisions
were fully reasonable, George is not listed in any license headers in
kicker/applets/clock/*, kicker/AUTHORS nor does cvs annotate tell anything
useful for the relevant files. Dawit says I have stepped on the maintainer
while there's nothing which indicates so.
Again, the commit was done by Aaron - I laid the proposal on kde-usability,
people liked it, Aaron said ok and commit'ed it. During the time, I have
submitted it to John Firebaugh(which /is/ the maintainer of Kicker) and when
it was clear Aaron already had commited it - he said OK.
The only thing valid in your mail is the comment on my decision on building an
argument on a kde-usability discussion. But it is nullfied since it was
approved by Aaron(a core hacker) and the Kicker maintainer.
Since you don't know the whole story, just as Dawit, it's not a surprise your
comments are wrong.
Cheers!
Frans
More information about the kde-core-devel
mailing list