Moving kdcop

Frans Englich frans.englich at telia.com
Tue Feb 3 16:19:38 GMT 2004


On Tuesday 03 February 2004 12:26, you wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 3 Feb 2004 10:09 am, Frans Englich wrote:
> > On Monday 02 February 2004 23:41, Brad Hards wrote:
> > > On Tue, 03 Feb 2004 09:21 am, Frans Englich wrote:
> > > > I want kdcop in kdesdk to reduce KDE forking.
> > >
> > > I'm not sure I understand. Why does moving a bit of code from one KDE
> > > module to another prevent forking (as in
> > > http://people.kldp.org/~eunjea/jargon/?idx=forked)?
> >
> > Yes, that's my definition(good idea to check this).
>
> Then can you please explain how moving it from one module to another can
> prevent two development activities?
>
> > > If you mean you are trying to influence distributions:
> >
> > I'm not, I'm trying to make KDE be more like distributors want it. Feel
> > free to quote where I indicated that.
> >
> > > 1. That is outside KDE's charter, see:
> > > http://www.kde.org/download/packagepolicy.php
>
> Changing CVS to work with packagers is still a secondary issue, and you
> haven't provided any evidence that any packagers actually want this (or
> care enough to rework their stuff).
>
> > > 2. You are creating work for them and us, for little or no gain.
> >
> > (and that's why this is irrelevant, AFAICT)
>
> You need to explain what "this" means (the work? the move? the gain?) since
> your comment is ambiguous.
>
> > > 3. It probably won't work anyway - if they had a kdcop package in
> > > previous releases, they'll likely want to have one in this release too.
> >
> > Assuming it's a conscious decision - that is, if they know what every
> > cryptic dir in our packages means, and manages to keep up to date with
> > what goes on in KDE development.
>
> The major distro packagers know what they are packaging. Everyone else just
> picks a RPM spec or Debian equivalent file, and changes the name :-)
>
> > Well, there's many reasons to why it's a Good Thing to have the vanilla
> > version as users wants it. And forking is Bad.
>
> You haven't provided any evidence or analysis showing that the way we
> currently have it is not the way the user wants it - how could the current
> location be a problem, given that most users don't know how CVS is
> organised in any case?
> Any the concept of reducing code forking by relocating from one module to
> another still doesn't make any sense.
>
> Basically there is no upside for anyone in such a move.

Yes, you may think so.

Frequently people object to why we should care about what we have in our 
modules, about our defaults etc, and how it all hangs together with 
distributors, and KDE.. I'm so sick of discussing it so I will address it in 
one place(kdedevelopers.org or something like that) so it can be peer 
reviewed and settled once and for all. That is, instead of responding to this 
mail. Is that ok with you?

Cheers,

		Frans



>
> Brad
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
>
> iD8DBQFAH4VKGwwszQ/PZzgRAg7FAKCBwvKk6R8E1lqVsWHXZos0zR3LHACfb/nP
> kIHIu2H2vt05AikRIhro3xk=
> =kxnB
> -----END PGP SIGNATURE-----




More information about the kde-core-devel mailing list