Handling of splitted Calligra repos and API changes

Mon Aug 31 11:46:30 BST 2015

Partial response, no time for more now.

On 31 August 2015 at 12:15, Friedrich W. H. Kossebau <kossebau at kde.org>
wrote:

> Am Montag, 31. August 2015, 02:29:29 schrieb Jaroslaw Staniek:
> > >> For people building largely by hand, I'd introduce a support for
> > >> specific case: a
> > >> find_package wrapper that checks if the dependency has an exact git
> > >> revision. That's like an assertion that tells you that your deps are
> > >> too old (or too new, or even from incompatible branch - use git to
> > >> find out). (I already offer the git revision information for kdb.git,
> > >> etc. and believe providing it even in --help for apps is a good thing
> > >> in modern times).
> > >
> > > Tagging a certain devel state with the main development branch sounds
> like
> > > an interesting solution. Just, how would that be integrated in people's
> > > workflow? How does the git revision info get from e.g. Calligra's
> > > CMakeLists.txt into the commands that fetch stuff from those separate
> > > repos, and then also make sure the certain version is checked out,
> build
> > > and installed?
> >
> > When we build we have set up a list of dirs: builddir, source dir and
> > prefix dir.
> > So while building, the sourcedir is known and build-dependency
> > checking can look into the sourcedir to know the required versions.
> > (Actually similar tool could update the cmake file for me when I as a
> > developer want to bump up the dependent versions; that's not needed
> > for every commit though)
>
> Under the line, that sounds like a complicated system to me, with the need
> for
> utils which are yet to be written.
> More, it will only work for those who adapt to that system. What about 3rd-
> party apps that want to develop again master branch of kdb? But use qmake?
> Or
> some other custom build system?
>
> What about using KProperty and KReport as testing ground for now for the
> approach you are proposing?
>

+1 or look below

>
> > > Also having to adapt the revision info any time one works on the
> external
> > > repos (with changing commit ids) smells like a lot of painful work, not
> > > only because due to waiting for cmake to finish reconfiguring :/
> > >
> > > So, interesting idea, but needs proof it stays the daily workflow for
> me
> > > :)
> >
> > The idea addresses a case that may or may not be a corner case,
> > depends on developer.
>
> For the start, for now, in current Calligra master I would like to propose
> to
> apply the BIC-day approach.
>
>
I am all for known workflows that cause no stress or wtf moments.
I understand developers want to be sure they have the "current" code.

The BIC days can work, the change from the above proposal would be then:
use a year+week number or so instead of git revision or cross-repo tag
name. The year+week number is a cross-repo too of course. It can be checked
at cmake level that during development branch we have too old deps such as
kreport/kdb/etc.

It's also all about one more thing. Even given that API/ABI is carefully
maintained, behaviour can change or fixes can appear in dependencies such
as kreport.git. Sometimes a bug in Kexi gets in fact fixed by kreport.git
commits only.

One thing is that if for tag 201540 (2015, Week 40) there were no commits
for kreport, we would need to add a tag anyway. Not an overhead I guess? In
2 years we'd end up with about 100 tags, that's all :)

> So a Stage&Flake-concentrated developer only has to pull kdb, kproperty &
> kreport on one day in the week, to always stay with a building master.
>
> Once there is a working alternative, which is understood and has working
> utils, we can switch to that any time.
>

> Yue, Camilla, Leinir, Zagge, Tomas, what is your take on this?
>
> Cheers
> Friedrich
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
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/20150831/2b3c9d38/attachment.htm>