libkwidgets (Re: patches on kcolors)
Giorgos Tsiapaliwkas
terietor at gmail.com
Wed Apr 11 12:21:59 UTC 2012
On 11 April 2012 14:55, Stephen Kelly <steveire at gmail.com> wrote:
>
> It's not clear which patch you're talking about. As far as I can see, you
> didn't really post the patches individually, but just posted the moevs that
> you made along with the CMakeLists changes you made (as one patch).
>
yes it is one patch because I don't see why I should split this patch into
more.
I did them all in one patch because they depend on each other.
> I'd suggest you try to move fewer things at once and make sure the entire
> branch builds (not just the parts you move). You want to move the things at
> the bottom of the dependency tree first.
>
I can't due to the buildsystem. Every move that I make creates a lot of
undef refs.
> Yes, you can post the patches here for review. The best would be to use git
> show -M -C <sha1> to create the patches so we can review them and I can do
> a
> build to make sure it builds.
What's the difference from what I am doing?
I copy&paste the moves and I give you the diff which has the changes.
> Probably not. Lets review it first.
ok, I am waiting :)
> >
> > Have you seen my issue about splitting?
> > Also with all this cherry pick now we can't merge my branch. Right?
>
> It's better that I cherry pick from your branch so that history remains
> buildable, or that you move files, post patches for review, I'll do a test
> build, and one of us push the result.
>
I agree, I think that its better if you make the cherry pick.
> I'm still not sure I understand the goals of your moves though. What
> classes
> do you still want to move? Do you have some kind of plan, or are you just
> trying to move everything from kdeui a few classes at a time? Why not just
> rename kdeui? Why rename kdeui? Do you plan on addressing any of the causes
> of interdependencies?
>
my work here at the frameworks started at the first KF day, you told me to
do it like this
and I did.
> I'd suggest that a better contribution would be to analyse what
> dependencies
> exist and why. For example, look at KLed. It depends on the colors stuff
> that is now in kdeguiaddons. Does it need to?
I don't consider me as the best person for this work. Why?
Because I don't trust my decisions, our frameworks is a heavy job and I
can't take such calls.
Also in order to this I have to study all that code, which requires a lot
of time and I don't volunteer for
that. I prefer someone who has the appropriate experience to tell me what
to do.
Regards,
Giorgos
--
Giorgos Tsiapaliwkas (terietor)
KDE Developer
terietor.gr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120411/da20a255/attachment.html>
More information about the Kde-frameworks-devel
mailing list