Handling of splitted Calligra repos and API changes

Mon Aug 31 14:38:49 BST 2015

I am OK with Monday. We'd need to adjust to this day when we prepare
releases. E.g. tagging was on Saturday so far, now it would make sense just
after the Monday BIC, right?

Also, am I allowed to delete the kexi-framework* branches in the
calligra.git origin?

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

> 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
>
> _______________________________________________
> 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/d985ab3f/attachment.htm>