'Re: About libraries...'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: koffice-devel
Subject: Re: About libraries...
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2009-09-01 16:48:06
Message-ID: ae32c1ef0909010948h4b9ca38ta5d63b653fbb4caf () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

>
> > I would make it certainly much more visible what everyone is working on
> > while they are working on it -- right now, if there is something big
> going
> > on nobody really knows unless you talk about it on irc or the mailing
> list.
>
> Perhaps this would be something to consider in the near future planning
> then?
> The Amorok developers seem to be very happy having moved to git.  And it
> does
> seem like it would help to minimise this kind of conflict.  If tools can do
> that then there is even more patience to go into coding ;-)
>

I don't think that a tool can solve any communication problems. =)

I think we have two problems here:
The first,
* we don't have any way to know "who does what" at the moment,

the second is a parent of the first one:
* we don't do enough architectural planning in our work (in my opinion).

One example (that's part of the patch i'm working on atm): layers subsystem.
In my opinion it lacks of initial architectural planning. And it introduces
many problems. If you take a look how masks are applied to layers, you see
that *the same code is duplicated* in **every** type of layer. More than
that this code seems to have been modified after it's initial duplication
for several times. BUT not all clones was updated during these
modifications. This created completely unmaintainable code. If we had
planned masks application while creation of KisLayer (or while introducing
masks themselfs) we would have moved all that code into KisLayer and this
would have made things much more easy.

We get almost the same problem here. We don't have a complete, approved by
everyone, plan of library reorganization. If we had one, the things would be
much easier. And, in my opinion, code freeze just delays the problem, not
solves it.

In my opinion, you both should just publish your own look into Ko libraries
as a whole. But it should be a COMPLETE library design proposal. Not just
"widgets should be stored in a separate/joint library" statement. Then it'll
be easier for you to discuss pros and cons of both solutions, choose one
(and the only one) and follow it all the way.

I think this is the way how devs should communicate =).

So, git is not a solution for that. Maybe UML?

PS:
Btw, does anyone work on layers, visitors, update strategies atm? If so, we
should discuss it too =)

-- 
Dmitry Kazakov

[Attachment #5 (text/html)]

<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div \
class="im"> &gt; I would make it certainly much more visible what everyone is working \
on &gt; while they are working on it -- right now, if there is something big \
going &gt; on nobody really knows unless you talk about it on irc or the mailing \
list. 
</div>Perhaps this would be something to consider in the near future planning \
then? The Amorok developers seem to be very happy having moved to git. And it \
does seem like it would help to minimise this kind of conflict. If tools can \
do that then there is even more patience to go into coding \
;-) </blockquote><div> I don&#39;t think that a tool can solve any \
communication problems. =) I think we have two problems here: The first, \
 * we don&#39;t have any way to know &quot;who does what&quot; at the moment, \
 the second is a parent of the first one: * we don&#39;t do enough \
architectural planning in our work (in my opinion). One example (that&#39;s \
part of the patch i&#39;m working on atm): layers subsystem. In my opinion it \
lacks of initial architectural planning. And it introduces many problems. If you take \
a look how masks are applied to layers, you see that *the same code is duplicated* in \
**every** type of layer. More than that this code seems to have been modified after \
it&#39;s initial duplication for several times. BUT not all clones was updated during \
these modifications. This created completely unmaintainable code. If we had planned \
masks application while creation of KisLayer (or while introducing masks themselfs) \
we would have moved all that code into KisLayer and this would have made things much \
more easy. We get almost the same problem here. We don&#39;t have a complete, \
approved by everyone, plan of library reorganization. If we had one, the things would \
be much easier. And, in my opinion, code freeze just delays the problem, not solves \
it. In my opinion, you both should just publish your own look into Ko \
libraries as a whole. But it should be a COMPLETE library design proposal. Not just \
&quot;widgets should be stored in a separate/joint library&quot; statement. Then \
it&#39;ll be easier for you to discuss pros and cons of both solutions, choose one \
(and the only one) and follow it all the way. I think this is the way how \
devs should communicate =). So, git is not a solution for that. Maybe \
UML? PS: Btw, does anyone work on layers, visitors, update strategies \
atm? If so, we should discuss it too =) </div></div> -- Dmitry \
Kazakov

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread] 