CP rollout plan

Harald Sitter apachelogger at ubuntu.com
Mon Aug 25 07:19:59 UTC 2014


On Sun, Aug 24, 2014 at 1:55 AM, Valorie Zimmerman
<valorie.zimmerman at gmail.com> wrote:
> On Sat, Aug 23, 2014 at 7:42 AM, Harald Sitter <apachelogger at ubuntu.com> wrote:
>> On Sat, Aug 23, 2014 at 9:00 AM, Valorie Zimmerman
>> <valorie.zimmerman at gmail.com> wrote:
>>> On Wed, Aug 20, 2014 at 11:48 AM, Harald Sitter <apachelogger at ubuntu.com> wrote:
>>>> oh, and I forgot....
>>>>
>>>> in Randa we talked about related stuff on the KDE CI side and in the
>>>> long term we will hopefully get to a point where upstream CI actually
>>>> provides 100% releasable tarballs on a daily basis (including
>>>> translations and whatnot). so at some point instead of basing our CP
>>>> off of a git branch we'd use a tarball from KDE CI. this other than
>>>> having testing of release builds (with l10n and docs...) on both ends
>>>> also means that we know that the tarballs we get are known to compile
>>>> on upstreams systems, so arbitrary FTBFS from random breakage get
>>>> taken out of the equation at that point entirely.
>>>>
>>>> HS
>>>
>>> The biggest question I have about this, is how are discussions
>>> proceeding with Debian about using their git infra for our CI? Any
>>> other good possibilities? From your description it seems that git is
>>> the only good choice.
>>
>> Indeed, that's however dependent on the outcome of the git sharing
>> test to begin with (i.e. I'd rather not add additional complexity to
>> the evaluation of shared repositories by talking about CP on top of
>> everything as CP really just sets on top of regular packaging anyway).
>> If we can tightly share the git repo with debian it's awesome but CP
>> wouldn't necessarily change anything about how this sharing works
>> (except the merge order of branches might be different).
>>
>> In the event that we can not share repos for whatever reason there's a
>> bunch of free hosting solution or really we could set up a simple
>> infrastructure ourselves. In the long term regardless of whether we
>> will actively share the same repository with debian we need to go to
>> git though. The thing is that since git can have multiple remotes
>> (i.e. remote instances of a repository with different content ontop a
>> common base) even if we can not share the same repository we can
>> create a derivative repository which in turn would give most of the
>> advantages a shared repo gives except it is slightly more work to set
>> up (namely one needs to manually configure the second git remote for
>> debian's packaging).
>>
>>> What about localization, docs and other translations? It sounds like
>>> this issue has not been fully solved yet.
>>
>> Note the first reply in this thread I made to myself :P
>> In the long run tarballs with all that stuff should come out of
>> jenkins. Depending on the time frame of this feature we might wire up
>> the release scripting with the builder we use for neon in the meantime
>> to get fully releaseable daily tarballs all the same.
>>
>> The first test builds I did has automation to rip out the relevant
>> paths from the packaging so that the builds don't fail, of course that
>> also means that the builds right now are not 100% reliable because
>> they do not test those extra bits (alas, upstream CI has the same
>> problem right now...).
>>
>> HS
>
> So what do we need to do next? Are we waiting to test out various
> options in Brno?

I am doing a test setup already :P

HS



More information about the kubuntu-devel mailing list