On Sun, Aug 24, 2014 at 1:55 AM, Valorie Zimmerman <valorie.zimmer...@gmail.com> wrote: > On Sat, Aug 23, 2014 at 7:42 AM, Harald Sitter <apachelog...@ubuntu.com> > wrote: >> On Sat, Aug 23, 2014 at 9:00 AM, Valorie Zimmerman >> <valorie.zimmer...@gmail.com> wrote: >>> On Wed, Aug 20, 2014 at 11:48 AM, Harald Sitter <apachelog...@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 -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
