Craft Stable

[Thomas Friedrichsmeier]

Hi,

On Thu, 18 May 2017 14:59:07 +0200
Hannah von Reth <vonreth at kde.org> wrote:
> On 18/05/2017 10:29, Thomas Friedrichsmeier wrote:
[...]
> > Some questions:
> > - Does it cache sources (perhaps at least for "archive" downloads,
> > might be difficult for version controlled sources)? I think one of
> > the most common causes of build breakage (esp. breakage over time)
> > has been upstream moving their downloads around, or even removing
> > some downloads, entirely.  
> We will package also all tool to archive a full KD5 build.
> Packaging sources isn't planned as for most targets we use tarballs
> and patches.
> A build can be reproduced by using Craft, re uploading all KF5
> tarballs and Qt tarballs wouldn't add much value.

What I was thinking about was "what if I try to build using a non-cached
compiler/architecture three months after the release?" In the past
something similar often meant some of the _downloads_ would fail for
being (re-)moved upstream. So I was wonderings, whether it would be
feasible to cache those upstream tarballs. Not the KF5 and Qt ones, but
libssl, dbus, icu, etc.

Not the most pressing matter, I agree.

> > - What's the workflow / commit policy? Are the stable branches to be
> >   considered "frozen", or to what degree? Is it ok to update
> > extragear applications to new versions, for instance? Is it ok to
> > patch for compilation with a non-default compiler? Is it ok to
> > patch for non-critical stuff?  
> Commits to extragear are welcome also changes to KDE Applications.
> I'd see the frameworks category as semi frozen, only reviewed patches
> can be applied there and only if they are really needed.
> So everything that's cached is semi frozen.
> Updating a 3party lib won't happen besides a severe security issue.
> 
> > - I suppose the current "stable" branch is "the branch that will
> >   become the _next_ version of the SDK (aka Qt5.6.2/KF5.33.0 or
> >   whatever). How does this relate to master, then? Or is "stable"
> > just a placeholder label until the branch naming has been decided
> > on?  
> The branch is a place holder as soon as 2017.05 is branched the stable
> branch will change again.
> Currently the only difference in the stable branch are some patches
> and the default targets for the recipes.
> Maybe dev would be a better name for the stable branch, I don't know.
> The stable branch is meant to be the next release.

Ok. I suppose any naming scheme is ambiguous. Still wondering a bit
about master vs. stable. For generic work on portage should I commit to
stable, and cherry-pick to master (or vice versa)? While master is
for ... anything that does not yet seem ready for the next release?

> > - What - besides voting on the poll - can we do to help? Now, and in
> >   the long run?  
> Besides voting. For now please try to use craft stable, I uploaded a
> new cache this morning and I plan to do the release this week.
> The cache should work, but there still might be some issues, so pls
> build some applications also some qmake projects with the stable
> branch.

Craft stable seems to work *really* well for me, so far. I certainly
don't recall ever building kdelibs4/KF5 on Windows without some kind
of manual intervention, before. Great! Some notes:
- Perhaps the craft setup script could give a hint as to which
  platforms are build-cached, or simply mention the fact that some are
  cached, and some are not. I went through most of a MinGW-32 build,
  thinking the cache feature simply wasn't online, yet, before I
  figured it out...
- Perhaps it was extraordinary bad luck, but somehow craft had cached a
  NULL for the build cache's manifest.json. That kept the cache
  disabled on my second attempt, too. Perhaps it would be worth
  decreasing the json cache lieftime from one day to one or two hours.
  It's not like _this_ is causing a whole lot of traffic, I guess.
- After setting up craft a few times, I ran into some interesting
  problems due to inconsistent drive letter substs. Problem is that if
  the drive letter substitutions already exist, then simply calling
    subst R: somewhere
  does not have any effect. You have to do
    subst R: /D
  first.

> After the release we need to upgrade the KF5 and application versions
> maybe update a few 3rd party libs, but the most important step will be
> to  make sure that the current kf5 tarballs are OK. Of course adding
> and fixing recipes for KDE Applications is also important and welcome.
> 
> Well and if everything works, please spread the word after the release
> and make KDE devs to support the Windows platform and provide a single
> application installer for their project.

Regarding this, what is the current "state of the art" approach to
packaging? For RKWard we had already set up an NSIS installer. This
seems to work to some degree (produces a package, still struggling with
missing MinGW runtime, and failure to find Qt plugins). However I have
an inkling that NSIS wouldn't be the "default" approach to packaging,
anymore. Where can I read up on this?

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20170520/23e91b13/attachment.sig>