Re: [Vote] Call for vote: Apache Mime4J 0.8.4

2021-04-15 Thread Tellier Benoit
Hello Jean,

I opened https://github.com/apache/james-mime4j/pull/38 on that topic:
 - correct release tracking on the JIRA
 - Detail the changelog for upcoming 0.8.4
 - Merge release notes and the changelog

This should solve your concerns,

Regards,

Benoit

Le 15/04/2021 à 14:12, Jean Helou a écrit :
> Hi benoit,
>
> The changelog has not been updated which is a bit sad (and i know it's
> painful to do but it's s helpful for developers who use the library)
> On a semi-related note : the release notes have not been updated either but
> that last file actually seems to be totally out of sync with the repo : it
> mentions an inexistant 0.9.0 and has not been modified for the last 4 years
> ... maybe delete it ?
>
> jean
>
> On Wed, Apr 14, 2021 at 9:09 AM Tellier Benoit  wrote:
>
>> Hi,
>>
>> Following a user request (https://issues.apache.org/jira/browse/MIME4J-297
>> ),
>>
>> I would like to propose a vote for 0.8.4 release of the MIME4J library.
>>
>> You can find the maven release staged in repository.apache.org as the
>> artifact #1053:
>> https://repository.apache.org/content/repositories/orgapachejames-1053/
>>
>>
>> Voting rules:
>>  - This is a majority approval: this release may not be vetoed.
>>  - A quorum of 3 binding votes is required
>>  - The vote starts at Wedneday 14th of April 2021, 2pm UTC+7
>>  - The vote ends at Wednesday 21th of April 2021, 2pm UTC+7
>>
>> You can answer to it just with +1 and -1. Down-votes may be motivated.
>>
>> 3 binding votes are expected move forward on this release.
>>
>> Cheers,
>>
>> Benoit Tellier
>>
>> -
>> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
>> For additional commands, e-mail: server-dev-h...@james.apache.org
>>
>>

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



[BUILD-FAILURE]: Job 'james/ApacheJames/master [master] [72]'

2021-04-15 Thread Apache Jenkins Server
BUILD-FAILURE: Job 'james/ApacheJames/master [master] [72]':
Check console output at "https://ci-builds.apache.org/job/james/job/ApacheJames/job/master/72/;>james/ApacheJames/master
 [master] [72]"

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

Re: apache/james on docker hub.

2021-04-15 Thread Tellier Benoit
Hello Jean,

Answer inlined...

Le 15/04/2021 à 19:01, Jean Helou a écrit :
>> Following the 3.6.0 release I experimented with dockerhub and pushed the
>> following images:
>>
>  THANK YOU ! (yes with caps because that's how grateful I am !)
>
> I also propose to timely edit the existing configuration to:
>>  - No longer use linagora repository for Apache James docker images
>> distribution
>>
>  - Only rely on released docker images (no longer branch master) to
>> better fit in Apache release policies
>>
> I saw the corresponding PR :+1:
>
>
>> To be fairly honest building these images took me too much time. I would
>> highly appreciate automation of docker images construction as part of
>> the maven build. A way to do it is JIB. [1]
>
> That's what I used to build my pure SMTP relay server assembly, it's being
> polished but jib works great :)
>
> demonstrate building a james
>> server image variation for a tierce project so I propose to do something
>> similar, except without requiring a docker daemon. It includes CLI,
>> glowroot, etc... We had been using this JIB generated image on
>> production without problems. I propose we target something similar for
>> James docker image generation. As part of the release process we would
>> then need to load, then push the maven build results. This would lead to
>> the removal of /dockerfiles folder (more or less).
>>
> Since  docker images are not considered release artifacts under apache
> policy (if I understand correctly) would it make sense to try and fully
> automate the image building post release ?
> add a piece to the jenkinsfile that monitors only tags, and builds the jib
> image downloading the artifacts from maven central
This argument make sense.

Maybe we could push automatically RCs to docker hub automatically upon
tagging (before the voting process), then once the vote pass just rename
the images?

That way:
 - It is automatic and convenient
 - We make it clear the artifact is not to be used yet

This would look like what Juhan proposed in
https://issues.apache.org/jira/browse/JAMES-3565 ...

Thoughts?

Cheers,

Benoit

>
>
>> [1]
>>
>> https://github.com/linagora/openpaas-james/tree/master/openpaas-james/apps/memory
>> README and pom.xml are of interest.
>>
>> Cheers,
>>
>> Benoit
>>
>> Le 11/12/2020 à 16:29, Tellier Benoit a écrit :
>>> You're right,
>>>
>>> I did not follow up on this.
>>>
>>> I just created the INFRA ticket.
>>> https://issues.apache.org/jira/browse/INFRA-21180
>>>
>>> As far as I understand, this is not an official release channel but
>>> rather a convenience one.
>>>
>>> Cheers,
>>>
>>> Benoit
>>>
>>> Le 11/12/2020 à 15:18, Jean Helou a écrit :
> I propose to ask for rights on apache/james repository
 I'm revisiting this thread after seeing
 https://www.docker.com/blog/supporting-open-source-projects-at-docker
>> which
 reminded me of this effort and I was wondering if an INFRA ticket has
>> been
 opened for james (of if there is a trace of the progress somewhere)
 I'm not sur exactly how the program works but if it whitelists prefixes,
 Apache is most likely already in it however in light of the work on CI
 builds on apache infrastructure, I am wondering if/how the credentials
>> for
 pushing form CI can be setup and I was hoping to drop a comment on the
 corresponding ticket.

 jean

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

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



Re: [Results] [VOTE] Call for vote: Apache James 3.6.0 (round 3)

2021-04-15 Thread Tellier Benoit
Hello Jean,

Le 15/04/2021 à 19:25, Jean Helou a écrit :
> [...]
> I don't see how 389 blocks the release but I'm ok with the PR anyway :)
I will advertise the release on the announce mailing list. If the first
page of the website is advertising a broken demo, then it is not good
for the overall project, and we miss a good opportunity to promote it.
> Cheers,
> Jean
>
>
>> Otherwise I will proceed, likely on Friday, if not next week when
>> I have time... - I must confess being impatient to be done with it.
>>
>> Cheers,
>>
>> Benoit
>>
>> Le 14/04/2021 à 10:34, Tellier Benoit a écrit :
>>> Hi all,
>>>
>>> I am happy to announce you the vote for the 3.6.0 release did succeed.
>>>
>>> The release received 8 positive votes, 3 of them being binding.
>>>
>>> Thanks to all contributors, developers and committers who made this
>>> possible!
>>>
>>> In the coming hours, I will finalize the release process, namely:
>>>
>>> - Publish the maven artifacts
>>> - Upgrade the download page and the (old) website
>>> - Announce the release
>>> - Apache docker images (convenience downloads, non official release
>>> artifacts CF Apache policy regarding docker images)
>>>
>>> Voting thread:
>>> https://www.mail-archive.com/server-dev@james.apache.org/msg70025.html
>>>
>>> Cheers,
>>>
>>> PMC member name
>>>
>>> -
>>> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
>>> For additional commands, e-mail: server-dev-h...@james.apache.org
>>>
>> -
>> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
>> For additional commands, e-mail: server-dev-h...@james.apache.org
>>
>>

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



[jira] [Comment Edited] (JAMES-2896) RabbitMQ MailQueue should support delays

2021-04-15 Thread Sam (Jira)


[ 
https://issues.apache.org/jira/browse/JAMES-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322416#comment-17322416
 ] 

Sam edited comment on JAMES-2896 at 4/15/21, 6:57 PM:
--

Hi Benoit,

Thank you for your answer

Yes, Apache Pulsar can be the best option, because I think the implementation 
with cassandra could give more problems, and RabbitMQ needs those tricks for 
this


was (Author: sp102285):
Hi Benoit,

Thank you for your answer

 

Yes, Apache Pulsar can be the best option, because I think the implementation 
with cassandra could give more problems, and RabbitMQ needs those tricks for 
this

> RabbitMQ MailQueue should support delays
> 
>
> Key: JAMES-2896
> URL: https://issues.apache.org/jira/browse/JAMES-2896
> Project: James Server
>  Issue Type: Improvement
>  Components: Queue, rabbitmq
>Reporter: Benoit Tellier
>Priority: Major
>  Labels: feature
>
> MX (mail exchange) servers do rely on delays for some things like spam and 
> abuse detection thus this is a critical capability for a mail queue component 
> of a server aiming at being used as an MX.
> So far, RabbitMQ mail queue does not support delays. Its usage is then 
> discouraged within an MX server (though it is perfectly suited for an MDA).
> We can relatively easily implement delays within the RabbitMQ mail queue:
>  - When a delay is specified, we save the message in the object storage,
>  fire a message on a **MailQueueDelayExchange**, and persist it on the
> MailQueueView.
>  - Each James listens on a single Queue plugged to the
> **MailQueueDelayExchange**.
>  - For each incoming message, the receiver will position a timer until
> the planned delivery (date).
>  - Upon timer completion, we ack the message of MailQueueDelayExchange,
> then we put the corresponding message in the mail RabbitMQMailQueue (no
> need to update the mailQueueView nor store again the blob).
>  - Upon connection loss, the message will be nacked and will be then
> handled by another s/consumer/jamesServer/.
> Obviously:
>  - We need synchronized clocks "best-effort" - think NTP
>  - This solution can duplicate emails upon connection loss - a local
> James needs to invalidate the entries he is waiting for upon connection loss.
>  - **flush** needs to be broadcasted so that all James servers can release 
> the retained delayed emails into the mail queue.



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



[jira] [Commented] (JAMES-2896) RabbitMQ MailQueue should support delays

2021-04-15 Thread Sam (Jira)


[ 
https://issues.apache.org/jira/browse/JAMES-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322416#comment-17322416
 ] 

Sam commented on JAMES-2896:


Hi Benoit,

Thank you for your answer

 

Yes, Apache Pulsar can be the best option, because I think the implementation 
with cassandra could give more problems, and RabbitMQ needs those tricks for 
this

> RabbitMQ MailQueue should support delays
> 
>
> Key: JAMES-2896
> URL: https://issues.apache.org/jira/browse/JAMES-2896
> Project: James Server
>  Issue Type: Improvement
>  Components: Queue, rabbitmq
>Reporter: Benoit Tellier
>Priority: Major
>  Labels: feature
>
> MX (mail exchange) servers do rely on delays for some things like spam and 
> abuse detection thus this is a critical capability for a mail queue component 
> of a server aiming at being used as an MX.
> So far, RabbitMQ mail queue does not support delays. Its usage is then 
> discouraged within an MX server (though it is perfectly suited for an MDA).
> We can relatively easily implement delays within the RabbitMQ mail queue:
>  - When a delay is specified, we save the message in the object storage,
>  fire a message on a **MailQueueDelayExchange**, and persist it on the
> MailQueueView.
>  - Each James listens on a single Queue plugged to the
> **MailQueueDelayExchange**.
>  - For each incoming message, the receiver will position a timer until
> the planned delivery (date).
>  - Upon timer completion, we ack the message of MailQueueDelayExchange,
> then we put the corresponding message in the mail RabbitMQMailQueue (no
> need to update the mailQueueView nor store again the blob).
>  - Upon connection loss, the message will be nacked and will be then
> handled by another s/consumer/jamesServer/.
> Obviously:
>  - We need synchronized clocks "best-effort" - think NTP
>  - This solution can duplicate emails upon connection loss - a local
> James needs to invalidate the entries he is waiting for upon connection loss.
>  - **flush** needs to be broadcasted so that all James servers can release 
> the retained delayed emails into the mail queue.



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



Re: [Results] [VOTE] Call for vote: Apache James 3.6.0 (round 3)

2021-04-15 Thread Jean Helou
>
> I am about to conclude the 3.6.0 release (publish the website & announce)
>

 :rocket:

However I would like the website to advertise the maintained, apache
> images rather than the unmaintained ones of an undisclosed third party.
>
> I imagine the changes in
> https://github.com/apache/james-project/pull/389 to be consensual.
>
> If the feedback is positive, I can finish the 3.6.0 process as off
> today.


I don't see how 389 blocks the release but I'm ok with the PR anyway :)

Cheers,
Jean


> Otherwise I will proceed, likely on Friday, if not next week when
> I have time... - I must confess being impatient to be done with it.
>
> Cheers,
>
> Benoit
>
> Le 14/04/2021 à 10:34, Tellier Benoit a écrit :
> > Hi all,
> >
> > I am happy to announce you the vote for the 3.6.0 release did succeed.
> >
> > The release received 8 positive votes, 3 of them being binding.
> >
> > Thanks to all contributors, developers and committers who made this
> > possible!
> >
> > In the coming hours, I will finalize the release process, namely:
> >
> > - Publish the maven artifacts
> > - Upgrade the download page and the (old) website
> > - Announce the release
> > - Apache docker images (convenience downloads, non official release
> > artifacts CF Apache policy regarding docker images)
> >
> > Voting thread:
> > https://www.mail-archive.com/server-dev@james.apache.org/msg70025.html
> >
> > Cheers,
> >
> > PMC member name
> >
> > -
> > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> > For additional commands, e-mail: server-dev-h...@james.apache.org
> >
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: apache/james on docker hub.

2021-04-15 Thread Jean Helou
> Following the 3.6.0 release I experimented with dockerhub and pushed the
> following images:
>

 THANK YOU ! (yes with caps because that's how grateful I am !)

I also propose to timely edit the existing configuration to:
>  - No longer use linagora repository for Apache James docker images
> distribution
>
 - Only rely on released docker images (no longer branch master) to
> better fit in Apache release policies
>

I saw the corresponding PR :+1:


> To be fairly honest building these images took me too much time. I would
> highly appreciate automation of docker images construction as part of
> the maven build. A way to do it is JIB. [1]


That's what I used to build my pure SMTP relay server assembly, it's being
polished but jib works great :)

demonstrate building a james
> server image variation for a tierce project so I propose to do something
> similar, except without requiring a docker daemon. It includes CLI,
> glowroot, etc... We had been using this JIB generated image on
> production without problems. I propose we target something similar for
> James docker image generation. As part of the release process we would
> then need to load, then push the maven build results. This would lead to
> the removal of /dockerfiles folder (more or less).
>

Since  docker images are not considered release artifacts under apache
policy (if I understand correctly) would it make sense to try and fully
automate the image building post release ?
add a piece to the jenkinsfile that monitors only tags, and builds the jib
image downloading the artifacts from maven central


> [1]
>
> https://github.com/linagora/openpaas-james/tree/master/openpaas-james/apps/memory
> README and pom.xml are of interest.
>
> Cheers,
>
> Benoit
>
> Le 11/12/2020 à 16:29, Tellier Benoit a écrit :
> > You're right,
> >
> > I did not follow up on this.
> >
> > I just created the INFRA ticket.
> > https://issues.apache.org/jira/browse/INFRA-21180
> >
> > As far as I understand, this is not an official release channel but
> > rather a convenience one.
> >
> > Cheers,
> >
> > Benoit
> >
> > Le 11/12/2020 à 15:18, Jean Helou a écrit :
> >>> I propose to ask for rights on apache/james repository
> >>
> >> I'm revisiting this thread after seeing
> >> https://www.docker.com/blog/supporting-open-source-projects-at-docker
> which
> >> reminded me of this effort and I was wondering if an INFRA ticket has
> been
> >> opened for james (of if there is a trace of the progress somewhere)
> >> I'm not sur exactly how the program works but if it whitelists prefixes,
> >> Apache is most likely already in it however in light of the work on CI
> >> builds on apache infrastructure, I am wondering if/how the credentials
> for
> >> pushing form CI can be setup and I was hoping to drop a comment on the
> >> corresponding ticket.
> >>
> >> jean
> >>
> > -
> > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> > For additional commands, e-mail: server-dev-h...@james.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


[jira] [Commented] (JAMES-3564) Bugfixes to 3.6.x branch

2021-04-15 Thread Juhan Aasaru (Jira)


[ 
https://issues.apache.org/jira/browse/JAMES-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322020#comment-17322020
 ] 

Juhan Aasaru commented on JAMES-3564:
-

I agree with using "fix/version" to keep track of where the change is targeted.

If there is someone that creates a ticket and then creates a pull request to 
master then of course we can step in at any time during review and update the 
ticket with adding additional fixVersion. When the pull request gets accepted 
and merged we can ask the contributor to create a PR with the same patch 
towards bugfix release (3.6.1) but if the original contributor doesn't do it 
the of course we have to create the PR ourselves.

Regarding JAMES-3562 I don't have enough knowledge about the underlying 
details. If it is a bug then it would be good to get it to bugfix release. We 
can postpone the decision until it is merged to master.

 

 

> Bugfixes to 3.6.x branch
> 
>
> Key: JAMES-3564
> URL: https://issues.apache.org/jira/browse/JAMES-3564
> Project: James Server
>  Issue Type: Improvement
>Affects Versions: 3.6.0
>Reporter: Juhan Aasaru
>Priority: Major
> Fix For: 3.6.1
>
>
> I created this task
>  * to keep track of all the pull requests that have been made to master 
> arfter 3.6.x
>  * and decide (and discuss) which ones should also get to 3.6.x branch (and 
> which should not)
>  
> ||PR to master||PR to 3.6.x ||Ticket||
> |[#362|https://github.com/apache/james-project/pull/362]|[#382 
> |https://github.com/apache/james-project/pull/382] 
> [(/)|https://github.com/apache/james-project/pull/384]|JAMES-3537 |
> |[#374|https://github.com/apache/james-project/pull/374]|[#383 
> |https://github.com/apache/james-project/pull/383] 
> [(/)|https://github.com/apache/james-project/pull/384]|JAMES-3432 |
> |[#377|https://github.com/apache/james-project/pull/377] |waiting PR to be 
> merged first|JAMES-3557 |
> |[#378|https://github.com/apache/james-project/pull/378] |waiting PR to be 
> merged first|JAMES-3558|
> |[#379|https://github.com/apache/james-project/pull/379]|[#384 
> |https://github.com/apache/james-project/pull/384] 
> [(/)|https://github.com/apache/james-project/pull/384]|JAMES-3556 |
> |[#221|https://github.com/apache/james-project/pull/221] | waiting PR to be 
> merged first|JAMES-3261 |
> |upcoming| |JAMES-3562 |
> | | | |
> | | | |
>  
> What not to merge and why
>  
> ||PR to master||Why not||
> |[#386|https://github.com/apache/james-project/pull/386]|not targeted to 
> james repo|
> | | |
>  
>  
>  
>  
>  
> I plan to work on this myself. 
>  



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



Re: [Vote] Call for vote: Apache Mime4J 0.8.4

2021-04-15 Thread Antoine Duprat
+1

Le mer. 14 avr. 2021 à 09:09, Tellier Benoit  a écrit :

> Hi,
>
> Following a user request (https://issues.apache.org/jira/browse/MIME4J-297
> ),
>
> I would like to propose a vote for 0.8.4 release of the MIME4J library.
>
> You can find the maven release staged in repository.apache.org as the
> artifact #1053:
> https://repository.apache.org/content/repositories/orgapachejames-1053/
>
>
> Voting rules:
>  - This is a majority approval: this release may not be vetoed.
>  - A quorum of 3 binding votes is required
>  - The vote starts at Wedneday 14th of April 2021, 2pm UTC+7
>  - The vote ends at Wednesday 21th of April 2021, 2pm UTC+7
>
> You can answer to it just with +1 and -1. Down-votes may be motivated.
>
> 3 binding votes are expected move forward on this release.
>
> Cheers,
>
> Benoit Tellier
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


[jira] [Updated] (JAMES-3564) Bugfixes to 3.6.x branch

2021-04-15 Thread Juhan Aasaru (Jira)


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

Juhan Aasaru updated JAMES-3564:

Description: 
I created this task
 * to keep track of all the pull requests that have been made to master arfter 
3.6.x
 * and decide (and discuss) which ones should also get to 3.6.x branch (and 
which should not)

 
||PR to master||PR to 3.6.x ||Ticket||
|[#362|https://github.com/apache/james-project/pull/362]|[#382 
|https://github.com/apache/james-project/pull/382] 
[(/)|https://github.com/apache/james-project/pull/384]|JAMES-3537 |
|[#374|https://github.com/apache/james-project/pull/374]|[#383 
|https://github.com/apache/james-project/pull/383] 
[(/)|https://github.com/apache/james-project/pull/384]|JAMES-3432 |
|[#377|https://github.com/apache/james-project/pull/377] |waiting PR to be 
merged first|JAMES-3557 |
|[#378|https://github.com/apache/james-project/pull/378] |waiting PR to be 
merged first|JAMES-3558|
|[#379|https://github.com/apache/james-project/pull/379]|[#384 
|https://github.com/apache/james-project/pull/384] 
[(/)|https://github.com/apache/james-project/pull/384]|JAMES-3556 |
|[#221|https://github.com/apache/james-project/pull/221] | waiting PR to be 
merged first|JAMES-3261 |
|upcoming| |JAMES-3562 |
| | | |
| | | |

 

What not to merge and why

 
||PR to master||Why not||
|[#386|https://github.com/apache/james-project/pull/386]|not targeted to james 
repo|
| | |

 

 

 

 

 

I plan to work on this myself. 

 

  was:
I created this task
 * to keep track of all the pull requests that have been made to master arfter 
3.6.x
 * and decide (and discuss) which ones should also get to 3.6.x branch (and 
which should not)

 
||PR to master||PR to 3.6.x ||Ticket||
|[#362|https://github.com/apache/james-project/pull/362]|[#382 
|https://github.com/apache/james-project/pull/382] 
[(/)|https://github.com/apache/james-project/pull/384]|JAMES-3537 |
|[#374|https://github.com/apache/james-project/pull/374]|[#383 
|https://github.com/apache/james-project/pull/383] 
[(/)|https://github.com/apache/james-project/pull/384]|JAMES-3432 |
|[#377|https://github.com/apache/james-project/pull/377] |waiting PR to be 
merged first|JAMES-3557 |
|[#378|https://github.com/apache/james-project/pull/378] |waiting PR to be 
merged first|JAMES-3558|
|[#379|https://github.com/apache/james-project/pull/379]|[#384 
|https://github.com/apache/james-project/pull/384]|JAMES-3556 |
|[#221|https://github.com/apache/james-project/pull/221] | waiting PR to be 
merged first|JAMES-3261 |
|upcoming| |JAMES-3562 |
| | | |
| | | |

 

What not to merge and why

 
||PR to master||Why not||
|[#386|https://github.com/apache/james-project/pull/386]|not targeted to james 
repo|
| | |

 

 

 

 

 

I plan to work on this myself. 

 


> Bugfixes to 3.6.x branch
> 
>
> Key: JAMES-3564
> URL: https://issues.apache.org/jira/browse/JAMES-3564
> Project: James Server
>  Issue Type: Improvement
>Affects Versions: 3.6.0
>Reporter: Juhan Aasaru
>Priority: Major
> Fix For: 3.6.1
>
>
> I created this task
>  * to keep track of all the pull requests that have been made to master 
> arfter 3.6.x
>  * and decide (and discuss) which ones should also get to 3.6.x branch (and 
> which should not)
>  
> ||PR to master||PR to 3.6.x ||Ticket||
> |[#362|https://github.com/apache/james-project/pull/362]|[#382 
> |https://github.com/apache/james-project/pull/382] 
> [(/)|https://github.com/apache/james-project/pull/384]|JAMES-3537 |
> |[#374|https://github.com/apache/james-project/pull/374]|[#383 
> |https://github.com/apache/james-project/pull/383] 
> [(/)|https://github.com/apache/james-project/pull/384]|JAMES-3432 |
> |[#377|https://github.com/apache/james-project/pull/377] |waiting PR to be 
> merged first|JAMES-3557 |
> |[#378|https://github.com/apache/james-project/pull/378] |waiting PR to be 
> merged first|JAMES-3558|
> |[#379|https://github.com/apache/james-project/pull/379]|[#384 
> |https://github.com/apache/james-project/pull/384] 
> [(/)|https://github.com/apache/james-project/pull/384]|JAMES-3556 |
> |[#221|https://github.com/apache/james-project/pull/221] | waiting PR to be 
> merged first|JAMES-3261 |
> |upcoming| |JAMES-3562 |
> | | | |
> | | | |
>  
> What not to merge and why
>  
> ||PR to master||Why not||
> |[#386|https://github.com/apache/james-project/pull/386]|not targeted to 
> james repo|
> | | |
>  
>  
>  
>  
>  
> I plan to work on this myself. 
>  



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



Re: [Vote] Call for vote: Apache Mime4J 0.8.4

2021-04-15 Thread Jean Helou
Hi benoit,

The changelog has not been updated which is a bit sad (and i know it's
painful to do but it's s helpful for developers who use the library)
On a semi-related note : the release notes have not been updated either but
that last file actually seems to be totally out of sync with the repo : it
mentions an inexistant 0.9.0 and has not been modified for the last 4 years
... maybe delete it ?

jean

On Wed, Apr 14, 2021 at 9:09 AM Tellier Benoit  wrote:

> Hi,
>
> Following a user request (https://issues.apache.org/jira/browse/MIME4J-297
> ),
>
> I would like to propose a vote for 0.8.4 release of the MIME4J library.
>
> You can find the maven release staged in repository.apache.org as the
> artifact #1053:
> https://repository.apache.org/content/repositories/orgapachejames-1053/
>
>
> Voting rules:
>  - This is a majority approval: this release may not be vetoed.
>  - A quorum of 3 binding votes is required
>  - The vote starts at Wedneday 14th of April 2021, 2pm UTC+7
>  - The vote ends at Wednesday 21th of April 2021, 2pm UTC+7
>
> You can answer to it just with +1 and -1. Down-votes may be motivated.
>
> 3 binding votes are expected move forward on this release.
>
> Cheers,
>
> Benoit Tellier
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>