CP rollout plan

[Valorie Zimmerman]

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?

Valorie