[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Blacklisting of PIM from the CI system
From:       Harald Sitter <sitter () kde ! org>
Date:       2019-12-05 11:40:25
Message-ID: CAEc+18HxoTjgEfzCD1XvLoc+AZjQGiLXzDUbqXyawSY3Gu6Y6A () mail ! gmail ! com
[Download RAW message or body]

It's a good idea. I thought about that briefly. Two problems
immediately came to mind that made me discard the idea:

a) for builds that are not from git we'd not know the commit count
(unless we glue that into the git release commit / tag - which I am
not sure we actually want, but is certainly a possibility)
b) more importantly: depending on the actual commit count it scales
poorly. for a repo like kdevelop it took 26 or so seconds to actually
count on the hard drives we use for CI when I tried a couple weeks
back.
personally I'd stay away from things that reduce the CI turn around :)

So, overall I think it may be a good solution, there are some hurdles
though. The benefit certainly would be that one could then actively
track dependencies down to the commit they were added to a framework.

On Thu, Dec 5, 2019 at 10:32 AM Luca Beltrame <lbeltrame@kde.org> wrote:
>
> Il giorno Thu, 05 Dec 2019 01:23:28 +0100
> Kevin Kofler <kevin.kofler@chello.at> ha scritto:
>
> > The git SHA is not going to work for this, because it is not
> > monotonic. What you really want to know is whether you have something
> > >= 5.65.0.abcd123, and having a 5.65.0.commithash version is not
> > >going to tell you that.
>
> Perhaps (like we do in openSUSE for some git snapshots) using the
> number of commits since the last tag? It should increase monotonically.
>
> (might be a bad idea in this context, but I thought I'd throw that into
> the mix)
>
>
[prev in list] [next in list] [prev in thread] [next in thread]