[
https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138583#comment-17138583
]
Ioan Eugen Stan commented on JAMES-2586:
----------------------------------------
Hi,
Thanks for getting back.
We have different opinions and I think that is ok.
I do hope we reach a consensus helpful for the whole project.
I'll explain my opinions and reasons why I think closing issues.
You might share some and disagree with some of them.
The issue tracker is meant as a way to record and track issues that people
have.
It's focused on what needs to be done now (where now is loosely used here).
I'll start with some generic reasons.
Having a lot of open issues does not help with the focusing part IMO.
It's hard (for me) to tell what should we focus on and what we should not.
Why should we keep issues open for more than 1-10+ years if no one is going to
work on them.
The issues can always be re-opened if necessary so why is it neccesary for us
to see them every time we use JIRA ?
It's my opinion that if things are important enough they get fixed.
If they are not important enough, they are left behind.
I do believe that keeping things tidy and clean improves the overall "healthy
and good" feel of the project, just like a clean room has a strong impression
on us.
Who wants to live in a unkempt dirty room?
Getting back to this particular issue.
I had the same idea you had since I love PostgreSQL (my default DB) and I know
some things are not implemented very good in JPA.
However I pondered a bit on decided against it was just wishful thinking.
I do believe this is a good idea to explore but unless someone takes the time
to work on it is a nice wish.
We should not have to see it every time we open JIRA and spend a few moments
asking ourselves: What is this all bout? Is this relevant? Is someone working
on this, will it be part of the release ?
If you want to keep the issue open please do.
It's not a thing we should argue over.
However I do hope you see the value in what I am proposing and what others have
implemented for similar reasons to the ones I shared above.
Bellow is a link and a comment from another project that has implemented
automated "Issue rotting".
https://github.com/ansible/ansibullbot/issues/1011
{noformat}
We discussed this at AnsibleFest Atlanta during the Community Summit. The
in-room consensus was to use a model similar to K8s' bot, where:
After 30d with no activity, open feature request is marked 'stale'
After 90d with no activity, open feature request is closed
{noformat}
> Implement a Postgres-specific backend
> -------------------------------------
>
> Key: JAMES-2586
> URL: https://issues.apache.org/jira/browse/JAMES-2586
> Project: James Server
> Issue Type: New Feature
> Reporter: Matthieu Baechler
> Priority: Major
>
> James has a JPA implementation of most interfaces that allows to deploy it on
> top of some popular RDBMS.
> However, while useful for some kind of applications, ORM are usually a bad
> fit for applications requiring high performance like a mail server.
> As an abstraction, it also prevents from using advanced features of a given
> RDBMS.
> For most usages, James would probably run great on top of Postgres, given
> that we use advanced features to implement search, for example.
> A good strategy would be to implement all interfaces implemented by JPA with
> a modern Postgres driver.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
