On Sat, Aug 23, 2014 at 7:42 AM, Harald Sitter <[email protected]> wrote: > 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
So what do we need to do next? Are we waiting to test out various options in Brno? Valorie -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
