[jira] [Closed] (JAMES-3603) Remove dockerfiles/packaging and /benchmarks

["Benoit Tellier (Jira)" <se...@james.apache.org>]

     [ https://issues.apache.org/jira/browse/JAMES-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benoit Tellier closed JAMES-3603.
---------------------------------
    Resolution: Fixed

> Remove dockerfiles/packaging and /benchmarks
> --------------------------------------------
>
>                 Key: JAMES-3603
>                 URL: https://issues.apache.org/jira/browse/JAMES-3603
>             Project: James Server
>          Issue Type: Improvement
>          Components: Build System
>    Affects Versions: 3.6.0
>            Reporter: Benoit Tellier
>            Priority: Major
>             Fix For: 3.7.0
>
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> https://www.mail-archive.com/server-dev@james.apache.org/msg70419.html
> While working on JAMES-3596 (reorganizing servers apps in server/apps
> folder), I notice the following:
>  - 1. dockerfiles/packaging is unmaintained
> It aimed at delivering Debien / RPM images for James. However:
>     - It uses linagora images and not apache ones
>     - It is not integrated to the Apache build, not integrated as
> release artifacts
>     - With the images reworks, it looks broken now.
> As such I wonder if we should maintain this at all.
> If people are interested maintaining the Debian packagin, then we likely
> could welcome contributions to integrate it to the maven build using
> things like jdeb.
>  - 2. /benchmarks + JenkinsfileStressTests.groovy usage:
>      - Requires complex setup (btrfs, Jenkins 2, etc...) and setting it
> up is undocumented
>      - Provisioning the email corpus is undocumented
>      - The Gatling-Job had not been contributed to the Apache project
>      - This launches all components of the distributed server on a
> single machine and as such does not represent real world performance,
> where all the building blocks are on different machines
>      - Not integrated to Apache processes of any kind.
> As such, as this seems unusable for any member of the community as-is,
> as Linagora practices moved toward testing on a real Kubernetes cluster,
> I propose to remove it rather than attempt to fix it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org