<div dir="ltr"><div dir="ltr"><div dir="ltr"><span class="gmail_default" style="font-family:monospace,monospace"></span>On Mon, 29 Oct 2018 at 09:01, Dag <<a href="mailto:danders@get2net.dk" target="_blank">danders@get2net.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>I'm looking into this to simplify releases, same as you have done with <br>kexi.<br>I hoped you had some hints for me, I haven't got much help from <br>sysadmins,<br>so I'm wondering what do they need to do and what do I need to do?</blockquote><div> </div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Hello Dag</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">1. Click sysadmin request on Phabricator to request the repo as the maintainer<br></div><div class="gmail_default"><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace"><a href="https://phabricator.kde.org/maniphest/task/edit/form/2/">https://phabricator.kde.org/maniphest/task/edit/form/2/</a></font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">2. </font><span style="font-family:monospace,monospace">Most of the work was for me related to extracting git history. </span><span style="font-family:monospace,monospace">Work *locally* until you are happy with the history. </span></div><div class="gmail_default"><span style="font-family:monospace,monospace">Have someone to review it. </span><span style="font-family:monospace,monospace">Your project does not need to build prior to first push but better have correct history / git blame. </span><span style="font-family:monospace,monospace">You have some work (can take even 24h of computation locally on your machine). Please see GIT SURGERY at <a href="https://community.kde.org/Kexi/Porting_to_Qt%26KF_5">https://community.kde.org/Kexi/Porting_to_Qt%26KF_5</a></span></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><div class="gmail_default" style="font-family:monospace,monospace">3. Also please see this entire thread and 3rd post especially:<br></div></div><div class="gmail_default"><font face="monospace, monospace"><a href="https://mail.kde.org/pipermail/kexi-devel/2015-February/000247.html">https://mail.kde.org/pipermail/kexi-devel/2015-February/000247.html</a></font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">4. Example for KProperty extraction: I succeeded with this - created two parts of history because in</font></div><div class="gmail_default"><font face="monospace, monospace">the days of koffice lib/ was renamed to libs/:</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">git  filter-branch -f --subdirectory-filter libs/koproperty/ -- kproperty</font></div><div class="gmail_default"><font face="monospace, monospace">git  filter-branch -f --subdirectory-filter lib/koproperty/ -- kproperty-lib</font></div><div class="gmail_default"><font face="monospace, monospace">then:</font></div><div class="gmail_default"><font face="monospace, monospace">git rebase --root --preserve-merges --onto kproperty-lib</font></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">This shows type of renames you may want.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Your root dir is going to have src/ subdir etc., so everything is moving. Same goes to test dirs.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">All depends on how clean history you want, KEXI's is tracked sown to pre-git times, April 1998 :)</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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).</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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).<br></div></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Regards, Jarek.<br></div></div><br><div class="gmail_quote"><div dir="ltr"><br></div></div><div><br></div>-- <br><div dir="ltr" class="m_3517180986050710788gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>KEXI:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>  <a href="http://twitter.com/kexi_project" target="_blank">http://twitter.com/kexi_project</a> <a href="https://facebook.com/kexi.project" target="_blank">https://facebook.com/kexi.project</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div></div></div></div></div></div>