Moving plan into separate repository

[Jaroslaw Staniek]

On Mon, 29 Oct 2018 at 09:01, Dag <danders at get2net.dk> wrote:

>
> I'm looking into this to simplify releases, same as you have done with
> kexi.
> I hoped you had some hints for me, I haven't got much help from
> sysadmins,
> so I'm wondering what do they need to do and what do I need to do?


Hello Dag

1. Click sysadmin request on Phabricator to request the repo as the
maintainer

https://phabricator.kde.org/maniphest/task/edit/form/2/

2. Most of the work was for me related to extracting git history. Work
*locally* until you are happy with the history.
Have someone to review it. Your project does not need to build prior to
first push but better have correct history / git blame. You have some work
(can take even 24h of computation locally on your machine). Please see GIT
SURGERY at https://community.kde.org/Kexi/Porting_to_Qt%26KF_5

3. Also please see this entire thread and 3rd post especially:
https://mail.kde.org/pipermail/kexi-devel/2015-February/000247.html

4. Example for KProperty extraction: I succeeded with this - created two
parts of history because in
the days of koffice lib/ was renamed to libs/:

git  filter-branch -f --subdirectory-filter libs/koproperty/ -- kproperty
git  filter-branch -f --subdirectory-filter lib/koproperty/ -- kproperty-lib
then:
git rebase --root --preserve-merges --onto kproperty-lib

This shows type of renames you may want.
Your root dir is going to have src/ subdir etc., so everything is moving.
Same goes to test dirs.
All depends on how clean history you want, KEXI's is tracked sown to
pre-git times, April 1998 :)

5. Moving/simplifying/copying of some Calligra's cmake magic script and
automatism. They are going to be simplified so developers are not confused
that they build entire calligra. Remove as many unused files as possible.

6. Please note that KEXI had no dependencies on calligra/libs/ (apart from
one optional plugin) due to the fact that is it is a very different type of
app. Since you have them you need to design how the dependencies will be
built: so far Calligra neither export them nor maintain BC for them
especially. Once you are on the outside with Plan you have to depend on
releases of Calligra anyway or make them in another repo (!) and have
someone maintain them (which would be awesome).
I say that is needed unless you copy these dependencies (if they are large
this can be against the principles) or remove them (may be impossible or
not practical depending on how large the dependencies are, Krita looks like
a similar case to me and it has managed to separate from them).

7. Optional: Plan can obsolete entire Calligra package in the distros since
there are going to be the same files installed by current calligra.git and
the plan.git. You can make sure your new files are unique on a distro and
bump version or even rename all installed files so there's zero conflict
with the "old" Plan from Calligra. I went further and implemented
side-by-side install-ability for KEXI - across all minor versions.

Regards, Jarek.



-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
KEXI:
: A visual database apps builder - http://calligra.org/kexi
  http://twitter.com/kexi_project https://facebook.com/kexi.project
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20181029/1289547a/attachment.htm>