Handling of splitted Calligra repos and API changes

[Friedrich W. H. Kossebau]

Am Montag, 31. August 2015, 12:46:30 schrieb Jaroslaw Staniek:
> 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.

Sounds like that could work without getting in the way, good idea. Even with 
added value to have the buildsystem properly warn. So such tags would be kind 
of internal development releases of the repos :)
Would be some added maintenance though, who will care to add the tags every 
week? The maintainers of the repos? The person doing the BIC commits?

> 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.

Sure. Just, the BIC-day thing is about being able to build the whole galaxy in 
a repo, and only the building. Because that is the minimum requirement to do 
development :) Which is also reflected in the policy to try to never have 
build-breaking commits.
Bugs in apps being only fixed in the libs is also something we have had with 
kdelibs + kdeapps, still the BIC-day helped in general. A small price to pay 
here when having to wait half-a-week in average until that fix can be expected 
with your fellow devs, but worth the reduced updating hassle in general.

Okay, so seems I got us settling on the BIC day, with noone objecting to that 
otherwise :) For the initial start it would be informal, soon to be supported 
by that tag system (will help to implement it, please ping me for that after 
Sep. 21th), and perhaps one day even with a more elaborated system, as 
sketched by you. Thanks.

So from my POV there is no further hurdle to merge kexi-frameworks branch 
finally into master :) Seems noone else had any objection as well, now that 
feature development is officially over in 2.9. Please don't forget to also 
remove all the intermediate branches you used.

Oh, and we need to agree on a day. I would propose
	 Monday
given most of us have most time on a week-end, and then could commit their BIC 
right after that. Having the BIC day on the week-end itself would only result 
in the problem we try to avoid here, i.e. requiring people to update more 
during the day then the repo they work on, because API changed.
Boud proposed Saturday morning, but reducing to part of a day might be too 
strict, as not everyone can control exactly when they have time during the day 
to sneak at the computer for their hobby :)
Monday also seemed to have worked for the KDE BIC-day.

Anyone objects to Monday? Otherwise starting next week that would be the day 
:)

Cheers
Friedrich