CP rollout plan

[Harald Sitter]

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