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/
>> > >>
>> > >
>> > >
>> >
>>
>>
>

Reply via email to