> On 22 Jun 2018, at 05:14, Vincent S Hou wrote:
>
> Great thanks to folks with votes and the comments.
Wow, a lot happened on my travel day!
> As a recap of current replies we have received, we have opened a list of
> issues to be fixed for OpenWhisk in the coming release or further
Great thanks to folks with votes and the comments.
As a recap of current replies we have received, we have opened a list of issues
to be fixed for OpenWhisk in the coming release or further releases:
1. Add the tutorial for 0.9.0 to build and deploy locally with source code
Thanks Ben for looking into this, having a good API doc/spec and matching
tests is very need it.
+1
-cs
On Thu, Jun 21, 2018 at 2:25 PM Ben Browning wrote:
> Our Swagger spec
> (
>
+1 for 0.9.0-incubating
time to write a book on it :)
--
Michele Sciabarra
openwh...@sciabarra.com
On Thu, Jun 21, 2018, at 8:24 PM, James Thomas wrote:
> +1 Release as Apache OpenWhisk 0.9.0-incubating.
>
> Good work on this everyone. Time to get the ready
>
> On 21 June 2018 at
Our Swagger spec
(https://github.com/apache/incubator-openwhisk/blob/92a64c291156a2cd3d6b304babc2a193a46d0699/core/controller/src/main/resources/apiv1swagger.json)
is incomplete and doesn't accurately reflect the actual Controller
API. It's manually updated without a full test suite which means
+1 Release as Apache OpenWhisk 0.9.0-incubating.
Good work on this everyone. Time to get the ready
On 21 June 2018 at 17:35, Priti Desai wrote:
> +1 for the release, its been a lot of hard work from the team, great job
> Matt, Vincent, and Daisy!
>
> Cheers
> Priti
>
>
--
Regards,
Can we also write up the release process in markdown and store in in the
repo to help future release managers (unless Vincent wants to do it forever
:))?
On 20 June 2018 at 20:59, Vincent S Hou wrote:
> Give me the honor to the initiative as the first release manager of
> OpenWhisk.
> The first
+1 for the release, its been a lot of hard work from the team, great job
Matt, Vincent, and Daisy!
Cheers
Priti
Hi Bertrand,
...Plus a single repo. source is not usable by itself and its build
dependent
on the other parts as I mentioned earlier...
>>Right, it if cannot be built that's a problem - but if you say that I
>>suppose there's a build order that must be followed?
>>If that's correct
Hi Matt,
On Thu, Jun 21, 2018 at 5:27 PM Matt Rutkowski wrote:
> ...Are you saying you believe the Incubator PMC
> will fail us strictly due to having 13 tgz/tar files vs. 1 for a first
> release?...
I don't know (and someone's welcome to ask on the
general@incubator.a.o list to find out), but
FWIW --- IF we had to pick one repo, the one with the fewest dependences
that could be standalone, as a first release would the go sdk.
Then wskdeploy?
The runtimes and CLI are tricky there after because why self contained, for
the most part, do share common bits with openwhisk repo for the
Hi Bertrand,
I am not sure I understand. Are you saying you believe the Incubator PMC
will fail us strictly due to having 13 tgz/tar files vs. 1 for a first
release? Again, it makes no sense to me as it is strictly a choice of
logical separation (representative of our architectural parts)
Hi Matt,
On Thu, Jun 21, 2018 at 5:03 PM Matt Rutkowski wrote:
> ...For now, I am quite happy with releasing all together
We can try, but as I said I'm not sure if the Incubator PMC will
accept this for a first release.
Even releasing a single module that's not usable by itself is progress
Hi Bertrand,
I do not believe we should (or can) release just one repo. at this time (my
vote is continue with current artifact granularity). In the future, we can work
to enable individual repo. release over time as well (describe via
process/tools), but most of these repos. must be released
Thanks Betrand,
You saved me time today :yay: !
Yeah the renaming of the scala packages, should not be a show stopper but
we should open an issue in the release repo to track.
Also needs some coordination for own modules that depends on it and
downstreams.
We can release 0.9.0, and after release
Hi Bertrand,
As you noted, the release process uses the Apache RAT to scan all the
built TAR files and our own Scancode utility scans files at "build time"
for both PR and release (master or named release) builds.
We have endeavored to document our use of these scanning utilities within
the
Thanks Bertrand for the suggestion to modularize the release - I do think
that makes a lot of sense as well.
The way we're vectoring is for the runtimes to be independent and can have
their own lifecycle.
Similarly the CLI and related tooling.
In the long run this will make a lot of sense.
-r
Hi Vincent,
On Thu, Jun 21, 2018 at 2:53 PM Vincent S Hou wrote:
> ...Does it mean we can try to release one of the 13 modules, like openwhisk,
> or openwhisk-cli, or consolidate
> all the 13 projects into one for release?...
The former, I would say?
It's probably more convenient for your
Hi Bertrand,
Thank you very much for your comments.
Let me clarify what you mean by one module:
Does it mean we can try to release one of the 13 modules, like openwhisk, or
openwhisk-cli, or consolidate all the 13 projects into one for release?
* The key can be accessed at
Hi Vincent,
Thanks for your work in preparing this release!
On Wed, Jun 20, 2018 at 11:16 PM Vincent S Hou wrote:
> ...There are totally 13 OpenWhisk projects within this release
As mentioned earlier I don't think it is a good idea to release
multiple modules in your first Incubator
ArtifactStore SPI exposes a shutdown method which is responsible for
closing any resource owned by store implementation.
Ccurrently for CouchDbRestStore it only shuts down ActorMaterializer which
is created one per instance. It does not shutdown Http pool which is shared
across 3 store instance.
21 matches
Mail list logo
