On Tue, Feb 27, 2018 at 1:25 AM, Waldek Kozaczuk <jwkozac...@gmail.com> wrote:
> Please see my responses below. Also one question I forgot to ask was the > cadence - how often and when to release. It could be: > > 1. when enough new features/bugs are added/fixed (this requires more > planning) > 2. when certain amount of time passes > > I am leaning towards the 1st approach. Should be once a month, every 3 > months? > Considering the very slow development of OSv over the last couple of years, a monthly release will not make much difference. That being said, if you'll have an easy way, even automatic, to build releases, the we can have monthly - or even nightly (!) binary releases. All this as long as we don't make any guarantees on release - we won't be doing any support or backporting on previous releases. We're simply not making enough progress for this to make sense. Maybe this will change in the future... > > On Monday, February 26, 2018 at 12:32:40 AM UTC-5, דור לאור wrote: >> >> IIRC we agreed to release a 0.25 few months ago. No problem to go >> back to a regular cadence of releases. Waldek, we'll need you as a >> driving force. >> > I thought you or Nadav mentioned somewhere else that 0.50 would be more > appropriate. Given it has been over 2 years since 0.24 it would make more > sense to make it 0.50 and maybe delete all old artifacts. > Dor is my boss, so I'll defer to his opinion, but you don't need to agree :-) I think Dor wanted to go with a low number to emphasise that, 1. OSv is not ready, and 2. OSv hasn't progressed *much* since 0.24. It has progressed, for sure, but it's not "twice" better than it used to :-) >>> Good luck with that. I think it may take a bit of experimentation to get >>> the version compatibility issues worked around (we can also fix many of >>> these issues at OSv itself, but this is orthogonal to the release issues). >>> But I have to wonder, shouldn't the compiled-package repository (for >>> Mikelangelo Capstan) and the compiled-kernel be at the same place, and the >>> person in charge of this place responsible to compiling them all in the >>> same environment? How will it help if we only host the kernel, and someone >>> else hosts the applications? >>> >> > I happen to have different opinion. I think that having kernel binary > (usr.img) available as a release artifact on OSv github page makes it > possible to try newer version of kernel with the same application Capstan > package *as long as both have been produced by the same tool chain*. This > can be guaranteed by using same docker container unless I am missing some > details. Obviously the docker file has to identify specific version of gcc, > etc like so: > That's true. > > RUN apt-get install gcc=4:5.3.1-1ubuntu1 #assumes ubuntu > > Per issue https://github.com/cloudius-systems/osv/issues/743 > Also relevant is https://github.com/cloudius-systems/osv/issues/821 > we should be using compilation/linking artifacts from host system (like > libgcc_s, boost) which would depend on the host configuration. But again if > specific version of artifact is pinned by Docker file then it all should be > repeatable and resulting kernel (usr.img) should be the same every time bit > by bit. > > If I was to create new docker file (based on Mikeleangelo capstan-packages > one) what specific versions of the "golden" tool chain elements should I > use? What distribution of Linux should I use (is Ubuntu better than Fedora > for example?). What distribution version? > > Maybe use the same version of tool chain elements that Jenkins build > server uses? > Another alternative is to automate with docker the creation of multiple compiled kernels, on multiple distributions (e.g., latest Fedora, latest Ubuntu, something a bit older, etc.) so the user can compile on his own machine, and then combine it with the appropriate choice of kernel. Our kernels are small enough that it's really fine if our download site had 10 different ones. -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
