Il Gioved=C3=AC 27 Agosto 2015 9:58, Bo= udewijn Rempt <boud@valdyas.org> ha scritto:

Hi,

We had a long discussion on #calligra yesterday, but I don't= know whether
we came to any conclusion... There are a bunch of things w= e have to
consider before moving on after 2.9.7.

I think that the= frameworks branch is now ready to be called 3.0. It's
obviously not rea= dy to release to end users, but we should make it the
new master. But le= t's call it the frameworks branch for now.

I propose that we move al= l feature development (magnetic selection
tool, animation, LOD) to the f= rameworks branch or a branch branched off
frameworks at this point. From= that point on, only bug fixes should
go into 2.9, and each bug fix shou= ld be individually forward-ported
to frameworks

The bigger questi= on is, what are we going to do with the frameworks
branch itself and wit= h our git repo, and with our community?

This is really hard for me, = personally, to formulate, but the truth is,
now that I am sponsored to w= ork on Krita, I cannot afford to spend time
on the rest of calligra if t= hat doesn't directly benefit Krita. I cannot
refactor something in the l= ibraries and then port sheets, because I feel
that would be a misuse of = the money the community has donated.

With the merging of the mvc bra= nch, I already ran into that, and found
that I just couldn't find the h= ours of the day to work on sheets, stage
and the rest. And apparently, n= obody else could find the time.

For the frameworks branch, I do want= to do a big cleanup. I want to make
building krita much easier, and tha= t means cutting down on dependencies,
cutting down on code in libraries = that krita doesn't need. On the other
hand, if I were the words maintain= er, I would like to get rid of stuff
that words doesn't need, like pigme= nt.

Originally, I envisaged our split up repo like:

calligra-= libs
calligra-apps
calligra-plugins
krita
kexi

Or even = split up calligra-libs into a set of repos: that would help with
the dep= endency graph in Linux distributions, where they now make marble
and mys= ql dependencies of Krita...

But in the discussion yesterday, I think= we came to a sort of tentative
conclusion that it doesn't make sense to= push all our libraries into
separate repositories, and that it even doe= sn't make sense to create a
separate calligra-libs.git that could be use= d by the applications.

I am not sure how much of the calligra libs a= re used by Kexi, and whether
sharing the same libraries between Kexi and= the office applications makes
sense. Should kexi go into its own repo?<= br>
For Krita, and I hate to say this, it probably makes sense to fork o= ur
shared libraries. The office-apps maintainers can then strip out all = the
krita-specific stuff, and for Krita, we can strip out the stuff that= only
makes sense for office applications.

I also think that it m= akes sense for Krita to integrate the karbon plugins
and tools, and mayb= e the karbon filters. I honestly don't see any future
for karbon as a se= parate application. You cannot build a good vector drawing
application w= ithout a dedicated maintainer, and Karbon has been officially
unmaintain= ed since April 2013 already.

I'm not really happy writing this mail.= .. But anyway, back to practical
issues. I'd like to start taking steps= next week already.

* split up our git repo whichever we we like
= * ask sysadmin to put our repos up
* update all the build documentation = on community.kde.org to talk
about kf5 and the new repo locations
* u= pdate the information on our websites (not forgetting kde.org)
* ping Da= vid Revoy about updating his build guide
* figure out the release proces= s after the split?

And then start hacking... Thoughts? Flames?
Boudewijn
_______________________________________________
Krita mai= ling list
kimageshop@kde.org
https://mail.kde.org/mailman/li= stinfo/kimageshop


		&nb= sp;	&nb= sp;
Read-only LibreOffice core repo - no p= ull request

Visualizza su github.com	Antepri= ma per Yahoo

=