Adding Miha back. Sent from my iPhone
> On Feb 26, 2018, at 18:25, 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: > when enough new features/bugs are added/fixed (this requires more planning) > when certain amount of time passes > I am leaning towards the 1st approach. Should be once a month, every 3 months? > >> 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. >> >>> On Sun, Feb 25, 2018 at 3:15 PM, Nadav Har'El <n...@scylladb.com> wrote: >>> >>>> On Sun, Feb 25, 2018 at 8:45 PM, Waldek Kozaczuk <jwkoz...@gmail.com> >>>> wrote: >>>> I would like to publish new release of OSv. The last official one was 0.24 >>>> and published on Oct 30, 2015 (a little over 2 years). I have never >>>> released OSv so any input and suggestions are very welcome especially from >>>> those that did it in the past. >>> >>> I agree. The antique release is just a trap for new users, who might be >>> tempted to use that version. So we should either make a new release, or >>> decide we don't have any releases at all and delete the links to old >>> releases. >>> >>> I think it would be nice to have a new release, if you're up to it. >>> >>>> >>>> There is an existing wiki page that documents how to publish new release - >>>> https://github.com/cloudius-systems/osv/wiki/OSv-Release-Procedure. >>>> However I think most of the steps do not apply anymore. >>> >>> I agree, and I think then whenever we decide what should apply going >>> forward, we should change that wiki page. >>> >>>> I think I should follow standard Github release procedure - >>>> https://help.github.com/articles/creating-releases/. >>> >>> I'm not sure if it's relevant either - you can use git commands to make >>> tags. And we should use ones similar to those we used in previous releases. >>> >>>> >>>> I would also like to take advantage of ability to upload binaries >>>> associated with the release. My plan is to build and attach "osv.loader" >>>> (aka usr.img) and "osv.bootstrap" mpm file and then let users use >>>> mikelangelo capstan in order to build new app packages. The trick is to >>>> build it using same or similar tool chain as other capstan packages are >>>> built. I am planning to use same or similar docker file as here - >>>> https://github.com/mikelangelo-project/capstan-packages in order to avoid >>>> any incompatibility issues as described here - >>>> https://www.mikelangelo-project.eu/2017/08/the-art-of-preparing-osv-packages/. >>>> I think it is important to use same host system (ubuntu 14), specific gcc >>>> and possibly specific version of other artifacts to make sure usr.img is >>>> compatible. >>> >>> 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: > > RUN apt-get install gcc=4:5.3.1-1ubuntu1 #assumes ubuntu > > Per issue https://github.com/cloudius-systems/osv/issues/743 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? > >>> >>>> >>>> >>>> My goal is to make it easier for OSv newcomers to try OSv. I also want to >>>> focus on promoting OSv as a deployment platform for stateless services. >>>> Therefore I would like to make it easy to build images using runtimes like >>>> JVM, node.js, erlang, python, ruby and eventually golang. I would be also >>>> nice to make it easy to try apps like redis, nginx, etc. >>>> >>>> Some outstanding questions: >>>> What should be new release version - 0.50, 0.75? >>> >>> I think 0.5. > OK. >>> >>>> What should be the release notes? I think it would be worth to at least >>>> list major new features added since last release. >>> >>> We can start digging in "git log" to compile a release notes, when the time >>> comes. >>> I think so much time has passed, that nobody will remember what 0.24 >>> contained, anyway :-) >>> In any case, the release notes should mention Mikelangelo Capstan and >>> explain how to use it, because that is a major new thing which became >>> relevant in this release. > Agree. >>> >>> Thanks, >>> Nadav. >>> -- >>> 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+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the Google > Groups "OSv Development" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/osv-dev/UF3gyDgwAMg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > osv-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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.
