On Mon, 29 Oct 2018 at 09:01, Dag <dand...@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
