Re: Call for vote: Apache James 3.8.0

2023-05-18 Thread Vincenzo Gianferrari Pini
+1

Vincenzo

Il Ven 19 Mag 2023, 04:27 Rene Cordier  ha scritto:

> +1,
>
> Rene.
>
> On 19/05/2023 09:23, Benoit TELLIER wrote:
> > Hi,
> >
> > I would like to propose a new vote for 3.8.0 release of the Apache James
> > server.
> >
> > You can find:
> >
> >   - The maven release staged in repository.apache.org as the artifact
> > #1074:
> > https://repository.apache.org/content/repositories/orgapachejames-1074/
> >   - The changelog for 3.8.0:
> > https://github.com/apache/james-project/pull/1568
> >   - The compatibility instructions/upgrade recommendation:
> > https://github.com/apache/james-project/pull/1568
> >
> > This release brings the following significant changes:
> >
> >   - Upgrade TCP protocols to Netty 4
> >   - Migrate IMAP protocol as reactive
> >   - Multiple additional IMAP extensions are implemented
> >   - Upgrade to Cassandra driver 4
> >   - Migrate to OpenSearch for license purposes
> >   - Review our threading model to cap threads performing blocking tasks
> >   - Implement official JMAP quotas specification
> >
> > 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 Friday 19th of June 2023, 9am30 UTC+7
> >   - The vote ends at Friday 26th of June 2023, 9am30 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 in the name of the Apache James PMC.
> >
> >
> > -
> > 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James 3.7.4

2023-03-24 Thread Vincenzo Gianferrari Pini
+1

Vincenzo


Il Ven 24 Mar 2023, 03:56 Rene Cordier  ha scritto:

> +1
>
> Rene.
>
> On 24/03/2023 00:21, Benoit TELLIER wrote:
> > Hi,
> >
> > I would like to propose a new vote for 3.7.4 release of the Apache James
> > server.
> >
> > You can find:
> >
> >   - The maven release staged in repository.apache.org as the artifact
> > #1073:
> > https://repository.apache.org/content/repositories/orgapachejames-1073/
> >   - The changelog for 3.7.4:
> > https://github.com/apache/james-project/blob/master/CHANGELOG.md
> >   - The compatibility instructions/upgrade recommendation:
> >
> https://github.com/apache/james-project/blob/master/upgrade-instructions.md#374-version
> >
> > There is only minor fixes part of this release.
> >
> > 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 Thursday 24th of March 2023, 6pm UTC+1
> >   - The vote ends at Thursday 31st of March 2023, 6pm UTC+1
> >
> > 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,
> >
> > 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James 3.7.3

2022-12-30 Thread Vincenzo Gianferrari Pini
+1

Vincenzo

Il Ven 30 Dic 2022, 11:21 Benoit TELLIER  ha scritto:

> Hi,
>
> I would like to propose a new vote for 3.7.3 release of the Apache James
> server.
>
> You can find:
>
>   - The maven release staged in repository.apache.org as the artifact
> #1072:
> https://repository.apache.org/content/repositories/orgapachejames-1072/
>   - Changelog entries and related documentation:
> https://github.com/apache/james-project/pull/1368
>   - No specific upgrade instructions for this release.
>
> This release:
>
>   - Fixes logging for now legacy Spring packaging
>   - Comprise some other bug fixes
>   - Brings security related dependency updates
>
> 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 Friday 30th of December 2022, 4pm UTC+7
>   - The vote ends at Friday 6th of January 2022, 4pm 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James MIME4J 0.8.9

2022-12-30 Thread Vincenzo Gianferrari Pini
+1

Vincenzo

Il Ven 30 Dic 2022, 08:19 Benoit TELLIER  ha scritto:

> Hi,
>
> I would like to propose a new vote for 0.8.9 release of the Apache James
> MIME4J library.
>
> You can find:
>
>   - The maven release staged in repository.apache.org as the artifact
> #1070:
> https://repository.apache.org/content/repositories/orgapachejames-1070/
>   - The changelog for 0.8.9:
> https://github.com/apache/james-mime4j/pull/83
>   - The blog post for this release:
> https://github.com/apache/james-project/pull/1370
>
> This release comprise small bug fixes and enhancements.
>
> 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 Friday 30th of December 2022, 3pm UTC+7
>   - The vote ends at Friday 6th of January 2022, 3pm 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James JSPF 1.0.3

2022-12-30 Thread Vincenzo Gianferrari Pini
+1

Vincenzo

Il Ven 30 Dic 2022, 08:24 Benoit TELLIER  ha scritto:

> Hi,
>
> I would like to propose a new vote for 1.0.3 release of the Apache James
> JSPF library.
>
> You can find:
>
>   - The maven release staged in repository.apache.org as the artifact
> #1071:
> https://repository.apache.org/content/repositories/orgapachejames-1071/
>   - The blog post for this release:
> https://github.com/apache/james-project/pull/1369
>
> This release fixes error handling for asynchronous JSPF executors.
>
> 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 Friday 30th of December 2022, 3pm UTC+7
>   - The vote ends at Friday 6th of January 2022, 3pm 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James Mime4J 0.8.8

2022-10-29 Thread Vincenzo Gianferrari Pini
+1
Vincenzo


On Fri, Oct 28, 2022 at 4:28 AM Benoit TELLIER  wrote:

> Hi,
>
> I would like to propose a new vote for 0.8.8 release of the Apache James
> MIME4J library.
>
> You can find:
>
>   - The maven release staged in repository.apache.org as the artifact
> #1067:
> https://repository.apache.org/content/repositories/orgapachejames-1067/
>   - The changelog for 0.8.8:
> https://github.com/apache/james-mime4j/pull/79
>
> 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 Friday 28th of October 2022, 10am UTC+7
>   - The vote ends at Friday 4th of November 2022, 10am 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James JSPF 1.0.2

2022-10-29 Thread Vincenzo Gianferrari Pini
+1
Vincenzo


On Fri, Oct 28, 2022 at 6:13 AM Benoit TELLIER  wrote:

> I would like to propose a new vote for 1.0.2 release of the Apache James
> JSPF library.
>
> You can find:
>
>   - The maven release staged in repository.apache.org as the artifact
> #1069:
> https://repository.apache.org/content/repositories/orgapachejames-1069/
>
>
> 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 Friday 28th of October 2022, 11am30 UTC+7
>   - The vote ends at Friday 4th of November 2022, 11am30 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James JSieve 0.8

2022-10-29 Thread Vincenzo Gianferrari Pini
+1
vincenzo


On Fri, Oct 28, 2022 at 5:48 AM Benoit TELLIER  wrote:

> I would like to propose a new vote for 0.8 release of the Apache James
> JSieve library.
>
> You can find:
>
>   - The maven release staged in repository.apache.org as the artifact
> #1068:
> https://repository.apache.org/content/repositories/orgapachejames-1068/
>   - The changelog for 0.8: https://github.com/apache/james-jsieve/pull/25
>
>
> 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 Friday 28th of October 2022, 11am UTC+7
>   - The vote ends at Friday 4th of November 2022, 11am 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Vote: Apache James JDKIM 0.3 [Call 2]

2022-10-13 Thread Vincenzo Gianferrari Pini
+1

Vincenzo



Il Lun 10 Ott 2022, 03:14 Benoit TELLIER  ha scritto:

> Hi,
>
> I would like to propose a new vote for 0.3 release of the Apache James
> JDKIM library.
>
> You can find the maven release staged in repository.apache.org as the
> artifact #1065:
> https://repository.apache.org/content/repositories/orgapachejames-1065/
>
> 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 Monday 10th of October 2022, 8am UTC+7
>   - The vote ends at Monday 17th of October 2022, 8am 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James 3.7.2

2022-10-13 Thread Vincenzo Gianferrari Pini
+1
Vincenzo



Il Ven 7 Ott 2022, 09:26 Benoit TELLIER  ha scritto:

> Hi,
>
> I would like to propose a new vote for 3.7.2 release of the Apache James
> server.
>
> You can find:
>
>   - The maven release staged in repository.apache.org as the artifact
> #1066:
> https://repository.apache.org/content/repositories/orgapachejames-1066/
>   - The communication material for release 3.7.2:
> https://github.com/apache/james-project/pull/1234
>
> This release brings various fixes and enhancements. Some security
> related dependency upgrades where done.
>
> 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 Friday 7th of October 2022, 2pm30 UTC+7
>   - The vote ends at Friday 14th of October 2022, 2pm30 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James JDKIM 0.3

2022-10-02 Thread Vincenzo Gianferrari Pini
+1
Vincenzo




Il Dom 2 Ott 2022, 11:06 Benoit TELLIER  ha scritto:

> +1
>
> On 02/10/2022 16:06, Benoit TELLIER wrote:
> > Hi,
> >
> > I would like to propose a new vote for 0.3 release of the Apache James
> > JDKIM library.
> >
> > You can find the maven release staged in repository.apache.org as the
> > artifact #1065:
> > https://repository.apache.org/content/repositories/orgapachejames-1065/
> >
> > 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 Sunday 2nd of October 2022, 4pm UTC+7
> >  - The vote ends at Sunday 9th of October 2022, 4pm 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James 3.7.1

2022-08-29 Thread Vincenzo Gianferrari Pini
+1

Vincenzo




Il Lun 29 Ago 2022, 04:30 Rene Cordier  ha scritto:

> +1,
> Rene.
>
> On 26/08/2022 18:12, Benoit TELLIER wrote:
> > |Hi, I would like to propose a new vote for 3.7.1 release of the Apache
> > James server. You can find: - The maven release staged in
> > repository.apache.org as the artifact #1064:
> > https://repository.apache.org/content/repositories/orgapachejames-1064/
> > - The changelog for 3.7.1:
> > https://github.com/apache/james-project/pull/1160 - The compatibility
> > instructions/upgrade recommendation:
> >
> https://github.com/apache/james-project/blob/master/upgrade-instructions.md#371-version
> > This release includes a few bug fixes 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 Friday 26th of August 2022, 6pm UTC+7 -
> > The vote ends at Friday 2nd of September 2022, 6pm 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, PMC member name |
> >
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James MIME4J 0.8.7

2022-04-03 Thread Vincenzo Gianferrari Pini
+1

Vincenzo



___

Ing. Vincenzo Gianferrari Pini



Il Ven 1 Apr 2022, 12:35 Rene Cordier  ha scritto:

> +1,
> Rene.
>
> On 01/04/2022 12:04, Benoit TELLIER wrote:
> > |Subject: Hi, I would like to propose a new vote for 0.8.7 release of
> > the Apache James MIME4J library. You can find: - The maven release
> > staged in repository.apache.org as the artifact #1063:
> > https://repository.apache.org/content/repositories/orgapachejames-1063/
> > - The changelog for 0.8.7:
> >
> https://github.com/apache/james-mime4j/blob/master/CHANGELOG.md#087---2022-04-01
> > - Announce: https://github.com/apache/james-project/pull/947 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 Friday 1st
> > of April, 12pm UTC+7 - The vote ends at Friday 8th of April, 12pm UTC+7
> > You can answer to it just with +1 and -1. Down-votes may be motivated.
> > Non binding votes are encouraged. 3 binding votes are expected move
> > forward on this release. 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
<mailto:amministrazi...@gocloud.it>* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it <mailto:amministrazi...@gocloud.it> 
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: [VOTE] Apache James release 3.7.0

2022-03-07 Thread Vincenzo Gianferrari Pini
+1

Vincenzo



___

Ing. Vincenzo Gianferrari Pini



Il Mer 2 Mar 2022, 04:44 Tellier Benoit  ha scritto:

> Hi,
>
> I would like to propose a new vote for 3.7.0 release of the Apache James
> server.
>
> You can find:
>
>  - The maven release staged in repository.apache.org as the
> artifact #1062:
> https://repository.apache.org/content/repositories/orgapachejames-1062/
>  - The changelog for
> 3.7.0:
> https://github.com/apache/james-project/blob/master/CHANGELOG.md#unreleased
>  - Changes to our doc and the website:
> https://github.com/apache/james-project/pull/900
>  - Release artifacts are uploaded to ASF dowloads.
>
> This release introduces some major bug fixes, stability enhancements and
> some cool additional components and features!
>
> 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 Wednesday 2nd of March 2022, 10am UTC+7
>  - The vote ends at Wednesday 9th of March 2022, 10am 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
<mailto:amministrazi...@gocloud.it>* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it <mailto:amministrazi...@gocloud.it> 
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: [VOTE] Apache James release 3.6.2

2022-01-28 Thread Vincenzo Gianferrari Pini
+1

Vincenzo


Il Gio 27 Gen 2022, 08:08 Benoit TELLIER  ha scritto:

> Hello,
>
> Sorry for the bad formatting.
>
> I would like to propose a new vote for 3.6.2 release of the Apache James
> server.
>
> You can find:
>
> - The maven release staged in repository.apache.org as the artifact
> #1061:
> https://repository.apache.org/content/repositories/orgapachejames-1061/
>
> - The changelog for 3.6.2 and & the compatibility instructions/upgrade
> recommendation: https://github.com/apache/james-project/pull/865
>
> 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 Thursday 27th of January 2022, 11am UTC+7
>   - The vote ends at Thursday 3rd of February 2022, 11am 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
>
> On 27/01/2022 11:50, Benoit TELLIER wrote:
> > |I would like to propose a new vote for 3.6.2 release of the Apache
> > James server. You can find: - The maven release staged in
> > repository.apache.org as the artifact #1061:
> > https://repository.apache.org/content/repositories/orgapachejames-1061/
> > - The changelog for 3.6.2 and |||hhe compatibility
> > instructions/upgrade recommendation:
> > |https://github.com/apache/james-project/pull/865 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 Thursday 27th of
> > January 2022, 11am UTC+7 - The vote ends at |||Thursday| 3rd of
> > February 2022, 11am 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: [IMPORTANT] Call for vote: Apache James 3.6.1 (3rd edition...)

2021-12-15 Thread Vincenzo Gianferrari Pini
+1

Vincenzo


On Thu, Dec 16, 2021 at 8:44 AM Antoine Duprat  wrote:

> +1
>
> Antoine
>
> Le jeu. 16 déc. 2021 à 08:27, btell...@apache.org  a
> écrit :
>
> > Hi,
> >
> > I would like to propose a new vote for 3.6.1 release of the Apache James
> > server.
> >
> > This time, as discussed on the JIRA this includes upgrade to Log4J
> 2.16.0.
> >
> > You can find:
> >
> >  - The maven release staged in repository.apache.org as the artifact
> > #1058:
> > https://repository.apache.org/content/repositories/orgapachejames-1058/
> <
> > https://repository.apache.org/content/repositories/orgapachejames-1058/>
> >  - The changelog for 3.6.1:
> >
> https://github.com/chibenwa/james-project/blob/changelog-3.6.1/CHANGELOG.md
> > <
> >
> https://github.com/chibenwa/james-project/blob/changelog-3.6.1/CHANGELOG.md
> > >
> > (to be merged on master)
> >  - The compatibility instructions/upgrade
> > recommendation:
> >
> >
> https://github.com/chibenwa/james-project/blob/changelog-3.6.1/upgrade-instructions.md#361-version
> > <
> >
> https://github.com/chibenwa/james-project/blob/changelog-3.6.1/upgrade-instructions.md#361-version
> > >
> >
> > This release is only comprised of bug fixes.
> >
> > 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 Thursday 16th of December 2021, 2pm30 UTC+7
> >  - The vote ends at Saturday 18th of December 2021, 2pm30 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,
> >
> > PMC member name
> >
> >
> > -
> > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> > For additional commands, e-mail: server-dev-h...@james.apache.org
> >
> >
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James 3.6.1

2021-12-07 Thread Vincenzo Gianferrari Pini
+1

Vincenzo





___

Ing. Vincenzo Gianferrari Pini

Liquidatore - GoCloud S.r.l

Sede legale: Via Larga 15, 20122 Milano (MI)

Cel. +39-3939837493

fax: +39-02-25514302



https://google.com/+VincenzoGianferrariPiniGoCloud

https://www.linkedin.com/in/vgianferrari

http://www.gocloud.eu






Il Ven 3 Dic 2021, 02:30 btell...@apache.org  ha
scritto:

> Hi,
>
> I would like to propose a new vote for 3.6.1 release of the Apache James
> server.
>
> You can find:
>
>  - The maven release staged in repository.apache.org as the artifact
> #1056:
> https://repository.apache.org/content/repositories/orgapachejames-1056/
>  - The changelog for 3.6.1:
> https://github.com/chibenwa/james-project/blob/changelog-3.6.1/CHANGELOG.md
> (to be merged on master)
>  - The compatibility instructions/upgrade
> recommendation:
>
> https://github.com/chibenwa/james-project/blob/changelog-3.6.1/upgrade-instructions.md#361-version
>
> This release is only comprised of bug fixes.
>
> 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 Friday 3rd of December 2021, 8am30 UTC+7
>  - The vote ends at Friday 10th of December 2021, 8am30 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,
>
> PMC member name
>
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
<mailto:amministrazi...@gocloud.it>* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it <mailto:amministrazi...@gocloud.it> 
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache JAMES MIME4J

2021-09-17 Thread Vincenzo Gianferrari Pini
+1

Vincenzo






Il Ven 17 Set 2021, 13:01 btell...@apache.org  ha
scritto:

> +1
>
> On 17/09/2021 17:59, btell...@apache.org wrote:
> > |Subject: Hi, I would like to propose a new vote for 0.8.6 release of
> > the Apache MIME4J library. You can find: - The maven release staged in
> > repository.apache.org as the artifact #1055:
> > https://repository.apache.org/content/repositories/orgapachejames-1055/
> > - The changelog for MIME4J 0.8.6:
> > https://github.com/apache/james-mime4j/pull/56 This release focused on
> > some further performance enhancements described in this email:
> > https://www.mail-archive.com/server-dev@james.apache.org/msg70470.html
> > 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
> > Friday 17th of September 2021, 6pm UTC+7 - The vote ends at Friday 24th
> > of September 2021, 6pm 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, 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
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


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

2021-04-14 Thread Vincenzo Gianferrari Pini
+1

Vincenzo


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

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


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

2021-04-06 Thread Vincenzo Gianferrari Pini
+1

Vincenzo


On Tue, Apr 6, 2021 at 9:28 AM Rémi Kowalski <
remi.florian.kowal...@gmail.com> wrote:

> +1
>
> Le mar. 6 avr. 2021 à 09:04, Tellier Benoit  a écrit
> :
>
> > I would like to propose a new vote 3.6.0 release of the Apache James
> > server.
> >
> > After an initial mistake (sorry), a failed vote (could not achieve a PMC
> > quorum), and more issues I did not yet complain about (closing the maven
> > artifact #1051 failed for a missing MD5 signature - network issue?),
> > here we are with one more vote !!!
> >
> > You can find:
> >
> > - The maven release staged in repository.apache.org as the artifact
> #1052:
> > https://repository.apache.org/content/repositories/orgapachejames-1052/
> > - The changelog for 3.6.0:
> >  https://github.com/apache/james-project/blob/master/CHANGELOG.md
> > - The compatibility instructions/upgrade recommendation:
> >
> >
> https://github.com/apache/james-project/blob/master/upgrade-instructions.md#360-version
> >
> > 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 Tuesday 6th of April 2021, 2pm UTC+7
> >  - The vote ends at Tuesday 13th of March 2021, 2pm UTC+7
> >
> > You can answer to it just with +1 and -1. Down-votes shall be motivated.
> >
> > 3 binding votes are expected move forward on this release.
> >
> > Cheers,
> >
> > Benoit Tellier
> >
> > Le 30/03/2021 à 17:16, Tellier Benoit a écrit :
> > > The voting period is over.
> > >
> > > Only one upvote had been collected this time. We did not achieve the 3
> > > PMC quorum, and other contributors did not vote as well.
> > >
> > > I will re-trigger a vote, this is a good opportunity to integrate
> > > https://github.com/apache/james-project/pull/349
> > >
> > > Cheers,
> > >
> > > Benoit
> > >
> > > Le 22/03/2021 à 15:16, Tellier Benoit a écrit :
> > >> Hi,
> > >>
> > >> I would like to propose a new vote 3.6.0 release of the Apache James
> > server.
> > >>
> > >> You can find:
> > >>
> > >>  - The maven release staged in repository.apache.org as the
> > >> artifact #1050:
> > >>
> https://repository.apache.org/content/repositories/orgapachejames-1050/
> > >>  - The changelog for
> > >> 3.6.0:
> > >> https://github.com/apache/james-project/blob/master/CHANGELOG.md
> > >>  - The compatibility instructions/upgrade
> > >> recommendation:
> > >>
> >
> https://github.com/apache/james-project/blob/master/upgrade-instructions.md#360-version
> > >>
> > >> 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 Monday 22th of March 2021, 4pm UTC+7
> > >>  - The vote ends at Monday 29th of March 2021, 4pm 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
> > >
> >
> > -
> > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> > For additional commands, e-mail: server-dev-h...@james.apache.org
> >
> >
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James 3.5.0

2020-07-22 Thread Vincenzo Gianferrari Pini
+1

Vincenzo




Il Gio 16 Lug 2020, 08:44 Tellier Benoit  ha scritto:

> Hi,
>
> I would like to propose a new vote 3.5.0 release of the Apache James
> server.
>
> I fixes Matthieu remarks since last proposal.
>
> You can see changes proposed to the website at the occasion
> of that release on this GitHub pull
> request: https://github.com/apache/james-project/pull/187
>
> You can find:
>
>  - The maven release staged in repository.apache.org as the
> artifact #1048:
> https://repository.apache.org/content/repositories/orgapachejames-1048/
>  - The changelog for
> 3.5.0:
> https://github.com/chibenwa/james-project/blob/website-3.5.0/CHANGELOG.md
>  - The compatibility instructions/upgrade
> recommendation:
>
> https://github.com/chibenwa/james-project/blob/website-3.5.0/upgrade-instructions.md
>
> 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 Thursday 16th of July 2020, 1pm UTC+7
>  - The vote ends at Thursday 23th of July 2020, 2pm UTC+7
>
> You can answer to it just with +1 and -1. Down-votes may be motivated.
>
> Cheers,
>
> Benoit Tellier
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: [Vote] migration to java 11

2019-10-25 Thread Vincenzo Gianferrari Pini
+1



___

Ing. Vincenzo Gianferrari Pini

Liquidatore - GoCloud S.r.l

Sede legale: Via Larga 15, 20122 Milano (MI)

Cel. +39-3939837493

fax: +39-02-25514302



https://google.com/+VincenzoGianferrariPiniGoCloud

https://www.linkedin.com/in/vgianferrari

http://www.gocloud.eu






Il Ven 25 Ott 2019, 08:38 Antoine Duprat  ha scritto:

> +1
>
> Le jeu. 24 oct. 2019 à 16:43, Matthieu Baechler  a
> écrit :
>
> > Hi,
> >
> > I would like to propose the migration to Java 11 as a runtime.
> >
> > I opened an ADR here: https://github.com/apache/james-project/pull/174
> >
> > Here is the content of this ADR:
> >
> > ---
> > # 9. Migration to Java Runtime Environment 11
> >
> > Date: 2019-10-24
> >
> > ## Status
> >
> > Proposed
> >
> > ## Context
> >
> > Java 11 is the only "Long Term Support" java release right now so more
> > and more people will use it exclusively.
> >
> > James is known to build with Java Compiler 11 for some weeks.
> >
> > ## Decision
> >
> > We adopt Java Runtime Environment 11 for James as a runtime to benefits
> > from a supported runtime and new features
> > of the languages and the platform.
> >
> > ## Consequences
> >
> > * It requires the upgrade of Spring to 4.3.x.
> > * All docker images should be updated to adoptopenjdk 11.
> > * The documentation should be updated accordingly.
> >
> > ---
> >
> > Voting rules:
> >
> > I do propose a vote to ensure consensus on it:
> >  - Answer this mail with "+1" to support this decision
> >  - Answer this mail with "-1" if you reject this decision
> >
> > Negative votes should be motivated. Voting ends on 31th October 2019
> > 8am UTC.
> >
> > Cheers,
> >
> > --
> > Matthieu Baechler
> >
> >
> > -
> > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> > For additional commands, e-mail: server-dev-h...@james.apache.org
> >
> >
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
<mailto:amministrazi...@gocloud.it>* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it <mailto:amministrazi...@gocloud.it> 
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: [Call for vote] Post 3.3.0 Components deprecation

2019-03-28 Thread Vincenzo Gianferrari Pini
+1 for all components

Vincenzo




Il Gio 28 Mar 2019, 09:27 Benoit Tellier  ha scritto:

> Hi,
>
> In order to improve overall James development experience, I propose to
> do a bit of post 3.3.0 cleanup.
>
> The proposal is to mark the given components as deprecated now, then, if
> no contributor shows up and give some love to these components, remove
> it after 3.4.0 release.
>
> I do propose a vote to ensure consensus on it:
>  - Answer this mail with "+1 for all components" to support all these
> deprecations
>  - Answer this mail with "-1 for all components" if you reject the idea
> of removing components
>  - Answer this mail with "+1 [components] -1 [components]" to express
> per component not favorable opinion.
>
> Negative votes should be motivated (and ideally have contributors for
> these components). Voting ends on 4th April 9am UTC
>
> Here are the rationals:
>  - Some components are not exposed to end users and affect our hability
> to refactor code.
>  - These components do not receive contributions
>  - These components are not well enough tested
>  - We introduced some components that are better at performing that very
> task
>
> See associated ticket: https://issues.apache.org/jira/browse/JAMES-2703
>
> The components are:
>
> ## mailbox
>
>  - mailbox/cache
>Unused, not tested, low code quality
>End user will not be affected by this removal
>
> ## server/data
>
>  - SieveDefaultRepository
>Read the filesystem to retrieve sieve scripts, read only, one file
> per user
>This does not support sieve script management and rtequires dropping
> manually the filesystem
>Migration strategy: use SieveFileRepository & CLI to upload scripts
>
>  - MBoxFileRepository
>Already deprecated, will target removal after 3.4.0
>Use FileMailRepository instead. Data migration can be done with
> reprocessing + specific configuration
>
>  - JDBCRecipientRewriteTable
>Already deprecated, will target removal after 3.4.0
>Use another RRT implementation
>
>  - AbstractJdbcUsersRepository DefaultUsersJdbcRepository &
> JamesUsersJdbcRepository
>Already deprecated, will target removal after 3.4.0
>Use another UsersRepository implementation
>
> ## mailets
>
> Note: these mailets are leveraging some storage capabilities of mailbox
> or server/data.
>
>  - AbstractRecipientRewriteTable
>Already deprecated, will target removal after 3.4.0
>The mailet is responsible of the rule storage.  No tests.
>Note that this would allow removing JDBCRecipientRewriteTable and
> XMLRecipientRewriteTable.
>Migration plan: add the rules in the standard RRT and use the classic
> RRT mailet.
>
>  - JDBCAlias
>Already deprecated, will target removal after 3.4.0
>This mailet does the RRT. No tests.
>Migration plan: add the rules in the standard RRT and use the classic
> RRT mailet.
>
>  - UsersRepositoryAliasingForwarding
>Already deprecated, will target removal after 3.4.0
>This buggy mailet expects the UsersRepository to be also a
> RecipientRewriteTable. Hopefully we have no such freaks.
>Otherwize behaves as the classic RRT mailet.
>Migration: Replace in the configuration by the classic RRT mailet
>
>  - MailboxQuotaFixed, AbstractStorageQuota, AbstractQuotaMatcher
>Not using the quota API, these matchers do full inbox scans on each
> processed email.
>It adds confiusion with the non-experimental  well tests IsOverQuota
> matcher, relying on the mailbox quota system.
>No test, big hierarchy
>Migration plan: Use IsOverQuota + quota APIs
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: MIME4J 0.8.3

2019-03-21 Thread Vincenzo Gianferrari Pini
+1

Vincenzo



Il giorno gio 14 mar 2019 alle ore 10:54 Benoit Tellier <
btell...@linagora.com> ha scritto:

> Hi,
>
> I would like to propose the 0.8.3 release of the Apache MIME4J library.
>
> You can see changes proposed to the website at the occasion
> of that release, as well as communication on this GitHub pull request:
> https://github.com/linagora/james-project/pull/2243
>
>  - The maven release staged in http://repository.apache.org/ as the
> artifact #1043
>  - 0.8.3 sources and binaries are uploaded on Apache dist
> https://dist.apache.org/repos/dist/release/james/mime4j/0.8.3/
>
> Changes includes in this release:
>
>  - MIME4J-270: Using "alternative" as default subtype
>  - MIME4J-263: decoding encoded words with empty encoded-text
>  - MIME4J-279: Fixed JavaDoc errors to comply with Java8
>  - MIME4J-280: Improve exception handling
>  - MIME4J-283: DecoderUtil performance fix
>
> 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 Tuesday 14th of March 2019, 5pm UTC
>  - The vote ends at Tuesday 21th of March 2019, 5pm UTC
>
> You can answer to it just with +1 and -1. Down-votes may be motivated.
>
> Cheers,
>
> Benoit Tellier
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: Apache James 3.3.0

2019-03-21 Thread Vincenzo Gianferrari Pini
+1

Vincenzo






Il giorno lun 18 mar 2019 alle ore 10:01 Antoine Duprat 
ha scritto:

> Hi,
>
> I would like to propose the 3.3.0 release of the Apache James server.
>
> You can see changes proposed to the website at the occasion
> of that release, as well as communication on this GitHub pull
> request:https://github.com/linagora/james-project/pull/2169
>
> You can find:
>
>  - The maven release staged in http://repository.apache.org/ as the
> artifact #1042
>  - 3.3.0 sources and binaries are uploaded on Apache dist. Please note
> that we included JPA Guice and JPA SMTP guice.
>  - The changelog for
> 3.3.0:
> https://github.com/linagora/james-project/blob/9706e15a627ee0cb9065980899f5e817d2817057/CHANGELOG.md
>  - The compatibility instructions/upgrade
> recommendation:
> https://github.com/linagora/james-project/blob/9706e15a627ee0cb9065980899f5e817d2817057/upgrade-instructions.md
>
> 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 Monday 18th of March 2019, 9pm00 UTC
>  - The vote ends at Monday 25th of March 2019, 9pm00 UTC
>
> You can answer to it just with +1 and -1. Down-votes may be motivated.
>
> Cheers,
>
> Antoine
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.


This 
e-mail and any  attachments thereto are confidential and may be covered by 
legal professional privilege or otherwise protected from disclosure. If you 
are not the intended recipient, please notify us immediately by email to 
the address _amministrazi...@gocloud.it  
and then immediately destroy this message and any attachments from your 
system, without copying or disclosing the contents to any other person. 
Thank you for your co-operation._


Re: Call for vote: mime4J version 0.8.1

2017-06-11 Thread Vincenzo Gianferrari Pini
+1

Thanks,
Vincenzo

Il giorno dom 11 giu 2017 alle ore 07:35 Manuel Carrasco Moñino <
man...@apache.org> ha scritto:

> +1
>
> Thanks
>
> On Fri, Jun 9, 2017, 6:06 AM aduprat  wrote:
>
> > +1
> >
> >
> > Le 09/06/2017 à 05:09, Benoit Tellier a écrit :
> > > Hello,
> > >
> > > I would like to call a vote for a mime4J release.
> > >
> > > This release includes:
> > >
> > >   - Work on the MIME4J DOM date:
> > > - provide a way to know the header Date is absent
> > > - correction of header parsing when century is absent
> > >
> > > This release is a requirement for James 3.0 upcoming release (we should
> > > not depend on SNAPSHOT dependencies).
> > >
> > > This is a majority approval, as described in
> > > http://www.apache.org/foundation/glossary.html#MajorityApproval. As a
> > > reminder:
> > >   - 3 binding +1 required (PMCs)
> > >   - Majority of +1
> > >   - This can not be vetoed
> > >
> > > You can check the maven release artifact:
> > >   - https://repository.apache.org/#stagingRepositories #1013
> > >
> > > Answer this email with:
> > >   +1 to promote the release
> > >   -1 to reject the release
> > >
> > > The starts from 10 am 9th June 2017 UTC+7 and will be closed on 10 am
> > > 16th June 2017 UTC+7 (one week)
> > >
> > > Best regards,
> > >
> > > Tellier Benoit
> > >
> > > -
> > > 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
> >
> >
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by email to the address *amministrazi...@gocloud.it 
* and then immediately destroy this message and 
any attachments from your system, without copying or disclosing the 
contents to any other person. Thank you for your co-operation.


Re: Release james-server into 3.0.0-RC1

2017-05-11 Thread Vincenzo Gianferrari Pini
+1

Vincenzo

Il giorno gio 11 mag 2017 alle ore 04:10 Benoit Tellier <
btell...@linagora.com> ha scritto:

> +1
>
> Le 11/05/2017 à 01:25, aduprat a écrit :
> > Hello every one,
> >
> > I'm very happy to announce the vote for the upcoming 3.0.0-RC1 version
> > of our beloved james server.
> >
> > You can access sources on github
> >
> > https://github.com/apache/james-project/releases
> >
> > Nexus artifact to be released can be found here :
> > https://repository.apache.org/#stagingRepositories
> >
> > It is number #1012
> >
> > Moreover I uploaded compiled zip, along with md5 and sha1 sums, all
> signed.
> >
> >
> http://www.apache.org/dist/james/server/james-server-app-3.0.0-RC1-app.zip
> >
> http://www.apache.org/dist/james/server/james-server-app-3.0.0-RC1-app.zip.asc
> >
> >
> http://www.apache.org/dist/james/server/james-server-app-3.0.0-RC1-app.zip.md5
> >
> >
> http://www.apache.org/dist/james/server/james-server-app-3.0.0-RC1-app.zip.md5.asc
> >
> >
> http://www.apache.org/dist/james/server/james-server-app-3.0.0-RC1-app.zip.sha1
> >
> >
> http://www.apache.org/dist/james/server/james-server-app-3.0.0-RC1-app.zip.sha1.asc
> >
> >
> > According to Release policy, we need a majority vote :
> >  - At least 3 PMC
> >  - A majority of voters
> >  - This release can't be vetoed
> >
> > Followhttp://www.apache.org/dev/release.html  for more details.
> >
> > To vote, you can reply to this email with
> >
> > +1
> >
> > If you accept the release
> >
> > -1
> >
> > If you reject the release
> >
> > Votes will close on Monday 15th May 2017, 8am CET.
> >
> > Regards,
> >
> > Antoine Duprat
> >
> >
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by email to the address *amministrazi...@gocloud.it 
* and then immediately destroy this message and 
any attachments from your system, without copying or disclosing the 
contents to any other person. Thank you for your co-operation.


Re: Call for vote: new website

2017-04-25 Thread Vincenzo Gianferrari Pini
+1

Great job,
Vincenzo

Il Ven 21 Apr 2017, 13:07 Tellier Benoit  ha scritto:

> Hello,
>
> After a one week feedback period, as discussed in a previous email, I
> would like to trigger a one week voting period for release of the new
> version of the website.
>
> The changes includes:
>
>  - A new responsive, modern and appealing homepage for the James project
>  - We keep the main website the same but:
>- We improve side menu navigation with a single side menu, all across
> the website
>- Make top menu consistent
>- We revisited some critical pages, and tried to make it more consistent
>- Remove most stable
>- We re-wrote pages about performance, migration support, etc...
>- Landing page of old website have been made more user friendly.
>  - News have been moved to homepage
>
> The improvement of the website is an important milestone towards James
> 3.0 release.
>
> You can view the result online: http://62.210.100.33
>
> React with +1 if you support this claim.
>
> React with -1 if you reject it.
>
> This is a Majority Approval Vote. PMC members are invited to participate
> to it.
>
> We will conclude it on the 28th of April 2017, 1pm UTC.
>
> Cheers,
>
> Benoit Tellier
>
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by email to the address *amministrazi...@gocloud.it 
* and then immediately destroy this message and 
any attachments from your system, without copying or disclosing the 
contents to any other person. Thank you for your co-operation.


Re: Release james-server into 3.0.0-beta5

2016-11-03 Thread Vincenzo Gianferrari Pini
+1

Thanks,
Vincenzo

Il Gio 3 Nov 2016, 09:25 Manuel Carrasco Moñino  ha
scritto:

> +1
>
> Thanks
> - Manolo
>
> On Thu, Nov 3, 2016 at 9:00 AM, aduprat  wrote:
>
> > +1
> >
> > Antoine
> >
> >
> >
> > Hello every one,
> >>
> >> I'm very happy to announce the vote for the upcoming 3.0.0-beta5 version
> >> of our beloved james server.
> >>
> >> You can access sources on github
> >>
> >> https://github.com/apache/james-project/releases
> >>
> >> Nexus artifact to be released can be found here :
> >> https://repository.apache.org/#stagingRepositories
> >>
> >> It is number #1010
> >>
> >> Moreover I uploaded compiled zip, along with md5 and sha1 sums, all
> >> signed.
> >>
> >> http://www.apache.org/dist/james/server/james-server-app-3.
> >> 0.0-beta5-SNAPSHOT-app.zip
> >> http://www.apache.org/dist/james/server/james-server-app-3.
> >> 0.0-beta5-SNAPSHOT-app.zip.asc
> >> http://www.apache.org/dist/james/server/james-server-app-3.
> >> 0.0-beta5-SNAPSHOT-app.zip.md5
> >> http://www.apache.org/dist/james/server/james-server-app-3.
> >> 0.0-beta5-SNAPSHOT-app.zip.md5.asc
> >> http://www.apache.org/dist/james/server/james-server-app-3.
> >> 0.0-beta5-SNAPSHOT-app.zip.sha1
> >> http://www.apache.org/dist/james/server/james-server-app-3.
> >> 0.0-beta5-SNAPSHOT-app.zip.sha1.asc
> >>
> >> According to Release policy, we need a majority vote :
> >>   - At least 3 PMC
> >>   - A majority of voters
> >>   - This release can't be vetoed
> >>
> >> Follow http://www.apache.org/dev/release.html for more details.
> >>
> >> To vote, you can reply to this email with
> >>
> >> +1
> >>
> >>  If you accept the release
> >>
> >> -1
> >>
> >>  If you reject the release
> >>
> >> Votes will close on Saturday 5th November 2016, 2pm CET.
> >>
> >> Regards,
> >>
> >> Benoit Tellier
> >>
> >> Developer at Linagora
> >>
> >>
> >> -
> >> 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
> >
> >
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by email to the address *amministrazi...@gocloud.it 
* and then immediately destroy this message and 
any attachments from your system, without copying or disclosing the 
contents to any other person. Thank you for your co-operation.


Re: Fwd: Release org.apache.james:apache-mime4j-project into 0.8.0

2016-10-14 Thread Vincenzo Gianferrari Pini
+1

Thanks,
Vincenzo

Il Sab 15 Ott 2016, 06:34 Manuel Carrasco Moñino  ha
scritto:

> +1
>
> Thanks
> - Manolo
>
> On Wed, Oct 12, 2016, 15:13 Matthieu Baechler  wrote:
>
> > +1
> >
> > --
> >
> > Matthieu Baechler
> >
> > On 10/12/2016 01:15 PM, Tellier Benoit wrote:
> > > Hello every one,
> > >
> > > As you may know, we want to release James 3.0.0-beta5. This release
> > > demands us to remove every SNAPSHOT dependency, including the one to
> > MIME4J.
> > >
> > > You can access sources on github.
> > >
> > > Nexus artifact to be released can be found here :
> > > https://repository.apache.org/#stagingRepositories
> > >
> > > It is number #1008
> > >
> > > According to Release policy, we need a majority vote :
> > >   - At least 3 PMC
> > >   - A majority of voters
> > >   - This release can't be vetoed
> > >
> > > Follow http://www.apache.org/dev/release.html for more details.
> > >
> > > To vote, you can reply to this email with
> > >
> > > +1
> > >
> > >  If you accept the release
> > >
> > > -1
> > >
> > >  If you reject the release
> > >
> > > Votes will close on Saturtay 15th October 2016, 2pm CEST.
> > >
> > > Regards,
> > >
> > > Benoit Tellier
> > >
> > > Developer at Linagora
> > >
> > >
> > > -
> > > 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
> >
> >
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by email to the address *amministrazi...@gocloud.it 
* and then immediately destroy this message and 
any attachments from your system, without copying or disclosing the 
contents to any other person. Thank you for your co-operation.


Re: James logo – the Vote is Open

2016-09-26 Thread Vincenzo Gianferrari Pini
VOTE FOR LOGO NUMBER: 10

Thanks,
Vincenzo

Il Lun 26 Set 2016, 17:33 Matthieu Baechler  ha
scritto:

> Hi there,
>
> Thank you Laura for this call for vote.
>
> Here is my vote :
>
> * VOTE FOR LOGO NUMBER: 10
>
> Cheers,
>
> --
> Matthieu Baechler
>
> Le 26/09/2016 à 16:04, Laura Royet a écrit :
> > Hi everyone,
> >
> > This emails opens the *single vote ballot* for *James log**o*.
> > Below are the detailed explanation.
> >
> > **Who ca**n vote :* all the recipients of this email.
> > Deadline :Monday, 3 October 2016 at 18:00 UTC*.
> >
> > *How to vo**te :
> > **You have two options : **choosing**one of the **proposals between
> > the 10 submitted *on : http://james.apache.org/#tabs-4 or *give a
> > blank vote*.
> >
> > *So please complete the appropriate field below **:*
> > * VOTE FOR LOGO NUMBER:
> > * AGAINST PROPOSED LOGOS, WAIT MORE TIME FOR NEW CHOICES :
> >
> >
> >
> > The proposal collecting the most votes will become James new logo!
> >
> > Thank you in advance for participating.
> >
> > Regards,
> >
> > Laura
> >
> >
>
>
> -----
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
> --


___
*Ing. Vincenzo Gianferrari Pini*
Chairman & CTO - GoCloud
Sede legale: Via Larga 15, 20122 Milano (MI)
Sede op. ed amm.: Via Copernico, 38 - 20125 Milano (MI)
Cel. +39-3939837493
tel: +39-02-87250672 (dir.)
tel: +39-02-25514300 (cent.)
fax: +39-02-25514302

https://google.com/+VincenzoGianferrariPiniGoCloud
https://www.linkedin.com/in/vgianferrari
http://www.gocloud.eu
​http://www.mapadore.com​
<https://mail.google.com/mail/u/0/%E2%80%8Bhttp://www.mapadore.com%E2%80%8B>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by email to the address *amministrazi...@gocloud.it 
* and then immediately destroy this message and 
any attachments from your system, without copying or disclosing the 
contents to any other person. Thank you for your co-operation.


Re: [VOTE] Release Apache James Server 2.3.2.1

2015-08-30 Thread Vincenzo Gianferrari Pini
[X] +1 Please release

Thanks to everybody for addressing this problem.

Vincenzo

Il giorno Lun 31 Ago 2015 06:01 Felix Knecht  ha scritto:

> [X] +1 Please release
>
>
> Am 29.08.2015 um 09:38 schrieb Eric Charles:
> > Hi there,
> >
> > We have a security fix implemented in JAMES-1602 thanks to Steve Brewin.
> >
> > I have uploaded a signed version of the artifacts on
> > http://people.apache.org/~eric/james-2.3.2.1/
> >
> > Please review and cast your VOTE:
> >
> > [ ] +1 Please release
> > [ ] +0 No time to review
> > [ ] -1 Something is wrong
> >
> > Thx, Eric
> >
> > -
> > 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
>
> --
*Ing. Vincenzo Gianferrari Pini*
Chairman & CTO - GoCloud
Sede legale: Via Larga 15, 20122 Milano (MI)
Sede op. ed amm.: Via Stefanardo da Vimercate 28, 20128 Milano (MI)
Cel. +39-3939837493
tel: +39-02-87250672 (dir.)
tel: +39-02-25514300 (cent.)
fax: +39-02-25514302

https://google.com/+VincenzoGianferrariPiniGoCloud
https://www.linkedin.com/in/vgianferrari
http://www.gocloud.eu
​http://www.mapadore.com​
<https://mail.google.com/mail/u/0/%E2%80%8Bhttp://www.mapadore.com%E2%80%8B>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by email to the address *amministrazi...@gocloud.it 
* and then immediately destroy this message and 
any attachments from your system, without copying or disclosing the 
contents to any other person. Thank you for your co-operation.


Re: Proposal about James modules merge

2015-08-28 Thread Vincenzo Gianferrari Pini
Hi all,

sorry for not having been active at all in the last period.

Anyway, I agree with Ioan that using GIT is *much* more productive than
using SVN, so I cast here my +1.

Regards,
Vincenzo

Il giorno lun 24 ago 2015 alle ore 21:51 Ioan Eugen Stan <
stan.ieu...@gmail.com> ha scritto:

> Hi,
>
> Yes, the work flow is not the best with SVN. There is an option to
> migrate James to git hosting and personally I think it will be a good
> thing.
>
> In order to make this a reality we have to raise a vote and raise a JIRA
> issue to Apache Infra. The vote has to run for 72h.
>
> You have my +1.
>
> p.s. One thing to have in mind is that we need to we need to take care
> of the site publishing also. But it's doable.
>
> Regards,
>
> --
*Ing. Vincenzo Gianferrari Pini*
Chairman & CTO - GoCloud
Sede legale: Via Larga 15, 20122 Milano (MI)
Sede op. ed amm.: Via Stefanardo da Vimercate 28, 20128 Milano (MI)
Cel. +39-3939837493
tel: +39-02-87250672 (dir.)
tel: +39-02-25514300 (cent.)
fax: +39-02-25514302

https://google.com/+VincenzoGianferrariPiniGoCloud
https://www.linkedin.com/in/vgianferrari
http://www.gocloud.eu
​http://www.mapadore.com​
<https://mail.google.com/mail/u/0/%E2%80%8Bhttp://www.mapadore.com%E2%80%8B>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
all'indirizzo email *amministrazi...@gocloud.it 
* e di procedere immediatamente alla 
distruzione dello stesso e dei suoi allegati, da effettuarsi senza copiarne 
o rivelarne ad alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by email to the address *amministrazi...@gocloud.it 
* and then immediately destroy this message and 
any attachments from your system, without copying or disclosing the 
contents to any other person. Thank you for your co-operation.


Re: [VOTE] Release Apache James Project 1.8.2

2013-02-06 Thread Vincenzo Gianferrari Pini
[X] +1 Please release

Ciao,
Vincenzo

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
al n° +390236680761 e di procedere immediatamente alla distruzione dello 
stesso e dei suoi allegati, da effettuarsi senza copiarne o rivelarne ad 
alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by phone at +390236680761 and then immediately destroy this 
message and any attachments from your system, without copying or disclosing 
the contents to any other person. Thank you for your co-operation.


Re: [VOTE] Release Apache James App 3.0-beta4 (3rd try)

2012-03-26 Thread Vincenzo Gianferrari Pini
[X] +1 Please release

Vincenzo

2012/3/22 Eric Charles 

> (resending, the mail didn't appear in the mailing lists)
>
> Hi Jamers,
>
> Please review and cast your VOTE for James server application 3.0-beta4
> release. NOTICE and template configuration files have been fixed further to
> your last reviews.
>
> [ ] +1 Please release
> [ ] +0 No time to review
> [ ] -1 Something is wrong
>
> Release Notes:
> https://issues.apache.org/**jira/secure/ReleaseNote.jspa?**
> projectId=12311920&version=**12320240
>
> SVN tags:
> https://svn.apache.org/repos/**asf/james/app/tags/apache-**
> james-3.0-beta4/
>
> Source tarballs:
> https://repository.apache.org/**content/repositories/**
> orgapachejames-097/org/apache/**james/apache-james/3.0-beta4/**
> apache-james-3.0-beta4-app.zip
>
> Staging repositories:
> https://repository.apache.org/**content/repositories/**orgapachejames-097/
>
> Thx.
> --
> eric | http://about.echarles.net | @echarles
>
> --**--**-
> To unsubscribe, e-mail: 
> server-dev-unsubscribe@james.**apache.org
> For additional commands, e-mail: 
> server-dev-help@james.apache.**org
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
al n° +390236680761 e di procedere immediatamente alla distruzione dello 
stesso e dei suoi allegati, da effettuarsi senza copiarne o rivelarne ad 
alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by phone at +390236680761 and then immediately destroy this 
message and any attachments from your system, without copying or disclosing 
the contents to any other person. Thank you for your co-operation.


Re: [VOTE] Release Apache James Server and App 3.0-beta4

2012-03-07 Thread Vincenzo Gianferrari Pini
[X] +0 No time to review

Sorry guys, but currently I'm unable to follow it. I hope in the future to
be more helpful.

Ciao,
Vincenzo

2012/3/2 Eric Charles 

> Hi there,
>
> We are ready to vote for James server application 3.0-beta4 based on the
> latest and greatest Protocols 1.6.2, Mailbox 0.3, IMAP 0.4 and jSieve 0.5.
>
> This vote is a conjoint vote to release server and app 3.0-beta4 projects.
>
> So please cast your VOTE for Apache James Server 3.0b4 release:
>
> [ ] +1 Please release
> [ ] +0 No time to review
> [ ] -1 Something is wrong
>
> Release Notes:
> https://issues.apache.org/**jira/secure/ReleaseNote.jspa?**
> projectId=10411&version=**12317240
>
> SVN tags:
> https://svn.apache.org/repos/**asf/james/app/tags/apache-**
> james-3.0-beta4/
> https://svn.apache.org/repos/**asf/james/server/tags/james-**
> server-3.0-beta4/
>
> Source tarballs:
> https://repository.apache.org/**content/repositories/**
> orgapachejames-043/org/apache/**james/apache-james/3.0-beta4/**
> apache-james-3.0-beta4-app.zip
> https://repository.apache.org/**content/repositories/**
> orgapachejames-042/org/apache/**james/james-server/3.0-beta4/**
> james-server-3.0-beta4-source-**release.zip
>
> Staging repositories:
> https://repository.apache.org/**content/repositories/**orgapachejames-043/
> https://repository.apache.org/**content/repositories/**orgapachejames-042/
>
> Thx.
> --
> eric | http://about.echarles.net | @echarles
>
> --**--**-
> To unsubscribe, e-mail: 
> server-dev-unsubscribe@james.**apache.org
> For additional commands, e-mail: 
> server-dev-help@james.apache.**org
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
al n° +390236680761 e di procedere immediatamente alla distruzione dello 
stesso e dei suoi allegati, da effettuarsi senza copiarne o rivelarne ad 
alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by phone at +390236680761 and then immediately destroy this 
message and any attachments from your system, without copying or disclosing 
the contents to any other person. Thank you for your co-operation.


Re: [VOTE] Release Apache James Protocols 1.6.1

2012-01-20 Thread Vincenzo Gianferrari Pini
[X] +0 No time to review

Vincenzo

2012/1/19 Norman Maurer 

> Hi there,
>
> after a defect in starttls was found in Apache James Protocols 1.6.0
> its time to release a bugfix release for it asap.
>
> So please cast your vote...
>
> Artifacts to review:
> https://repository.apache.org/content/repositories/orgapachejames-100/
>
> [ ] +1 Yes, go ahead
> [ ] +0 No time to review
> [ ] -1 Something wrong
>
> Thanks,
> Norman
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>

-- 
Il presente messaggio ed i suoi allegati sono confidenziali in ragione 
della loro natura professionale e, in ogni caso, non accessibili al 
pubblico. Nel caso in cui il presente messaggio sia ricevuto da soggetto 
diverso dal suo diretto destinatario, si prega di darne immediata notizia 
al n° +390236680761 e di procedere immediatamente alla distruzione dello 
stesso e dei suoi allegati, da effettuarsi senza copiarne o rivelarne ad 
alcuno il contenuto. Grazie per la collaborazione.

This e-mail and any  attachments thereto are confidential and may be 
covered by legal professional privilege or otherwise protected from 
disclosure. If you are not the intended recipient, please notify us 
immediately by phone at +390236680761 and then immediately destroy this 
message and any attachments from your system, without copying or disclosing 
the contents to any other person. Thank you for your co-operation.


Re: [VOTE] Release Apache James Mime4j 0.7.2

2012-01-11 Thread Vincenzo Gianferrari Pini
[ x] +0 No time to review

Vincenzo

2012/1/8 Norman Maurer 

> Hi there,
>
> its time again for a new release of Apache James Mime4j 0.7.2.
>
> Changelog:
>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+MIME4J+AND+fixVersion+%3D+%220.7.2%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESC&mode=hide
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachejames-030/
>
> [ ] +1 Yes please release
> [ ] +0 No time to review
> [ ] -1 Something wrong with the release
>
> Thanks,
> Norman
>


Re: [VOTE] Release Apache James Skin 1.7

2011-10-19 Thread Vincenzo Gianferrari Pini
[X] +1 Please release

I'm too busy around to review, but I agree with Stefano.

Vincenzo

2011/10/18 Stefano Bagnara 

> 2011/10/18 Felix Knecht :
> > Hi
> >
> > A list of changes/fixes:
> > - Logos for James modules added (when existing)
> > - Fancybox utility for image zooms under MIT licence added
> > - Access javascript arrays via array.item(nr) instead of array[nr]
> because
> > the cgi script doesn't likes words in square brackets (JAMES-1260)
> > - Implement Apache Branding Requirements 3. Website Navigation Links:
> navbar
> > links included, link to www.apache.org included -> need to update the
> left
> > menu, putting the link to www.apache.org in bold (JAMES-1289)
> > - Fix maven skin "download" tracking in order to support asynchronous
> google
> > analytics code (the #googleAnalytics tag now includes the new code so
> that
> > "urchinTrack" is not available anymore.
> > - Rename artifact from maven-skin to james-skin (keep existing version)
> > JAMES-1334)
> > - Replace parent pom reference (JAMES-1334)
> > - Cleanup pom and add needed definitions (JAMES-1334)
> > - It's no longer a Maven2 but Maven3 skin (JAMES-1334)
> >
> > Please cast you vote for release Apache James Skin 1.7.
> >
> > Release for review:
> > https://repository.apache.org/content/repositories/orgapachejames-073/
>
> [X] +1 Please release
>
> Thank you for taking care of this!
> I didn't review in depth, but this is not for public availability and
> just a building block for our other artifacts, so if we find issues
> when releasing we can fix them and release 1.8.
>
> Stefano
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


R: [VOTE] Release Apache James 3.0-beta3

2011-08-16 Thread Vincenzo Gianferrari Pini
[X] +1 Release Apache James 3.0-beta3

Great job Robert!

Vincenzo
Inviato dal dispositivo wireless BlackBerry®

-Original Message-
From: Robert Burrell Donkin 
Date: Mon, 15 Aug 2011 11:33:32 
To: James Developers List
Reply-To: "James Developers List" 
Subject: [VOTE] Release Apache James 3.0-beta3

It's been a long (apologies) and rocky (dev box MIA) road but I hope
we're finally ready.

(The war release process provided unreliable. I hope to have this
fixed for the next release.)

Please review 
https://repository.apache.org/content/repositories/orgapachejames-037/
and cast your votes.

Anyone and everyone are encouraged to vote. James PMC votes are
binding on Apache.

I'll tally the results no earlier than Wednesday, August 17 at 1200 UTC [1]

Again, apologies for not making this happen much earlier :-/

Robert

[1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20110817T12

--8<-
[ ] +1 Release Apache James 3.0-beta3
[ ] +0 Tending towards acceptance (without time for full review)
[ ] -0 Tending towards rejection
[ ] -1 Do not release Apache James 3.0-beta3 (with reasons, please)
--

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



Re: [VOTE] Release Apache James IMAP 0.2.1

2011-06-12 Thread Vincenzo Gianferrari Pini
[x] +1 Go ahead

Vincenzo

2011/6/12 Eric Charles 

> [x] +1 Go ahead
> - Eric
>
>
> On 09/06/11 18:44, Norman Maurer wrote:
>
>> Hi there,
>>
>> its time again for the next IMAP release before we move forward and
>> need the new mailbox api changes.
>>
>> This release does not need any api changes from the 0.2 release.
>>
>> Changes:
>>
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+IMAP+AND+fixVersion+%3D+%220.3%22+AND+resolution+in+%28Fixed%2C+%22Won%27t+Fix%22%2C+Duplicate%2C+Invalid%2C+Incomplete%2C+%22Cannot+Reproduce%22%2C+Later%2C+%22Not+A+Problem%22%29
>>
>> Please review and cast your vote:
>> https://repository.apache.org/content/repositories/orgapachejames-062/
>>
>> [ ] +1 Go ahead
>> [ ] +0 No time to review
>> [ ] -1 Something wrong with it
>>
>> -
>> 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: [VOTE] Release Apache James IMAP 0.2

2011-05-23 Thread Vincenzo Gianferrari Pini
[X] +1 Yes please release

Vincenzo

2011/5/21 Norman Maurer 

> Hi there,
>
> here is the VOTE for version 0.2 of Apache James IMAP. This will be
> used for the upcomming beta release of Apache James Server.
>
> So please review and cast our vote:
> https://repository.apache.org/content/repositories/orgapachejames-042/
>
> [ ] +1 Yes please release
> [ ] +0 No time to review
> [ ] -1 Something wrong with it
>
> Bye,
> Norman
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Release protocols 1.4 and mailets-standard 1.1

2011-05-12 Thread Vincenzo Gianferrari Pini
[X] + 0 No time to review

Sorry, I'm not able now to examine the whole thing ...

If my vote becomes crucial, let me know.

Ciao,
Vincenzo


2011/5/10 Norman Maurer 

> Hi there,
>
> this is the VOTE for release protocols 1.4 and mailets-standard 1.1.
> Both releases are needed for james-server 3.0-M3.
>
> So please cast your VOTE.
>
> protocols 1.4:
>
> Review url:
> https://repository.apache.org/content/repositories/orgapachejames-003
>
> [ ] +1 Yeah, go ahead
> [ ] + 0 No time to review
> [ ] -1 There is a bug we need to fix first
>
>
>
> standard-mailets 1.1:
>
> Review url:
> https://repository.apache.org/content/repositories/orgapachejames-002
>
> [ ] +1 Yeah, go ahead
> [ ] + 0 No time to review
> [ ] -1 There is a bug we need to fix first
>
> Thanks,
> Norman
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Move to java6 for james-server, imap, mailbox

2011-04-25 Thread Vincenzo Gianferrari Pini
[X] +1 Yes please go ahead

Ciao,
Vincenzo


2011/4/23 Norman Maurer 

> Hi there,
>
> this is a VOTE to move the minimum java version to java6 for
> james-server, imap, mailbox.
>
> So please VOTE...
>
> [ ] +1 Yes please go ahead
> [ ] +0 No real preference
> [ ] - 1 No... We need to at least support java 5
>
> Bye,
> Norman
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Release protocols 1.3

2010-12-28 Thread Vincenzo Gianferrari Pini
[X] +1 Yes please release

Ciao,
Vincenzo


Re: [VOTE] Release Mime4J 0.6.1

2010-12-28 Thread Vincenzo Gianferrari Pini
[X] +1 Yes please release

Ciao,
Vincenzo


Re: [VOTE] Release protocols 1.2

2010-11-28 Thread Vincenzo Gianferrari Pini
[X] +1 Yes, please release

Ciao,
Vincenzo

2010/11/27 Norman Maurer 

> Hi there,
>
> its time again to cut a release for protocols. This release will be
> included in the upcomming james server release. So please review and
> cut your VOTE:
>
> https://repository.apache.org/content/repositories/orgapachejames-024/
>
> [ ] +1 Yes, please release
> [ ] + 0 No time to review
> [ ] -1 No this release does not match the criteria for a release..
>
>
> Thx,
> Norman
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE AGAIN] James Server 3.0-M2

2010-11-11 Thread Vincenzo Gianferrari Pini
[X] +1 Yes please release

2010/11/10 Norman Maurer 

> Hi all,
>
> after fixing a major bug with leaking files on windows I want to start
> the VOTE for M2 again.
>
> Here are the artifacts for review:
> https://repository.apache.org/content/repositories/orgapachejames-056/
>
> So please cast your VOTE:
>
> [  ] +1 Yes please release
> [  ] +0 No time to review
> [  ] -1 No the code is not ready yet.
>
> Thx,
> Norman
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Release JAMES Server 3.0-M2

2010-11-07 Thread Vincenzo Gianferrari Pini
[X] +1 Yes please release

Ciao,
Vincenzo

2010/11/6 Norman Maurer 

> Hi all,
>
> its time to start a VOTE for the second milestone of the
> upcomming major version of JAMES Server (3.0). I know its not long
> since the last milestone
> but we fixed a bunch of bugs, and you know.. Release often;Release early ;)
>
> Here are the artifacts for review:
> https://repository.apache.org/content/repositories/orgapachejames-043/
>
> So please cast your VOTE:
>
> [  ] +1 Yes please release
> [  ] +0 No time to review
> [  ] -1 No the code is not ready yet.
>
> Thx,
> Norman
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Release IMAP 0.2-M1

2010-10-17 Thread Vincenzo Gianferrari Pini
[X] +1 Looks good, please release

Ciao,
Vincenzo

Il giorno 15 ottobre 2010 21.22.44 UTC+2, Norman Maurer
ha scritto:

>  Hi there,
>
> we are currently doing the last steps to get ready for cut the first
> milestone of JAMES server. For doing so we need a new release of IMAP.
> I think after fixin the a few bugs today, so I prepared one and staged
> it fro review..
>
> So here we go, please review and cast your VOTE:
>
> https://repository.apache.org/content/repositories/orgapachejames-002/
>
> [ ] +1 Looks good, please release
> [ ] +0 No time to review
> [ ] -1 No release pelase
>
> Thx,
> Norman
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


R: [VOTE] Release of protocols-1.2-M1

2010-10-15 Thread Vincenzo Gianferrari Pini (GoCloud)
[X] +1 Looks good, please release

Ciao,
Vincenzo
--Messaggio originale--
Da: Norman
A:James Developers List
Rispondi a:James Developers List
Oggetto: [VOTE] Release of protocols-1.2-M1
Inviato: 15 Ott 2010 07:16

  Hi there,

we are currently doing the last steps to get ready for cut the first 
milestone of JAMES server. For doing so we need a new release of 
protocols. So I prepared one and staged it fro review..

So here we go, please review and cast your VOTE:

https://repository.apache.org/content/repositories/orgapachejames-001/

[ ] +1 Looks good, please release
[ ] +0 No time to review
[ ] -1 No release pelase

Thx,
Norman


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



Inviato dal dispositivo wireless BlackBerry®

Re: [VOTE] Release protocols 1.1

2010-07-11 Thread Vincenzo Gianferrari Pini
[X] +1 Please release the artifacts

Vincenzo

P.S. Thanks for your continuous commitment.


2010/7/4 Norman Maurer 

> Hi all,
>
> to be able to release James Server 3.0-M1 we need to cut a release of
> the protocols subproject, to remove SNAPSHOT dependencies. The protocols
> release
> contains some critical bugfixes for smtp-auth and for correctly shut
> down the server implementation
>
>
> So please review and cast your vote:
>
> https://repository.apache.org/content/repositories/orgapachejames-033/
>
> [ ] +1 Please release the artifacts
> [ ] +0 No time for review
> [ ] -1 Something is wrong or we are not ready for a milestone yet.
>
>
> Bye,
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Release apache-mailet-base 1.1

2010-05-19 Thread Vincenzo Gianferrari Pini
[X] +0 No time for review

Vincenzo


Re: [VOTE] Release mailet-standard 1.0 (AGAIN)

2010-05-09 Thread Vincenzo Gianferrari Pini
>
> [X] +1 Please release the artifacts
>
> Vincenzo
>


Re: [VOTE] Release jsieve 0.4 (AGAIN)

2010-05-09 Thread Vincenzo Gianferrari Pini
[X] +1 Please release the artifacts

Vincenzo


Re: [VOTE] Release apache-mailet 2.5

2010-05-03 Thread Vincenzo Gianferrari Pini
[X] +0 No time for review

Sorry for not being helpful.

Ciao,
Vincenzo


Re: [IMAP] [VOTE] James IMAP 0.1-M1 Release

2010-02-15 Thread Vincenzo Gianferrari Pini
Great!

I'm unable to review, so

[X] +0 No time for review

But otherwise I would +1, as it's a long awaited thing!

Vincenzo

On Thu, Feb 11, 2010 at 8:57 PM, Norman Maurer  wrote:

> Hi all,
>
> I think its time to cut the first milestone of IMAP.
>
> This Milestone will prolly be used for the first milestone of JAMES
> Server a.k.a 3.0-M1.
>
> So please review and cast your vote:
>
> https://repository.apache.org/content/repositories/orgapachejames-016/
>
> [ ] +1 Please release the artifacts
> [ ] +0 No time for review
> [ ] -1 Something is wrong or we are not ready for a milestone yet.
>
>
> Bye,
> Norman
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Release James-Project 1.5

2010-01-12 Thread Vincenzo Gianferrari Pini
>
> [+0] No time to review
>
>


Re: [VOTE] Pure Spring deployment ready to merge

2010-01-04 Thread Vincenzo Gianferrari Pini
Great Norman!


> [X] +0 I trust you enough but had not the energie to review the changes
>
>
Sorry, but I won't be able to test it. But it would be a very important
thing to give back fuel to James.

Ciao,
Vincenzo


Re: [VOTE] Add Hupa as subproject to JAMES

2009-09-19 Thread Vincenzo Gianferrari Pini
On Fri, Sep 18, 2009 at 9:58 AM, Norman Maurer  wrote:

> Hi all,
>
> just for to be safe I would start a VOTE about adding Hupa[1] as
> subproject to JAMES. So here we go..
>
> [X] +1 Yeah I would like to Hupa included it
>

Vincenzo


>
> Thx,
> Norman
>
> [1] http://svn.apache.org/repos/asf/labs/hupa
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Release James 2.3.2

2009-08-16 Thread Vincenzo Gianferrari Pini
On Mon, Aug 10, 2009 at 11:04 PM, Robert Burrell Donkin <
robertburrelldon...@gmail.com> wrote:

> i've uploaded an FC to http://people.apache.org/~rdonkin/james/
>
> please review, test and then vote. all are encouraged to express their
> opinions but only PMC votes are binding on apache.
>
> note that i am transitioning my old DSA key to a longer RSA key(see
>
> http://www.jroller.com/robertburrelldonkin/entry/release_distribution_renewing_the_web
> ).
> http://people.apache.org/~rdonkin/TRANSITION.asc is my transition
> statement. this release is signed with the new key.
>
> - robert
>
> [X] +1 Release this candidate as Apache James 2.3.2
>
> 
>
>


Re: 2.3.2 Release ...?

2009-06-15 Thread Vincenzo Gianferrari Pini
I agree with Steve.
Vincenzo

On Sat, Jun 13, 2009 at 8:22 PM, Steve Brewin  wrote:

> Robert Burrell Donkin [mailto:robertburrelldon...@gmail.com] wrote on: 12
> June 2009 14:06
> > On Fri, Jun 12, 2009 at 12:45 PM, Stefano
> > Bagnara wrote:
> > > Robert Burrell Donkin ha scritto:
> > >> i'd like to try to release the long delayed 2.3.2
> > >>
> > >> anyone else like to see a 2.3.2 release?
> > >>
> > >> there's only one remaining issue: unless anyone wants to commit
> > >> https://issues.apache.org/jira/browse/JAMES-875 (i'm agnostic) , i
> > >> propose to push to 2.4
> > >
> > > If JAMES-875 lands 2.3.2 I'll use it in a couple of
> > production server
> > > where I'm currently using a v2.3 branch build + JAMES-875.
> > While I agree
> > > it may cause backward incompatibility IMO it is a long
> > standing critical
> > > bug and should be included, but I don't care enough to push this.
> >
> > i'm agnostic but the consensus seems to be shipping with JAMES-875 in
> >
> > any objections?
> >
> > - robert
>
> Not from me. Behaving correctly seems eminently reasonable.
>
> Cheers
> --Steve
>
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Apache JSieve 0.3

2009-06-14 Thread Vincenzo Gianferrari Pini
I didn't get too much acquainted with JSieve, unfortunately.
[ ] +1 Release Apache JSieve 0.3
[X] +0
[ ] -0
[ ] -1 Do not release Apache JSieve 0.3

Cheers,
Vincenzo

On Wed, Jun 10, 2009 at 10:53 AM, Robert Burrell Donkin <
robertburrelldon...@gmail.com> wrote:

> i think we're still need another vote for this to pass
>
> if anyone can find the time to take a look sometime soon that'd be great
> :-)
>
> - robert
>
> On Tue, May 12, 2009 at 9:58 PM, Robert Burrell
> Donkin wrote:
> > i've uploaded an FC to http://people.apache.org/~rdonkin/apache-jsieve/
> >
> > - robert
> >
> >
> ---8<---
> > [ ] +1 Release Apache JSieve 0.3
> > [ ] +0
> > [ ] -0
> > [ ] -1 Do not release Apache JSieve 0.3
> >
> -
> >
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Release Apache Mailet Base 1.0

2009-03-22 Thread Vincenzo Gianferrari Pini
[x] +1Release apache-mailet-base 1.0

Bye,
Vincenzo

On Thu, Mar 19, 2009 at 9:24 PM, Robert Burrell Donkin <
robertburrelldon...@gmail.com> wrote:

> after three release candidates, i think it's time to call the work.
> the release can be found at
> http://people.apache.org/~rdonkin/apache-mailet-base/
>
> here's my +1
>
> - robert
>
> --8<---
> [ ] +1Release apache-mailet-base 1.0
> [ ] +0
> [ ] -0
> [ ] -1 Do not release apache-mailet-base 1.0
>
> -
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Create mime4j-dev mailing list

2009-01-16 Thread Vincenzo Gianferrari Pini
X] +/-0, I don't care
Same as Stefano :)

Ciao,
Vincenzo


On Mon, Jan 12, 2009 at 5:38 PM, Stefano Bagnara  wrote:

> Bernd Fondermann ha scritto:
> > Hi,
> >
> > Development of mime4j has considerably gained speed, with added
> > committers and successful releases.
> >
> > Mime4j discussions comprise a large part of the mail on server-dev.
> >
> > Mime4j is independent of our server product and used outside of JAMES.
> >
> > While we do not know whether or not mime4j will really become a project
> > of its own, it seems due time to give it more space to expand on a
> > seperate mailing list to foster this ongoing process.
> >
> > So I propose to establish the mailing list
> >
> > mime4j-...@james.apache.org
> >
> > for all mime4j product related discussion.
>
> [X] +/-0, I don't care
>
> In fact "I do care", but I'm fine with what active people need.
>
> Will svn notifications for the mime4j tree be moved there, too?
>
> Stefano
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>


Re: [VOTE] Release Mailet API 2.4

2008-12-28 Thread Vincenzo Gianferrari Pini
>
>
> [X] +1 Release Mailet API 2.4


Vincenzo


Re: [VOTE] James Mime4j 0.4 release (take 2)

2008-08-19 Thread Vincenzo Gianferrari Pini
+1

Vincenzo


Re: [VOTE] Introduce mailet-base product

2008-04-27 Thread Vincenzo Gianferrari Pini
>
>
> [x] +1 Create mailet-base


Vincenzo


Re: [VOTE] jSPF-0.9.6 (seconds try....)

2008-04-05 Thread Vincenzo Gianferrari Pini
 [x] +0 Cool to see the release

Vincenzo


Re: [VOTE] jSPF-0.9.6

2008-03-25 Thread Vincenzo Gianferrari Pini
+0

BTW, below it looks like the vote has already been closed on Sunday 23 ...
;-)

Vincenzo

On Tue, Mar 25, 2008 at 11:17 AM, Norman Maurer <[EMAIL PROTECTED]> wrote:

> Hi dev-team,
>
> I finally found the time to prepare for next jSPF
> release...
>
> Fixed bugs and improvements can be found at:
>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310350&fixfor=12312813
>
>
> Packages can be found at:
>
> http://people.apache.org/~norman/staging-repository/org/apache/james/apache-jspf/0.9.6/
>
> So please vote.. The VOTE will be closed on 23.03.08 11:00:00 CET 2008
>
> VOTE:
> [ ] +1 Yes plz make this release official!
> [ ] +0 Cool to see the release
> [ ] -0 Anyway I don't care to much..
> [ ] -1 No.. I don't want a new release for some reason!
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>


Re: [VOTE] Mailet First Steps

2008-03-21 Thread Vincenzo Gianferrari Pini
>
>
> [x] +1 Create product standard-mailets in mailet subproject
> [ ] +0
> [ ] -0
> [ ] -1 Do not create product standard-mailets in mailet subproject
>
> -
>
>
> --8<-
> [x] +1 Create product crypto-mailets in mailet subproject
> [ ] +0
> [ ] -0
> [ ] -1 Do not create product cyrpto-mailets in mailet subproject
>
> ---
>
> Vincenzo


Re: [VOTE] Mailets -> Mailet subproject

2008-03-03 Thread Vincenzo Gianferrari Pini
>
>
> [x] +1 Move Mailets to Mailet subproject
>
>
Vincenzo


Re: [VOTE] Jukka Zitting commit in trunk

2008-02-03 Thread Vincenzo Gianferrari Pini


[X] +1 I agree that Jukka should be allowed to commit anywhere in James codebase

Vincenzo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Move spring-deployment module to TRUNK

2007-10-08 Thread Vincenzo Gianferrari Pini
+1

Vincenzo

Bernd Fondermann wrote:
> Hi,
> 
> As proposed in a previous mail, we should make the spring-deployment
> part of trunk.
> As a consequence, we would be able to release a Spring-container-based
> Server runtime besides our regular Avalon-based.
> 
> Please cast your vote to execute
> svn cp
> https://svn.apache.org/repos/asf/james/server/sandbox/spring-integration/spring-deployment
> https://svn.apache.org/repos/asf/james/server/trunk
> 
> [] +1, let's include the spring-deployment code in trunk
> [] 0, I don't care
> [] -1, Veto! Don't include the spring-deployment code in trunk and in
> upcoming releases
> 
> This vote will run for an entire week for code review and will be
> tallied not before 2007-10-14 20:00 GMT
> 
> Thanks for voting,
> 
>   Bernd
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] next-major from trunk will be 3.0

2007-08-01 Thread Vincenzo Gianferrari Pini

+1

Vincenzo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [POLL] James 3.0 Milestone 1...?

2007-07-20 Thread Vincenzo Gianferrari Pini

[X] +1 Great!

Vincenzo

robert burrell donkin wrote:

the code in trunk has a ton of new features
(http://mail-archives.apache.org/mod_mbox/james-server-dev/200707.mbox/browser) 



i think that the upcoming spring integration might be a good excuse to
cut a milestone from trunk and christen it 3.0 milestone 1. yes,
there's work to be done (on the build, auditing the licenses, making
sure that everyone's happen with policy for milestones, cutting
releases for component sub-projects) but this is only a poll to see
whether people think it would be a good idea or not.

the milestone would be an official release but just a technology
preview with no guarantees about compatibility with the actual 3
series releases (whenever they happen).

- robert

[ ] +1 Great!
[ ] +0 Yeh, whatever
[ ] -0 Whatever
[ ] -1 Do I Look bovverd?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] Jar names should contain "apache" (was: Re: [mime4j] release plan for 0.3)

2007-05-14 Thread Vincenzo Gianferrari Pini

+1

Vincenzo

Danny Angus wrote:

On 5/14/07, Bernd Fondermann <[EMAIL PROTECTED]> wrote:

I'd prefer
Apache James Server, Apache mime4j, Apache jspf, as they constitute
products on their own.


+1.

d.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Jukka Zitting Committer Karma

2007-05-02 Thread Vincenzo Gianferrari Pini

+1

Vincenzo

Noel J. Bergman wrote:

Jukka Zitting, JackRabbit Committer & PMC Chair, has volunteered to help
work on a Proof of Concept related to the use of JCR as our unified data
store.  The proof of concept will start by focusing on the modelling of the
data in JCR, and will build from the JCR side out, not start with existing
JAMES code at all.

The work should be done in our SVN, hence the need for karma.

+1 from me.

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] JAMES 2.3.1 (final)

2007-04-25 Thread Vincenzo Gianferrari Pini

+1

Vincenzo

Norman Maurer wrote:

Hi all,

its me again :-P

If we want to get JAMES 2.3.1 out of the door before ApacheCon EU we
have to VOTE now. So here it is...

You can grab the builds from:
http://people.apache.org/~norman/james/downloads

Please test and review ;-)

This VOTE will be closed at 2007-04-29 12:00:00 GMT

bye
Norman

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] JAMES 2.3.1RC1

2007-04-15 Thread Vincenzo Gianferrari Pini

+1

Vincenzo

Norman Maurer wrote:

Hi guys,

after noone replied to my question about 2.3.1rc1 I dediced to moved
forward to start a vote (to much time allready lost). So please
download,test and vote ;-)

A list of changes can be found here:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10411&fixfor=12312150

You can grab it from:
http://people.apache.org/~norman/james/downloads


bye
Norman

Ps: I hope it was ok to just move forward

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: [VOTE] Using of 2.3 branch

2006-12-21 Thread Vincenzo Gianferrari Pini


Stefano Bagnara wrote:

Vincenzo Gianferrari Pini wrote:
You should do this in trunk. Trunk is where development is done. 
After you have done this in trunk we can discuss wether to backport 
it to some branch.
And I will do it that way. But then I need to immediately backport to 
2.3 (or 2.4), because I have to deliver it to a Client with my 
extension (I'm using this as an example, but is real :-)  ).


Well, I understand this, but we cannot change the whole James roadmap 
because of your needs, Noel's needs, my needs or anyone else here. If 
we do this for my needs then we should break any compatibility today 
and add DSN support (that I shipped 1 year ago to a client as a custom 
change and it would be really cool if it was part of james and I 
wouldn't need to merge the whole thing at every new release).
Mine was just an example of the need that many of us have of building 
quickly minor enhancements that can be useful to others, and avoiding to 
mantain custom builds. In parallel with the real major work to be done 
in trunk anyway.


I know that 2.2.0 had a lot of bugs but we never released a point 
release to fix bugs. We waited 2 years for 2.3.0 to be published: I 
know that many James developer was using custom builds because of this.


Now I would avoid a "war" to decide wether to publish 2 or 3 releases 
in the next 6 months, otherwise we'll end up with no release at all ;-)


I just asked forever to not use the "v2.3" folder of our repository 
for new features, and it seems I was not the only one asking for this. 
I believe, as I suggested in past, that an "svn cp v2.3 next-minor" 
would have solved a lot of problems.
Ok, I change my vote (always open to change my mind): Let's do "svn cp 
v2.3 next-minor" or "svn cp v2.3 2.4" as soon as possible.


What I expect from someone that actively want to work on the 
point/bugfix release or next-minor is to apply every common issue to 
the v2.3 branch (license headers, agreed critical bugfix backports) 
*then* branch next-minor.
Here is the point: I think we should not wait too much before branching. 
I would try to freeze quickly 2.3.1 and then branch next-minor/2.4.


For me it's all the same: the only difference is that if we have 2.3, 
2.4 and trunk we have to backport twice any fix. But let's then 
create a 2.4 branch.


And when we'll have branched next-major we'll have to do this 3 times :-(

Btw I think that it is better to have 3 developers that actively can 
work on each of the 3 branch than having 3 developers that do nothing 
because they discuss the whole day about what to do in the common 
branch, why and how...


This is why backporting can be done with a vote after a proposal 
including the list of intended backports is done. As I said I prefer 
RTC for the v2.3 branch, but I'm not against using CTR: I thought 
that people that loose time working on that code would be happy to 
know ASAP if I will vote -1 to a release including what they just 
backported. Of course a single -1 will not block the release, but a 
majority of -1 will do, so it is better to understand each others 
and define the roadmap.

What are RTC and CTR :-)  ?


Review-Then-Commit and Commit-Then-Review
http://www.apache.org/foundation/glossary.html
http://www.apache.org/foundation/voting.html

ASF seems to be more restrictive than us on the practice. Lazy 
consensus is allowed in CTR with this workflow:
"The patch below fixes bug #8271847; if no-one objects within three 
days, I'll assume lazy consensus and commit it."


So, for ASF, even CTR with Lazy Consensus would need a message to let 
others to know what is going to happen.


I believe that we don't need a so restrictive workflow, but I think 
that at least when there is no clear consensus it is better to use a 
vote to have it clear and avoid the work of reverting changes.


You know I've always said that I favor CTR because things can be 
backported if needed, but this should be done if the veto is not 
resolved. This is why I think we should either resolve the current 
veto on v2.3 or revert the commit if we want to "unlock" that branch, 
otherwise it will become a mess. This is something that should not 
happen at all in a maintenance branch.


Stefano



Vincenzo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: [VOTE] Using of 2.3 branch

2006-12-21 Thread Vincenzo Gianferrari Pini
You are right. Let's then create a 2.4 branch from 2.3, so some work can 
be done. In my case, being very busy, I unfortunately cannot work too 
much, but in the very short time I can work on two or three things that 
can make it for 2.4.


And obviously, as correctly said many times by Stefano, I would work on 
trunk and backport it, as for they very nature they are easy to 
backport. And there may be other "tactical" but useful things that can 
be done for 2.4.
The only really wrong thing would be adding fixes and new 
functionalities to  2.3 or 2.4 or next minor and not to trunk! This 
would look like an old story that we "old guys" remember.


Vincenzo


Joachim Draeger wrote:

Am Donnerstag, den 21.12.2006, 16:03 +0100 schrieb Vincenzo Gianferrari
Pini:

  

- New Features into Trunk
- Bugfixes into the Release Branch of 2.3
- ported Features of Trunk that should be incorporated into the 2.3 codebase
should be done into a new branch with the name 2.4

That way everything is clean, everyone looking at the repository gets an idea
of how the project is structured.
  
  


  
Agree, but at the same time having three branches is hard to mantain (we 
know that from the past history of James), so what I think is worth is 
to all of us be more *flexible and pragmatic*.



And we should be open for *compromises*. It just seems that James PMC
and community are unable to make widely accepted decisions at the moment
and it seems that this state will continue. 
Crucial votes, maybe even with vetos, will bring us nothing. Discussion

will just come up again and prevent us from moving forward.
Having three branches will be better than discussing for ever and just
doing nothing.
There is a group that doesn't want to work on next minor. Not because it
is not a desirable goal. They want to concentrate on new features in
trunk and bugfixes for 2.3. I think this won't change. 
Some think that we need a bugfix only branch of 2.3 to be able to

release it at any time. A backported feature probably needs more time to
test.
Even if it may be cumbersome and inconvenient: The three branches
strategy may be the only possible compromise to enable everyone to
work. 
Of course working on a common goal would be much better. But this way is

better than doing nothing.

I don't care whether 2.3 based release will use CTR or RTC. But I think
setting up a roadmap is needed to make the community to understand the
goal. It will also make it easier for people to get involved.

Joachim

P.S.: I announced a vote for today. Sorry, I don't think we are that far
right now.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: AW: [VOTE] Using of 2.3 branch

2006-12-21 Thread Vincenzo Gianferrari Pini


Jürgen Hoffmann wrote:

Hi Vincenzo,

see inline...

-Ursprüngliche Nachricht-
Von: Vincenzo Gianferrari Pini [mailto:[EMAIL PROTECTED] 
Gesendet: Donnerstag, 21. Dezember 2006 16:04

An: James Developers List
Betreff: Re: AW: [VOTE] Using of 2.3 branch


*We* comitters should be wise enough to judge and make the decision 
individually, and the commit can be withdrawed any time after a veto (or 
simply after a short discussion on the list). We should just be not 
touchy if it happens.


[JH>] Open Discussion about introducing features, whether minor or major, on
the mailinglist is fine. Although I think this should be done beforehand. This
removes the need for a separate "feature" Branch. This kind of discussion
should be held beforehand though.

I especially liked the "touchy" citation, since I used it in another context
some time ago ;)


Agree, but at the same time having three branches is hard to mantain (we 
know that from the past history of James), so what I think is worth is 
to all of us be more *flexible and pragmatic*.


For example, I have in mind (and have a personal need) to put inside the 
appropriate places of RemoteDelivery calls to two empty (just returning) 
protected methods called onSuccess and onError (or some similar name), 
to be able to build my own  personal extension "MyRemoteDelivery" 
(inside a jar in SAR-INF/lib) that would log into an application 
database the outcome of the delivery. I need and want to use 2.3.1 or 
2.4.n. The featrue is very "minor", in the sense that the code change is 
very simple and safe. But I have not yet done it because I don't know 
where to put it, so I may end up writing my own modified RemoteDelivery 
mailet instead of using the official one plus my extension.


[JH>] see above. I think it is necessary to discuss new features to be
introduced into a certain branch beforehand. One might miss a commit, because
he is on a convention for a week, and with the discussion beforehand, the
community already has come to a certain understanding and consent why this
feature should go into the branch.

And another thing about minor changes. A minor change is always capable to
break something somewhere else. No matter how big the change, things have to
be tested thoroughly. The fix for a mission critical Bug, should always be
released, even without further features within the branch. 


To grab your example. Think about the committer who has written the feature
you are talking about. He might miss to release the connection. No one notices
it. A Bug comes in, that needs to be fixed, is fixed and released. Another
user reads about the new feature within the bugfix release, thinks COOL I need
this. Bang memory leaking Mailserver.

See the point?
  
Just being specific on the example, the change to RemoteDelivery would 
be two calls to two new empty methods, while all the potentially 
"dangerous" code (handling jdbc connections etc.) would stay in another 
Mailet class that I would keep private and not commit in James. 
Otherwise I agree it would not be a "minor and safe" thing at all :-) .

Kind regards

Juergen


  

Ciao,

Vincenzo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: [VOTE] Using of 2.3 branch

2006-12-21 Thread Vincenzo Gianferrari Pini

Stefano Bagnara wrote:

Vincenzo Gianferrari Pini wrote:
Agree, but at the same time having three branches is hard to mantain 
(we know that from the past history of James), so what I think is 
worth is to all of us be more *flexible and pragmatic*.


Imho mantainability depends on how much people is committed to the 
process of a given release. If we had 100 committers I would have no 
problems in having 10 branches.

True.


Imho the problem in this thread is the mixed issue of the v2.3 branch 
and a release created starting from the v2.3 branch.

True.


If I understood Norman's intentions for calling this vote, it is not 
about next-minor, but simply about the use of the "v2.3" branch we 
have in the repository.


When I vote -1 to use "v2.3" for new features I mean that I don't want 
that branch to be used for features, but I'm not against the creation 
of a release based on the v2.3 branch. I simply think that this 
deserve a PROPOSAL (concrete, with issues to be backported list) and a 
custom branch. Maybe that we'll never use the v2.3 for another 
release, but I don't think why to reuse branch names on svn. It seems 
to me simply following good practice.


For example, I have in mind (and have a personal need) to put inside 
the appropriate places of RemoteDelivery calls to two empty (just 
returning) protected methods called onSuccess and onError (or some 
similar name), to be able to build my own  personal extension 
"MyRemoteDelivery" (inside a jar in SAR-INF/lib) that would log into 
an application database the outcome of the delivery. I need and want 
to use 2.3.1 or 2.4.n. The featrue is very "minor", in the sense that 
the code change is very simple and safe. But I have not yet done it 
because I don't know where to put it, so I may end up writing my own 
modified RemoteDelivery mailet instead of using the official one plus 
my extension.


You should do this in trunk. Trunk is where development is done. After 
you have done this in trunk we can discuss wether to backport it to 
some branch.
And I will do it that way. But then I need to immediately backport to 
2.3 (or 2.4), because I have to deliver it to a Client with my extension 
(I'm using this as an example, but is real :-)  ).


For me it's all the same: the only difference is that if we have 2.3, 
2.4 and trunk we have to backport twice any fix. But let's then create a 
2.4 branch.


FWIW, there is a missing functionality in SVN compared to SourceSafe: 
the *share/split* concept. It would allow a much easier common 
management of two very similar branches as 2.3 and 2.4 would be. When I 
talked about that to the SVN people in ApacheCon Europe, they simply 
didn't know it and then said that it's a matter of habit, but it's not 
true. Anyway this is not pertinent to James... :-)


This is why backporting can be done with a vote after a proposal 
including the list of intended backports is done. As I said I prefer 
RTC for the v2.3 branch, but I'm not against using CTR: I thought that 
people that loose time working on that code would be happy to know 
ASAP if I will vote -1 to a release including what they just 
backported. Of course a single -1 will not block the release, but a 
majority of -1 will do, so it is better to understand each others and 
define the roadmap.

What are RTC and CTR :-)  ?


My concern with backporting features is that a LOT of bugfixes (either 
minor or major) have been done in trunk, and I think that selectively 
backporting all the bugfixes is already a really big task wrt a point 
release. I wouldn't like to make a release with backport of minor new 
features but not backports for bugfixes we did.


Stefano




Vincenzo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: [VOTE] Using of 2.3 branch

2006-12-21 Thread Vincenzo Gianferrari Pini

Hi Jürgen, read inline...

Vincenzo

Jürgen Hoffmann wrote:

Hi Vincenzo,

reading your mail, I was wondering what the difference between a minor and a
major feature might be?
IMHO, in this context "minor" should mean simple and safe, or optional 
(like a new mailet for example, whose usage is not mandatory at all).

Who sets the bar, who makes the decision?
*We* comitters should be wise enough to judge and make the decision 
individually, and the commit can be withdrawed any time after a veto (or 
simply after a short discussion on the list). We should just be not 
touchy if it happens.

Who is
responsible to put the branch feature into trunk? IMHO it should be the other
way around. 


- New Features into Trunk
- Bugfixes into the Release Branch of 2.3
- ported Features of Trunk that should be incorporated into the 2.3 codebase
should be done into a new branch with the name 2.4

That way everything is clean, everyone looking at the repository gets an idea
of how the project is structured.
  
Agree, but at the same time having three branches is hard to mantain (we 
know that from the past history of James), so what I think is worth is 
to all of us be more *flexible and pragmatic*.


For example, I have in mind (and have a personal need) to put inside the 
appropriate places of RemoteDelivery calls to two empty (just returning) 
protected methods called onSuccess and onError (or some similar name), 
to be able to build my own  personal extension "MyRemoteDelivery" 
(inside a jar in SAR-INF/lib) that would log into an application 
database the outcome of the delivery. I need and want to use 2.3.1 or 
2.4.n. The featrue is very "minor", in the sense that the code change is 
very simple and safe. But I have not yet done it because I don't know 
where to put it, so I may end up writing my own modified RemoteDelivery 
mailet instead of using the official one plus my extension.



Question at hand is, how quick you want bugfixes to be released. If you
introduce features into the Release Branch, you maneuver yourself into a
one-way-street. You might introduce features that are not well-tested, and
that must be released with the critical bugfix that has to be fixed and
released.

I hope I was able to bring my point across...

Kind regards

Juergen

-Ursprüngliche Nachricht-
Von: Vincenzo Gianferrari Pini [mailto:[EMAIL PROTECTED] 
Gesendet: Donnerstag, 21. Dezember 2006 10:48

An: James Developers List
Betreff: Re: [VOTE] Using of 2.3 branch

Norman Maurer wrote:
  

Hi all,

i start this vote because i want to get an idea what other developers
think about this. Here are the possible solutions:

1) Commit fixes and new "minor" features to 2.3 branch:


  


+1.

My point is: we need fixes plus minor features applied to code branch 
that we can consider stable and safe, being used by most (I suppose) 
people (the ones that have started to use 2.3.0). So let's try to do it, 
with the goal of cutting a release quite soon, and limiting the new 
minor features that we can consider really "minor".
When we cut it we vote on changing the name to 2.4.0 if there are *not 
only* fixes (and I would vote +1 to such name change).
In other words, let's keep only one branch other than trunk and let's 
work on both. And the current 2.3 branch is already "next-minor" (we may 
already rename it for clarity).
The idea is that whatever goes into the 2.3/2.4/next-minor branch is 
aimed to maximum stability and compatibility, and if something is not so 
safe it *must* be optional and documented as such.


Moreover, I think that we are responsible enough to evaluate (the 
unfortunately few of us that will do them) if a minor feature is really 
low risk and could go into this branch, so I think that lazy consensus 
is much better than voting every time. And for such minor stuff a road 
map is bureaucracy. Next minor is


Finally, let's avoid religion wars around names :-) , and let's avoid 
becoming like the Italian Parliament these days  ;-) .
  

2) Commit only bugfixes to 2.3 branch:


  


-0
  

So please cast your votes and tell me what you prefer.

bye
Norman



  


Vincenzo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

!EXCUBATOR:1,458a588344674840514886!



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Using of 2.3 branch

2006-12-21 Thread Vincenzo Gianferrari Pini

Norman Maurer wrote:

Hi all,

i start this vote because i want to get an idea what other developers
think about this. Here are the possible solutions:

1) Commit fixes and new "minor" features to 2.3 branch:


  

+1.

My point is: we need fixes plus minor features applied to code branch 
that we can consider stable and safe, being used by most (I suppose) 
people (the ones that have started to use 2.3.0). So let's try to do it, 
with the goal of cutting a release quite soon, and limiting the new 
minor features that we can consider really "minor".
When we cut it we vote on changing the name to 2.4.0 if there are *not 
only* fixes (and I would vote +1 to such name change).
In other words, let's keep only one branch other than trunk and let's 
work on both. And the current 2.3 branch is already "next-minor" (we may 
already rename it for clarity).
The idea is that whatever goes into the 2.3/2.4/next-minor branch is 
aimed to maximum stability and compatibility, and if something is not so 
safe it *must* be optional and documented as such.


Moreover, I think that we are responsible enough to evaluate (the 
unfortunately few of us that will do them) if a minor feature is really 
low risk and could go into this branch, so I think that lazy consensus 
is much better than voting every time. And for such minor stuff a road 
map is bureaucracy. Next minor is


Finally, let's avoid religion wars around names :-) , and let's avoid 
becoming like the Italian Parliament these days  ;-) .


2) Commit only bugfixes to 2.3 branch:


  

-0

So please cast your votes and tell me what you prefer.

bye
Norman



  

Vincenzo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Quota matcher

2006-12-18 Thread Vincenzo Gianferrari Pini



Norman Maurer wrote:

Hi guys,

as you (hopefully) all know the current Quota code is very ineffectiv
and can cause many problems when using JDBC based mailrepository.

See:
http://issues.apache.org/jira/browse/JAMES-717
http://issues.apache.org/jira/browse/JAMES-718

For me there are 2 possible solutions at the moment for getting rid of it:

1. Add an comment to config.xml to explain the problems with this
matchers and mark the matchers as experimental.

+ 0

  

+1

2. Remove the code until we can provide a "usefull" support for quota.
For me thats impossible until we add the quota support to the storage
layer (Mailbox). This will propally not be done until we break storage
comptatibility

+ 1
  

-1

It is being used by some people and, although it is inefficient with 
JDBC based repositories, it works fine with file based ones, as for me. 
So we *cannot* remove it at all.


bye
Norman



  

Vincenzo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Reopened: (JAMES-712) Improbe Logging of delivery exception

2006-12-03 Thread Vincenzo Gianferrari Pini (JIRA)
 [ http://issues.apache.org/jira/browse/JAMES-712?page=all ]

Vincenzo Gianferrari Pini reopened JAMES-712:
-

 
The fix applied to RemoteDelivery does not compile under JDK 1.4 because uses 
"replace(CharSequence target, CharSequence replacement)".

> Improbe Logging of delivery exception
> -
>
> Key: JAMES-712
> URL: http://issues.apache.org/jira/browse/JAMES-712
> Project: James
>  Issue Type: Task
>  Components: Matchers/Mailets (bundled)
>Reporter: Norman Maurer
> Assigned To: Norman Maurer
>Priority: Minor
> Fix For: Next Major
>
>
> At the moment no information get logged why the remotemailserver return a 
> permanent or a temporary exception. Thats really bad logging for admins. We 
> should provide information of the cause without need for enable debugging in 
> RemoteDelivery

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Updated: (JAMES-616) Add chi-square-based spam filter approach to BayesianAnalyzer.

2006-11-28 Thread Vincenzo Gianferrari Pini (JIRA)
 [ http://issues.apache.org/jira/browse/JAMES-616?page=all ]

Vincenzo Gianferrari Pini updated JAMES-616:


Fix Version/s: Next Major

Gary Robinson gave a first answer with some clarifications/links and promised 
to come back, but didn't show up again.

But I think that the information I have may be enough.

> Add chi-square-based spam filter approach to BayesianAnalyzer.
> --
>
> Key: JAMES-616
> URL: http://issues.apache.org/jira/browse/JAMES-616
> Project: James
>  Issue Type: Improvement
>  Components: Matchers/Mailets (bundled)
>Affects Versions: Next Major
>    Reporter: Vincenzo Gianferrari Pini
> Assigned To: Vincenzo Gianferrari Pini
> Fix For: Trunk, Next Major
>
>
> We should add chi-square-based spam filter approach to BayesianAnalyzer, 
> based on Gary 
> Robinson's blog and paper 
> (http://garyrob.blogs.com//handlingtokenredundancy94.pdf).
> I will first of all write him an email asking for some clarifications.
> My impression for now is that the work should not be so difficult.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [DISCUSSION] Preparing next-major

2006-11-28 Thread Vincenzo Gianferrari Pini

It seems to be a reasonable set of choices.

I will try to have james-616 in time for the next checkpoint.

Vincenzo

Stefano Bagnara wrote:

Hi all,

Norman and I made today an IM session to review current JIRA issue. We:
1. moved to "Trunk" every issue having an assignee and no fix version
2. moved to "Trunk" every issue assigned to "Next-Major" and that we 
don't consider blocking for Trunk or we don't commit ourselves to fix 
soon.
3. created a list of issues we *could* work on before branching, but 
not blocking for the branching purpose (see the bottom).


Please review the following issue list on JIRA:
Open issues for "Next-Major"
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=10427&pid=10411&resolution=-1 


Fix for "Trunk"
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=12312135&pid=10411&resolution=-1 


Undefined fix release
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=-1&pid=10411&resolution=-1 



If you think something else *must* be included in next-major or 
*should* be included or you're likely to work on some backward 
compatible (storage and config.xml) issue please speak now :-)


We propose Dec 15 as the next checkpoint: that day we'll verify every 
"new feature"/"improvement"-issue assigned to next-major is fixed and 
we'll start a vote for branching and to define the release number or 
to delay the branch creation to a later date.


Once the branch will be created improvements/new features will be 
allowed only in RTC while fixes in trunk/branch in CTR.


Stefano


And here is the list of issues we'll optionally work on:
---
Stefano
JAMES-491 SpoolManager refactorings
JAMES-520 Create a RemoteDelivery service
JAMES-134 Large emails in the spool cause SpoolManager to throw 
OutOfMemoryError

JAMES-241 fail gracefully upon large messages/attachments
JAMES-288 memory efficient retrieval

Norman
JAMES-552 Clamav code should be moved to a "generic" class to use it 
on mailet,matcher,messagehandler
JAMES-670 Per IP connection limiting is not configurable per service, 
nor is the configuration logged during initialization.

JAMES-599 BeanShell Scripting in James


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: AW: Permanent errors from transient DNS issues?

2006-11-27 Thread Vincenzo Gianferrari Pini

Hi Jürgen,

if the target (destination) is wrong surely it's its administrator 
problem, but if it is a problem with my servers (either James or all my 
nameservers or the ones I query) or a network problem isolating me, then 
I don't want *all* my sending users get back immediate bounces and I 
want instead to try to fix the things, so it's my problem.


I sure may be wrong, but as I said before I'm making a difference here 
between *my* nameservers and the *target domain* nameservers.


Vincenzo

Jürgen Hoffmann wrote:

Hi Vincenzo,

seriously, if another mailserver is delivering a "552 No such user" Can we
really be sure that there really is no such user, or that the administrator
may have mis-configured his Mailserver. ;)

Kind regards

Juergen

-Ursprüngliche Nachricht-----
Von: Vincenzo Gianferrari Pini [mailto:[EMAIL PROTECTED] 
Gesendet: Montag, 27. November 2006 15:29

An: James Developers List
Betreff: Re: AW: Permanent errors from transient DNS issues?

Hi Norman,

IMHO the point is: are we sure of that? Will dnsjava return 
Lookup.TRY_AGAIN even if all *my nameservers* are reachable but they are 
isolated from the rest of the world?

And do you agree that the above is the right discriminator?

Ciao,

Vincenzo


Norman Maurer wrote:
  

Hi Vincenzo,

i whould asspect that dnsjava will return Lookup.TRY_AGAIN on such cases. 
And thats what i check for ;-)


bye
Norman

  


Hi Jürgen and Norman,

I agree with you *if* I can be sure that at least one of *my*
nameservers (the ones queried by my James server) is able to reach the
net and doesn't resolve the target domain (no target nameservers found),
and anwers NXDOMAIN. But is it possible to figure it out? And does
Norman's fix take in account that?

In other words, if all *my* nameservers are either unreachable, or are
themselves unable to forward the query, it means that there are
connection problems "on my side" and we can not "be pretty sure, that
there is no such Domain/MX Entry", and we should keep retrying. If
instead "an outer world" query is done then your reasoning is correct.

I'm making a difference here between *my* nameservers and the *target
domain* nameservers.

Am I right or I'm missing something here :-)?

Anyway, it is unacceptable to have a message bounce back only after one
week because there is a typo in the domain part of an address.

Vincenzo

Norman Maurer wrote:

  

Hi Jürgen,

that was exactly what i did. But then they all start complaining. Thats
why i changed it to be configurable.

bye
Norman


  


Hi All,

seriously, I disagree with how you expect DNS to work. A Domain has
configured "n" Nameservers that are responsible for Name resolution. So
I
would expect James to use all of them in a loop fashion.

If all Nameservers fail with "NXDOMAIN", or we cannot even determine,
that
there is not even one Nameserver for a given Domainname available, we
can
be pretty sure, that there is no such Domain/MX Entry.

So I would really like to handle this differently.

- If it is not possible to determine nameservers, bounce with perm
error
- If there are nameservers available, but not reachable, queue the
Mail.

Does this make sense?

Kind Regards

Juergen



-Ursprüngliche Nachricht-
Von: Steve Brewin [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 26. November 2006 18:39
An: 'James Developers List'
Betreff: RE: Permanent errors from transient DNS issues?

Norman Maurer wrote:



  

Ok.. RemoteDelivery now supports to configure a diffrent
retry for such
DNS "issues". Even if i not like it .. Anyway i hope now all
are happy..

  


:) Thanks Norman.

-- Steve



  

bye
Norman


  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

!EXCUBATOR:1,456ae2fb53071335268197!


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

!EXCUBATOR:1,456af64f53071672013762!



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: Permanent errors from transient DNS issues?

2006-11-27 Thread Vincenzo Gianferrari Pini

Hi Norman,

IMHO the point is: are we sure of that? Will dnsjava return 
Lookup.TRY_AGAIN even if all *my nameservers* are reachable but they are 
isolated from the rest of the world?

And do you agree that the above is the right discriminator?

Ciao,

Vincenzo


Norman Maurer wrote:

Hi Vincenzo,

i whould asspect that dnsjava will return Lookup.TRY_AGAIN on such cases. 
And thats what i check for ;-)


bye
Norman

  

Hi Jürgen and Norman,

I agree with you *if* I can be sure that at least one of *my*
nameservers (the ones queried by my James server) is able to reach the
net and doesn't resolve the target domain (no target nameservers found),
and anwers NXDOMAIN. But is it possible to figure it out? And does
Norman's fix take in account that?

In other words, if all *my* nameservers are either unreachable, or are
themselves unable to forward the query, it means that there are
connection problems "on my side" and we can not "be pretty sure, that
there is no such Domain/MX Entry", and we should keep retrying. If
instead "an outer world" query is done then your reasoning is correct.

I'm making a difference here between *my* nameservers and the *target
domain* nameservers.

Am I right or I'm missing something here :-)?

Anyway, it is unacceptable to have a message bounce back only after one
week because there is a typo in the domain part of an address.

Vincenzo

Norman Maurer wrote:


Hi Jürgen,

that was exactly what i did. But then they all start complaining. Thats
why i changed it to be configurable.

bye
Norman


  

Hi All,

seriously, I disagree with how you expect DNS to work. A Domain has
configured "n" Nameservers that are responsible for Name resolution. So
I
would expect James to use all of them in a loop fashion.

If all Nameservers fail with "NXDOMAIN", or we cannot even determine,
that
there is not even one Nameserver for a given Domainname available, we
can
be pretty sure, that there is no such Domain/MX Entry.

So I would really like to handle this differently.

- If it is not possible to determine nameservers, bounce with perm
error
- If there are nameservers available, but not reachable, queue the
Mail.

Does this make sense?

Kind Regards

Juergen



-Ursprüngliche Nachricht-
Von: Steve Brewin [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 26. November 2006 18:39
An: 'James Developers List'
Betreff: RE: Permanent errors from transient DNS issues?

Norman Maurer wrote:




Ok.. RemoteDelivery now supports to configure a diffrent
retry for such
DNS "issues". Even if i not like it .. Anyway i hope now all
are happy..

  

:) Thanks Norman.

-- Steve




bye
Norman


  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

!EXCUBATOR:1,456ae2fb53071335268197!







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: Permanent errors from transient DNS issues?

2006-11-27 Thread Vincenzo Gianferrari Pini

Hi Jürgen and Norman,

I agree with you *if* I can be sure that at least one of *my* 
nameservers (the ones queried by my James server) is able to reach the 
net and doesn't resolve the target domain (no target nameservers found), 
and anwers NXDOMAIN. But is it possible to figure it out? And does 
Norman's fix take in account that?


In other words, if all *my* nameservers are either unreachable, or are 
themselves unable to forward the query, it means that there are 
connection problems "on my side" and we can not "be pretty sure, that 
there is no such Domain/MX Entry", and we should keep retrying. If 
instead "an outer world" query is done then your reasoning is correct.


I'm making a difference here between *my* nameservers and the *target 
domain* nameservers.


Am I right or I'm missing something here :-)?

Anyway, it is unacceptable to have a message bounce back only after one 
week because there is a typo in the domain part of an address.


Vincenzo

Norman Maurer wrote:

Hi Jürgen,

that was exactly what i did. But then they all start complaining. Thats
why i changed it to be configurable.

bye
Norman

  

Hi All,

seriously, I disagree with how you expect DNS to work. A Domain has
configured "n" Nameservers that are responsible for Name resolution. So I
would expect James to use all of them in a loop fashion.

If all Nameservers fail with "NXDOMAIN", or we cannot even determine, that
there is not even one Nameserver for a given Domainname available, we can
be pretty sure, that there is no such Domain/MX Entry.

So I would really like to handle this differently.

- If it is not possible to determine nameservers, bounce with perm error
- If there are nameservers available, but not reachable, queue the Mail.

Does this make sense?

Kind Regards

Juergen



-Ursprüngliche Nachricht-
Von: Steve Brewin [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 26. November 2006 18:39
An: 'James Developers List'
Betreff: RE: Permanent errors from transient DNS issues?

Norman Maurer wrote:



Ok.. RemoteDelivery now supports to configure a diffrent
retry for such
DNS "issues". Even if i not like it .. Anyway i hope now all
are happy..
  

:) Thanks Norman.

-- Steve



bye
Norman

  
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Permanent errors from transient DNS issues?

2006-11-24 Thread Vincenzo Gianferrari Pini

Adding my 2c to Norman's example:

Because of the scenario he described, I changed my config.xml long time 
ago to one day instead of 5 days of retry before giving up.


I was planning to code in RemoteDelivery (and never did it) a kind of 
"warning bounce" feature to trigger after a few hours, while retrying 
for up to five days.
But it would be much better if we could find a way to check if "my DNS 
server" is failing to resolve the domain because the recursed servers 
fail to resolve, and not because there is a network problem isolating my 
local  network.


Or (a different approach) have a different retry policy (few hours 
instead of 5 days) for DNS resolution failures while keeping the longer 
5 days period in case of target SMTP server failures: the difference is 
that there is a "world wide" cache system for DNS resolution, and if a 
domain name is not found in such cache it is *much* more probable that 
the domain is non-existent for real and not that there are network 
problems. What do you think?


Vincenzo

Norman Maurer wrote:

Noel J. Bergman schrieb:
  

Norman,

  


Noel J. Bergman schrieb:

  

-1
  
The handling of this condition as temporary was very intentional, and

in no way accidental.  This is a not uncommon problem.  The DNS can be
wrong, and later corrected.  The problem is ascertaining whether a
domain is non-existent for real (there is no registration record) or
because of a temporary DNS configuration error.

Consider the debate within the SPF council regarding whether or not
NXDOMAIN was to be treated as a PermError or TempFail.
  

  


This was not the final solution. See revision 478589

  

I am not happy with the change.  As I read it, r478589 is a bit better only if 
the local DNS server is down.  That's only one of several DNS related issues 
that can result in failure.

Consider http://www.mhonarc.org/archive/html/spf-discuss/2005-05/msg00327.html. 
 I do consider the author of that particular e-mail to wrong because the intent 
of the SMTP specification is to put a very high degree of reliability on the 
delivery of mail.  We bias decisions to ensure delivery.  But the point is for 
you to read the real-world examples of DNS failure given to him as examples.  
And, FWIW, I have seen similar errors and had mail lost by qmail that would not 
have been lost by JAMES.

I am OK with optional filters for rejecting mail in-protocol if the MAIL FROM 
or even REPLY-TO domains are invalid (even temporarily), but I am *not* OK with 
hardcoding the change you are making to bounce mail because there is a 
transient DNS glitch on the delivery side.

Do you understand now?

--- Noel

  



Hi Noel,

i not agree with you. First of all if the nameserver is not configured
correctly etc we should not try to "take care" and give the admin a
chance to correct it He should get sure what he do before change the
config.. I think most admins and users want to get the error as soon as
possible. Let me  give you an example why the old behavoir is bad:

Think about you have a  costumer where you installed james. He sended an
email with an importent text out and not notice that he has a misstyping
in the domainname. The domain he used as recipient domain does not
exists. But he not get the bounce back till the configured retry count
was reached.. (about 5 days). Because of that  he not notice that he had
a misstyping in the domainname, so he lost a job which whould hat
brought him 1 000  Dollars. How you whould explain him this ?

This is not acceptable for me.. If we have an other DNS error then a
temporary connection problem we should bounce as soon as possible.

Don't get me wrong.. im not aggressiv.. I only try to explain you why i
think the old behavoir is really bad!

bye
Norman



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))

2006-11-23 Thread Vincenzo Gianferrari Pini

+1

Vincenzo

Jürgen Hoffmann wrote:

Hi guys,

sorry if my last 2 E-Mails were shot before reading all Mails, but I am on a
GPRS Link at the moment, and using it is really a PITA.

Anyways, just to sum it up. It seems we all have the same view now, and can
agree with consent. Everyone is fine with what Stefano is doing, if he labels
issues both with "next-major" AND "trunk" correct?

Kind regards

Juergen


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))

2006-11-22 Thread Vincenzo Gianferrari Pini
So what you mean is that the right thing to do is, if someone plans to 
have something fixed/working for next-major is to *add* the next-major 
fix version *without removing* the trunk label, right? Sounds correct.


Vincenzo

Noel J. Bergman wrote:

Jürgen Hoffmann wrote:

  

All he is doing is that he is tagging certain jira-issues,
that they are fixed in the next-major



Well, that is the thing.  They may or may not be.  What there ARE closed in
is trunk.  I don't really care if they are listed against next-major, but
when we actually have code for next-major (remember: trunk is copied, then
PRUNED to become next-major), it may turn out that they are not resolved in
next-major at all.

All that I asked him to do was stop removing trunk as a label, since that IS
where the issue is resolved.

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))

2006-11-22 Thread Vincenzo Gianferrari Pini

Hi everybody,

Juergen said it exactly: what Stefano and Norman are doing is just proactively judging 
what they think could and should be fixed/developed for "next-major", and 
documenting it through jira labels, without any change to our subversion repository. All 
the committers are free to have - issue by issue - a different opinion and re-change the 
labels.

When, sooner or later, "next-major" will be considered mature to be finalized, an SVN 
branching will be voted and done and a version number will voted and applied, and the jira labels 
renamed accordingly. Same for "next-minor".

I think that we all can and should stay calm, peaceful, optimistic and polite.

Vincenzo


Jürgen Hoffmann wrote:

Hi Bernd,

>From my viewpoint, all he is trying to do is to define a rough road map for
himself with the tools he has at hand.

And if trunk == next-major, where is the difference? Why is everyone so touchy
about the term?

I think what he is doing is fine, you guys voted about what you would like to
work on ("next-major"). All he is doing is that he is tagging certain
jira-issues, that they are fixed in the next-major, which is really just a
label inside jira.

So that after the discussion and vote for a branch is over, and after the
discussion/vote about a next version number is over, just rename the label.

That saves a lot of work. So I really see nothing bad in doing so.

My 2 cents

Juergen

-Ursprüngliche Nachricht-
Von: Bernd Fondermann [mailto:[EMAIL PROTECTED] 
Gesendet: Dienstag, 21. November 2006 11:56

An: James Developers List
Betreff: Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))

Stefano,

Again I find it very disturbing how you manage this "next-major" thing.

We just made a release, have massive changes in the codebase, are
weeks (if not months) away from a branch and you are suggesting what
is or is not in the next release. All this by applying an artificial
abstract label (BTW, what is the follow-up label, "next-major 2.0"?)
to code which _is_ on /trunk/ and not on a /branch/.
When I noticed all the JIRA logs on the weekend I was really flatted.
No time to respond to that until now, and really I still don't feel
like answering. Anyway.

This all happens in the light of severe reservations by some
committers concerning the branching/releasing thing as you put it and
a release numbering vote pending on [EMAIL PROTECTED]

On 11/21/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
  

Noel J. Bergman wrote:


Fix Version/s: Next Major (was: Trunk)


Please stop doing this and messing up the JIRA issues.
  

I kept updated JIRA for the last year and more following this schema.

We agreed to have sequential branches and not diverging brnaches so it
make real sense to use that method, imho.



I don`t know of any current release branch in svn other than 2.3.x.
can you point me to it?

  

If you can't leave with me updating JIRA and mantaining this schema
bring your own reason.



by saying that, are you suggesting you can do with JIRA whatever you
want? this is not a co-operative reasoning.

  

As we did with 2.3 and trunk we agreed that everything we could have
written for 2.3 would have been applied first in trunk and then
backported. This way there is no issue applied to 2.3 that will not be
in trunk.



+1. that was when we had a release branch for 2.3.0.

  

Using only 2.3 as fix version will make a much more clean
roadmap/changelog and will make us understand better the current scenario.



don't understand that one, sorry.

  

I said I would have operated this way more than 1 year ago, if we want
to change this.



you changed the way you operate. everyone else did not move.

  

 > trunk is real.  next_major is nothing.

Next-major is the only real roadmap we currently have: it has proposal,
status update and discussions. And also a REAL VOTE!



please don't confuse the voting outcome with your personal
comprehension of what the vote might justify you to do. the vote is
not a blank cheque to storm away.
let us work on trunk in the way the vote is suggesting and talk about
branching and releasing when this is due.

there is lots of code added/changed and this is a very good thing. all
is progressing fine. we are in the coding and refactoring phase of the
release cycle. we partially skipped the planning phase, because it was
obscured by stupid pseudo-roadmap discussions. but we are not not
feature-finalizing, not branching, not final-testing, not RCing. am I
wrong?

only about half a year ago you said things like "I can live without a
release, I don't care for releasing". Now I am under the impression
you would like to push a second release out of the door not after
tommorrow.

  

On the other side I still have to see the roadmap for next-minor if we
want to talk about nothing and real...



By saying this you are trying to put pressure on people who are - from
your view - not getting enough things done. Do you t

Re: isLogEnabled() and StringBuffer

2006-11-17 Thread Vincenzo Gianferrari Pini

 :-)

Vincenzo

Joachim Draeger wrote:

Vincenzo Gianferrari Pini wrote:

BTW: I have often seen NPE *bugs* in debug messages, that appeared
magically when the costumer has turned on *de*bugging. :-) This could
avoided by putting a try/catch block around...

  

Im against this.. Even if the NPE is in the debug message it should not
catched. IMHO thats a bad practice.. NPE should fixed not "catched" ;-)


  Norman is totally right.

We should notice that the NullPointerException class is on purpose a 
subclass of RuntimeException, whose handling is not enforced by the 
java compiler just because it is a "coding error" that, by 
definition,  can not be anticipated and should just be fixed when 
found. It does not make sense to anticipate any possible 
RuntimeException *locally* in any possible place surrounding 
everything everywhere by try/catch blocks.


Sorry! I should have written:
 This could avoided by putting a try/catch block around... 

Shame on me, I know it is bad style to use irony 1. in electronic 
communication 2. in a language that is not ones first.

I was joking related to methods to blow up code.

Joachim



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: isLogEnabled() and StringBuffer

2006-11-17 Thread Vincenzo Gianferrari Pini



Norman Maurer wrote:

Joachim Draeger schrieb:
  
  

...
  

BTW: I have often seen NPE *bugs* in debug messages, that appeared
magically when the costumer has turned on *de*bugging. :-) This could
avoided by putting a try/catch block around...

Joachim

  


Im against this.. Even if the NPE is in the debug message it should not
catched. IMHO thats a bad practice.. NPE should fixed not "catched" ;-)

bye
Norman



  

Norman is totally right.

We should notice that the NullPointerException class is on purpose a 
subclass of RuntimeException, whose handling is not enforced by the java 
compiler just because it is a "coding error" that, by definition,  can 
not be anticipated and should just be fixed when found. It does not make 
sense to anticipate any possible RuntimeException *locally* in any 
possible place surrounding everything everywhere by try/catch blocks.
It does make sense instead to have a global try/catch block somewhere to 
avoid having a server crash, and this does exist in James (see 
http://wiki.apache.org/james/HandlingExceptions).


Vincenzo




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



James development using NetBeans

2006-11-12 Thread Vincenzo Gianferrari Pini
Some notes on how to develop, run, debug and profile  James using 
NetBeans can now be found in


http://wiki.apache.org/james/NetBeansNotes

Vincenzo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  1   2   3   4   >