On Sat, Aug 23, 2014 at 9:00 AM, Valorie Zimmerman <[email protected]> wrote: > On Wed, Aug 20, 2014 at 11:48 AM, Harald Sitter <[email protected]> > 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 -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
