App duplication again (Re: new project in kdemultimedia)

Neil Stevens neil at qualityassistant.com
Mon May 6 14:49:20 BST 2002


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

This really is winding down, but a couple things I do have to address:

On Monday May 06, 2002 06:26, Thomas Diehl wrote:
> Am Montag, 6. Mai 2002 13:27 schrieb Neil Stevens:
> > Well, if it's all or nothing from the translators, as you are
> > portraying their view, then there really isn't a way to avoid it.
>
> I would appreciate it if you stop putting words in my mouth.

You wrote to Waldo:

"Hmm, depends on what you call a problem. But I could imagine that many 
people won't be too enthusiastic when translators and documenters go on 
strike and produce 60+ messages threads every time something like this 
happens again."

I think I summarized that sentiment accurately. Threatening to "strike" 
"every time something like this happens again" is an all-or-nothing 
approach.  I'm not saying it's unreasonable to take that action, though.  
I'm just saying it leaves little room for a fair compromise.





 I
> explicitely said that I wouldn't want to discourage rewrites,
> experimenting, having "maybe" 2 apps with overlapping functionality and
> so on. But, yes, I'm against "an unlimited number of apps with almost
> the same functionality". Is really somebody _for_ this?

No, nobody is for that, but that's irrelevant as we're not faced with that 
situation.  These CD writers *aren't* the same.  The actual functionality 
is all contained with cdrecord, please do understand that.  These 
applications' entire code is dedicated to user interface to that backend.  
Some differ markedly in their user interface design.  The result is that 
they overlap a lot less than what looking at the messages in KBabel will 
lead one to conclude.


>
> There seems to be one breaking point, however. Waldo put his view this
> way:
>
> ---
> I rather see people working together on one truely great app. However,
> if that, for whatever reason, doesn't happen, then I see no problem in
> having multiple apps with overlapping functionality in CVS.
> ---
>
> This is noble. But it is the point where I have to disagree. For my
> part, I would want to know why people don't work together in CVS as soon
> as they are _massively_ starting to duplicate functionality without any
> clear technical reason (such as a necessary rewrite). And _if_ it comes
> down to just people who cannot play along then I would not be prepared
> to just leave it at that forever, saying "whatever reasons they have,
> let them have it their way, no matter if we end up with 5 almost
> identical apps". I would start looking for a way to solve this. And also
> I would not import 2,3, or more almost identical apps to CVS _before_
> people made it clear that they were at least willing to cooperate with
> each other.
>
> There will always be problems to play along with certain people for
> almost everybody and there might not always be a way out. But if I'm not
> willing to cooperate at all even on the same functionality what am I
> doing here? Why make this a problem to 50 translation teams,
> documenters, and a lot of other people? The biggest surprise to me is
> that we really have an argument about this. After all, this is a team
> effort, isn't it?
>
> > I've proposed
> > that the translators simply skip the apps they don't want to
> > translate.
>
> Yes. And about everybody who replied told you that this is not an
> option. This won't change just by repeating it over and over.

Yes, several people replied to that idea, but few said anything worth 
reading.  Offtopic personal questions about my language skills were made 
in reply to me.  Nonsensical hypotheticals about changing the default 
language were proposed in reply to me.  Unwarranted accusations about how 
I value the translations were made in reply to me.  The only reply of 
substance was that it would "look bad."

Given the poor quality of debate on this proposal, I don't think it was 
given a fair consideration, and therefore I don't think it's right to 
dismiss it yet.

> > What portion of the KDE decision making process isn't transparent?
>
> I'm not under the impression that the import of K3b into CVS happened
> after any thorough discussion as proposed in the posting I referred to.
> But maybe I missed something.

Someone (I think David) wrote at one point  that kdenonbeta isn't some 
required stopover before importing an app.  I think this kind of sentiment 
is what you missed, in thinking that there was supposed to be some big 
discussion before one app gets imported.

With 3.0.1 at hand, we're just now at the beginning of the full steam 3.1 
development cycle.  Now is the time to develop and create (even with a 
little recklessness).  Later, when the betas near, will be the time to 
evaluate what is actually mature for release.

Thanks for your well-thought-out, intelligent, civil replies, whether this 
thread continues or not.

- -- 
Neil Stevens - neil at qualityassistant.com
"I always cheer up immensely if an attack is particularly wounding
because I think, well, if they attack one personally, it means they
have not a single political argument left." - Margaret Thatcher
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE81ongf7mnligQOmERAvw6AKCU4prvvE8GRfQuGf5fwL7wHGarNACdFnCD
HYuY8q9ZhHQ5oRUygCwZfS0=
=llXg
-----END PGP SIGNATURE-----





More information about the kde-core-devel mailing list