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

List:       koffice-devel
Subject:    Re: koffice/libs/flake
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2009-12-17 20:05:51
Message-ID: 200912172105.51324.t.zachmann () zagge ! de
[Download RAW message or body]

On Thursday 17 December 2009 19:15:00 Thomas Zander wrote:
> On Thursday 17. December 2009 15.17.31 Thorsten Zachmann wrote:
> > > This was discussed with Jan and agreed on. You are not in the copyright
> > >  list, so I didn't talk to you, no.
> >
> > Still if you would have send a mail on the list everybody could have
> > given its  opinion.
> 
> True, thats possible.
> At the same time these classes are from 2003 and there still is only one
> implementation.
> Sending a mail for each of the, what, 30 refactors I did over the last
>  couple of weeks to the list is not practical, I hope you agree. And I did
>  talk to others, so this is not a sole operation here.

I did not ask to do that for every change. Still for a change like that I 
think it would be a good idea.

> No code is removed, the refactor was agreed on and I don't think it makes a
> lot of sense to have an abstract baseclass purely on the "it may be used
>  soon" premise. Again, no code is removed, a refactor to add the virtuals
>  can be done in the future and takes you no more than 10 minutes. So lets
>  do it when we actually need it.

I don't see how 500 lines of code are some pure virtuals. I talk about 
bringing the base class the commit removed back to existence as it will be 
needed for the line ends. As I said I'm fine if it is not exported as it will 
be used in flake only. If we find out in future it will be needed somewhere else 
it can be exported. 

> 
> Thinking a bit more about this thread;
> Let me write down something I've been thinking is obvious, it may not be at
> all and only live in my head. So I'll make sure its clear, especially for
>  the people that were not in the Oslo meeting.
> 
> We should get a clean API for flake + libodf at least. A clean API means
> minimum exported symbols since those can't be changed, ever, after we
>  freeze the libraries for 3rd party devs to work on. And then when any new
>  API is needed in flake we should take care to only commit that when its
>  done. Develop it in a public branch if its bigger, if you want.
> Done means it passes all the library-commit-policies (on techbase) and it
>  has had at least one round of API-review.
> 
> All people I talked to so far think thats a good idea since its a proven
>  way of working and it helps with making sure the library we ship and say
>  will stay SC+BC actually will be maintainable and even fun to work on
>  without breaking that promise.
> 
> Does everyone like this? Have problems with the goals?
> Let me know why, please :)

I don't have problems with the goals. That is all fine. 

However I thinkthere are other parts of koffice which could use work and would 
help the users of koffice much more than to have a stable API. I personally 
don't see that we gain much by this. 

Thorsten
_______________________________________________
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]