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 together for compatibility. IMO, we made a decision early in the project to separate component parts of our architecture into individual repos. for many good, well considered reasons.
Primarily the project represents a complex PaaS platform with many moving parts (both client and server) with different requirements for skills and languages, but all interdependent on each other by inherent versioning of APIs and Service Provider Interfaces, as well as runtime conventions. In reality we cannot release just even the main OW repo. since it's build is dependent on the other repos.' images. It is disingenuous at best IMO. Releasing individual repos. without clear documentation of these still changing surfaces really does not work. It is something the community well knows, has been discussed several times, is documented as a future "goal". For now, I am quite happy with releasing all together. I look at it this way... we could simply TAR all the repos. into one big TAR (to no real benefit other than to get 1 file). Code is code, packaging is packaging; in the end that all it really represents. BTW, I am more than happy to formalize and represent this position (along with the history) to make it clear for others during the review process. /soapbox off -MR On 2018/06/21 13:08:23, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > Hi Vincent, > > On Thu, Jun 21, 2018 at 2:53 PM Vincent S Hou <s...@us.ibm.com> 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 users and w.r.t release cycles? > > For Apache Sling, as an example which is extremely modular, we do lots > of individual module releases all the time, and about once a year do a > "big bang" release that includes all core module. > > A model like that might be good for OpenWhisk, but as this stage as > mentioned for a first "training release" it's probably best to stick > to one typical module to refine the process. > > ... > > * The key can be accessed at > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS. You missed > > "dev/" in your link... > > Ah ok, sorry! Got it now. > > > ...* So far the header is not verified with RAT. We have a unitiy repo call > > openwhisk-utility(https://github.com/apache/incubator-openwhisk-utilities) > > to scan all the code. RAT has issues, > > since I have never got it running correctly in openwhisk. The Travis build > > uses this openwhisk-utility to verify the > > headers for every incoming commit.... > > Ok. The "how to I run the utility to verify the license headers" > question should be answerable with a URL, maybe the docs of that > utility? > People will need to be able to run it standalone to do their own > verifications. > > > * RSA private key should have some instructions. We will work on it... > > Great > > > * We do not release binary this time... > > Yes - I was checking for binaries that might have been leftover, saw > none and that's good! > > > * We will look at the .scala code files... > > Ok. If the package name change is too disruptive it can be postponed > for later during incubation, but that needs to be tracked. > > > * For README, let me make the build instruction more clear... > > Thanks! > > I suppose this means this vote is canceled until you have a new > release candidate? > > -Bertrand >
