<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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?<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Also, am I allowed to delete the kexi-framework* branches in the calligra.git origin?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 31 August 2015 at 15:32, Friedrich W. H. Kossebau <span dir="ltr"><<a href="mailto:kossebau@kde.org" target="_blank">kossebau@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Am Montag, 31. August 2015, 12:46:30 schrieb Jaroslaw Staniek:<br>
> Partial response, no time for more now.<br>
><br>
> On 31 August 2015 at 12:15, Friedrich W. H. Kossebau <<a href="mailto:kossebau@kde.org">kossebau@kde.org</a>><br>
><br>
> wrote:<br>
> > Am Montag, 31. August 2015, 02:29:29 schrieb Jaroslaw Staniek:<br>
> > > >> For people building largely by hand, I'd introduce a support for<br>
> > > >> specific case: a<br>
> > > >> find_package wrapper that checks if the dependency has an exact git<br>
> > > >> revision. That's like an assertion that tells you that your deps are<br>
> > > >> too old (or too new, or even from incompatible branch - use git to<br>
> > > >> find out). (I already offer the git revision information for kdb.git,<br>
> > > >> etc. and believe providing it even in --help for apps is a good thing<br>
> > > >> in modern times).<br>
> > > ><br>
> > > > Tagging a certain devel state with the main development branch sounds<br>
> ><br>
> > like<br>
> ><br>
> > > > an interesting solution. Just, how would that be integrated in<br>
> > > > people's<br>
> > > > workflow? How does the git revision info get from e.g. Calligra's<br>
> > > > CMakeLists.txt into the commands that fetch stuff from those separate<br>
> > > > repos, and then also make sure the certain version is checked out,<br>
> ><br>
> > build<br>
> ><br>
> > > > and installed?<br>
> > ><br>
> > > When we build we have set up a list of dirs: builddir, source dir and<br>
> > > prefix dir.<br>
> > > So while building, the sourcedir is known and build-dependency<br>
> > > checking can look into the sourcedir to know the required versions.<br>
> > > (Actually similar tool could update the cmake file for me when I as a<br>
> > > developer want to bump up the dependent versions; that's not needed<br>
> > > for every commit though)<br>
> ><br>
> > Under the line, that sounds like a complicated system to me, with the need<br>
> > for<br>
> > utils which are yet to be written.<br>
> > More, it will only work for those who adapt to that system. What about<br>
> > 3rd-<br>
> > party apps that want to develop again master branch of kdb? But use qmake?<br>
> > Or<br>
> > some other custom build system?<br>
> ><br>
> > What about using KProperty and KReport as testing ground for now for the<br>
> > approach you are proposing?<br>
><br>
> ​+1 or look below<br>
> ​<br>
><br>
> > > > Also having to adapt the revision info any time one works on the<br>
> ><br>
> > external<br>
> ><br>
> > > > repos (with changing commit ids) smells like a lot of painful work,<br>
> > > > not<br>
> > > > only because due to waiting for cmake to finish reconfiguring :/<br>
> > > ><br>
> > > > So, interesting idea, but needs proof it stays the daily workflow for<br>
> ><br>
> > me<br>
> ><br>
> > > > :)<br>
> > ><br>
> > > The idea addresses a case that may or may not be a corner case,<br>
> > > depends on developer.<br>
> ><br>
> > For the start, for now, in current Calligra master I would like to propose<br>
> > to<br>
> > apply the BIC-day approach.<br>
><br>
> I am all for known workflows that cause no stress or wtf moments.<br>
> I understand developers want to be sure they have the "current" code.<br>
><br>
> ​<br>
> ​The BIC days can work, the change from the above proposal would be then:<br>
> use a year+week number or so instead of git revision or cross-repo tag<br>
> name. The year+week number is a cross-repo too of course. It can be checked<br>
> at cmake level that during development branch we have too old deps such as<br>
> kreport/kdb/etc.<br>
<br>
</div></div>Sounds like that could work without getting in the way, good idea. Even with<br>
added value to have the buildsystem properly warn. So such tags would be kind<br>
of internal development releases of the repos :)<br>
Would be some added maintenance though, who will care to add the tags every<br>
week? The maintainers of the repos? The person doing the BIC commits?<br>
<span class=""><br>
> It's also all about one more thing. Even given that API/ABI is carefully<br>
> maintained, behaviour can change or fixes can appear in dependencies such<br>
> as kreport.git. Sometimes a bug in Kexi gets in fact fixed by kreport.git<br>
> commits only.<br>
<br>
</span>Sure. Just, the BIC-day thing is about being able to build the whole galaxy in<br>
a repo, and only the building. Because that is the minimum requirement to do<br>
development :) Which is also reflected in the policy to try to never have<br>
build-breaking commits.<br>
Bugs in apps being only fixed in the libs is also something we have had with<br>
kdelibs + kdeapps, still the BIC-day helped in general. A small price to pay<br>
here when having to wait half-a-week in average until that fix can be expected<br>
with your fellow devs, but worth the reduced updating hassle in general.<br>
<br>
Okay, so seems I got us settling on the BIC day, with noone objecting to that<br>
otherwise :) For the initial start it would be informal, soon to be supported<br>
by that tag system (will help to implement it, please ping me for that after<br>
Sep. 21th), and perhaps one day even with a more elaborated system, as<br>
sketched by you. Thanks.<br>
<br>
So from my POV there is no further hurdle to merge kexi-frameworks branch<br>
finally into master :) Seems noone else had any objection as well, now that<br>
feature development is officially over in 2.9. Please don't forget to also<br>
remove all the intermediate branches you used.<br>
<br>
Oh, and we need to agree on a day. I would propose<br>
         Monday<br>
given most of us have most time on a week-end, and then could commit their BIC<br>
right after that. Having the BIC day on the week-end itself would only result<br>
in the problem we try to avoid here, i.e. requiring people to update more<br>
during the day then the repo they work on, because API changed.<br>
Boud proposed Saturday morning, but reducing to part of a day might be too<br>
strict, as not everyone can control exactly when they have time during the day<br>
to sneak at the computer for their hobby :)<br>
Monday also seemed to have worked for the KDE BIC-day.<br>
<br>
Anyone objects to Monday? Otherwise starting next week that would be the day<br>
:)<br>
<div class="HOEnZb"><div class="h5"><br>
Cheers<br>
Friedrich<br>
<br>
_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">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>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</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>