Hi Sahtwik, Thank you for clarification!
I also understand your high quality goals. My hope is that with Michael Hahn as (Apache ODE?) committer can help to achieve these goals. Cheers, Oliver 2018-02-23 12:41 GMT+01:00 Sathwik B P <sathwik...@gmail.com>: > Oliver, > > Apache Ci is Jenkins, code pushes will trigger the build almost immediately > and snapshots are availavle in the Apache snapshot repo.As I have already > responded that we cannot market/expose snapshot artifacts to the users as > per the organization policy no matter which CI tools one proposes to use. > > What is your idea behind CI-Pipeline? > > regards, > sathwik > > On Fri, Feb 23, 2018 at 5:02 PM, Sathwik B P <sathwik...@gmail.com> wrote: > > > Hi Michael, > > > > Just a quick jot down of tasks for JACOB. Migration is another, need to > > see what is missing in JACOB. > > > > JACOB [Release branch (2.0a) - compatible with the ODE trunk branch] > > ------------------------------------------------------------ > > ------------------------------------------- > > 1) Update pom > > -- Upgrade Jackson to latest stable release > > -- JDK 8 > > 2) Lookout for patterns in source as indicated in the CVE [ > > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jackson]. > > 3) Make a new CI build for the 2.0a-JDK 8. > > 4) Run the ODE trunk build to take up latest jacob snapshot. > > 5) Look out for any JACOB open JIRA issues. [issues.apache.org/jira/ > > browse/JACOB] > > > > Migrations testing from 1.3.7 > > ------------------------------ > > 1) Deploy ODE 1.3.7 with external database [mysql] and any transaction > > manager on TOMCAT or use the Embedded ODE Tomee distro. > > 2) Deploy a prrocess and run an instance of the process. > > 3) Configure the ODE trunk to the same external database. Run database > > migration scripts [need to check if there is any required]. > > 4) Do we need to recompile the process binary[.cbp file] to new OModel? > > This is the real thing. > > 5) Complete the running process instance. Runtime processing state > > migration would be tested. > > 6) Create a fresh process instance on the trunk and complete the running > > instance. > > 7) Verify all the exmaple processes in similar fashion. > > > > Lets see how it goes from here. > > > > regards, > > sathwik > > > > On Thu, Feb 22, 2018 at 2:35 PM, Michael Hahn <mhahn....@gmail.com> > wrote: > > > >> Hi Sathwik, > >> > >> I could commit to support you with the releasing (new JACOB > >> implementation, ODE) and to help you by taking up features/issues on the > >> trunk and fix/test them, e.g., implementation of migration from java > >> serialized jacob states to json based jacob states as mentioned by > Tammo. > >> > >> Would it be possible to create a consolidated roadmap/task list to > >> exactly define the tasks/steps necessary for the different releases? > >> So that everybody that wants to contribute is able to do so because at > >> the moment it is hard to get an idea what the open points are (at least > >> from my perspective). > >> If I can help with that, just let me know :-) > >> > >> Best regards, > >> Michael > >> > >> -----Ursprüngliche Nachricht----- > >> Von: Sathwik B P [mailto:sathwik...@gmail.com] > >> Gesendet: Donnerstag, 22. Februar 2018 08:07 > >> An: dev@ode.apache.org > >> Betreff: Re: Extension activities > >> > >> Oliver, > >> > >> What is your commitment towards continued interest in developing ODE > >> further beyond the extension activities? [We are on the verge of zero > >> project activity]. > >> We can offer committership. > >> > >> Trunk is RAW code, never tested. We also probably need to see if there > >> are any security concerns with respect to JSON serialization used in the > >> new Serialization mechanism, I vaguely remember as there was a flag > raised > >> on it sometime ago on a different project. > >> We can probably look for an Alpha release unless the PMC disagrees. This > >> process will require quite an effort on the administrative front. > >> With my limited bandwidth since I only contribute during my free time, > >> it's going to be quite a task. I have the 1.3.8 release process on my > plate. > >> > >> What do you mean by "correlation between source + binary"? > >> > >> regards, > >> sathwik > >> > >> On Wed, Feb 21, 2018 at 9:40 PM, Oliver Kopp <kopp....@gmail.com> > wrote: > >> > >> > Hi, > >> > > >> > Sorry for being pushy. The thing, I want to know is: What steps need > >> > to be taken to create a release which contains our ported extension > >> activities? > >> > Should we port them to another branch? Are there features which we > >> > should help implementing (Jacob?)? > >> > > >> > We need an "official" source + binary of the Apache Foundation of > >> > Apache ODE including support of the extension activities. > >> > > >> > It might be possible that an alpha or beta version also works fine. I > >> > think, the correlation between source + binary is also there and it > >> > has a touch of a release. So maybe a beta release of the current state > >> > is possible without much effort from your side? O:-) > >> > > >> > Cheers, > >> > > >> > Oliver > >> > > >> > > >> > > >> > > >> > > >> > 2018-02-21 13:40 GMT+01:00 Oliver Kopp <kopp....@gmail.com>: > >> > > >> > > Hi, > >> > > > >> > > I think, it's a chiggen-egg problem. > >> > > > >> > > Why not establish a more modern release-early-release-often cycle to > >> > > show activity to the community? What is hindering a CI pipeline? > >> > > This could > >> > also > >> > > ease jumping in this project.I have experience with CircleCI and > >> > > Travis > >> > if > >> > > that helps. > >> > > > >> > > This could also kick-off a Google Summer-of-Code project somehow? > >> > > > >> > > Cheers, > >> > > > >> > > Oliver > >> > > > >> > > 2018-02-03 5:26 GMT+01:00 Sathwik B P <sathwik...@gmail.com>: > >> > > > >> > >> Hi Oliver, > >> > >> > >> > >> May be, we wait to see for the kind of involvment in the DEV > >> > >> community which justifies the release proposal. Head back to the > >> > >> run up of 1.3.7 release on the ODE-1.3.x branch and look for the > >> > >> kind of involvement of devs and also consider the time that these > >> > >> developers spend on contributing to ODE and then probably revisit > >> > >> the release cycles. > >> > >> > >> > >> ODE 1.4 was envisaged to be a major GA release with new features, > >> > >> but > >> > due > >> > >> to lack of involvement in the community it has not seen the light > >> > >> of the day. I would encourage developers to take up features/issues > >> > >> on the > >> > trunk > >> > >> and fix/test them and share information to the community, so that > >> > >> the > >> > PMC > >> > >> can make a sound judgement about releases. > >> > >> > >> > >> We would definitely like to see fresh blood coming into the > >> community. > >> > >> > >> > >> regards, > >> > >> sathwik > >> > >> > >> > >> On Feb 2, 2018 20:27, "Oliver Kopp" <kopp....@gmail.com> wrote: > >> > >> > >> > >> Hi, > >> > >> > >> > >> > >> > >> 2018-02-01 18:45 GMT+01:00 Sathwik B P <sathwik...@gmail.com>: > >> > >> > >> > >> > I dont have a timeline as of yet. The trunk has lot of changes. > >> > >> > We > >> > need > >> > >> to > >> > >> > release the new JACOB implementation. Revisit the clustering > >> > >> implementation > >> > >> > based on hazelcast. We need to test migrations from 1.3.x > >> > >> > versions > >> > from > >> > >> > java serialization to json based serialization. We need to > >> > >> > document > >> > >> these. > >> > >> > All this is sitting on the trunk. > >> > >> > > >> > >> > >> > >> Oh, wow, this sounds like much work. > >> > >> > >> > >> Can't we rethink the release model? I am pretty impressed, what > >> > >> Angular > >> > is > >> > >> doing. They seem to follow "Release early, release often" ( > >> > >> https://en.wikipedia.org/wiki/Release_early,_release_often ) very > >> > >> close and they are not afraid of getting issue reports. > >> > >> > >> > >> You are doing an amazing job at Apache ODE. It should be possible > >> > >> that your work reaches the public very soon: New features and fixes > >> > >> should be released soon and not be kept hidden for a long time. > >> > >> > >> > >> I would propose the following: > >> > >> > >> > >> 1. Start using semantic versioning - https://semver.org/ 2. Make > >> > >> sure that the each of the points you listed are marked as > >> > >> openedissue 3. Release ODE 3.0.0 from the trunk straight away. - > >> > >> Reason: A) There > >> > was > >> > >> once ODE 2.x, so that should be skipped. B) It is NOT backward > >> > compatible > >> > >> with ODE 1.x (Jacob-JSON things) > >> > >> 4. Work on the JSON migration from java serialized jacob states to > >> > >> json based 5. Release ODE 4.0.0, which is then (hopefully) > >> > >> backard-compatible with 1.3.x > >> > >> > >> > >> Reasoning: > >> > >> > >> > >> 1. The 1.x line can still be maintained as rock-solid engine > >> > >> implementation for business users 2. Starting from 3.x, ODE is a > >> > >> fast-moving project, which can include contributions from external > >> > >> fast and also have the possibility to > >> > "release > >> > >> early, release often" > >> > >> > >> > >> I would also propose to have the "master" branch always release > >> ready: > >> > All > >> > >> tests are green. > >> > >> > >> > >> WDYT? > >> > >> > >> > >> Cheers, > >> > >> > >> > >> Oliver > >> > >> -- > >> > >> http://github.com/koppor/ > >> > >> > >> > > > >> > > > >> > > >> > >> > > >
