[X] +1 Release these artifacts
Build from tag passed with `mvn clean install site` on
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-18T06:33:14+12:00)
Maven home: /opt/apache-maven-3.5.4
Java version: 1.8.0_232, vendor: Private Build, runtime:
Sorry, missed this one. On it. Vote e-mail should be in within the next 30
mins.
Bruno
On Friday, 3 January 2020, 10:58:23 am NZDT, Gary Gregory
wrote:
May we get more PMC reviews please?
Gary
On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory wrote:
> We have fixed quite a few bugs
> On Jan 2, 2020, at 6:55 PM, Alex Herbert wrote:
>
>
>
>> On 2 Jan 2020, at 16:53, Rob Tompkins wrote:
>>
>> +0 (could be convinced of +1)
>>
>> RAT:
>>
>> *
>> Summary
>> ---
>> Generated at: 2020-01-02T10:45:36-05:00
>>
>>
> On 2 Jan 2020, at 16:53, Rob Tompkins wrote:
>
> +0 (could be convinced of +1)
>
> RAT:
>
> *
> Summary
> ---
> Generated at: 2020-01-02T10:45:36-05:00
>
> Notes: 3
> Binaries: 4
> Archives: 1
> Standards: 287
>
> Apache Licensed:
May we get more PMC reviews please?
Gary
On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory wrote:
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Codec 1.13 was released, so I would like to release
> Apache Commons Codec 1.14.
>
> Apache Commons
Folks,
In https://issues.apache.org/jira/browse/NET-414 we introduced a check that the
source port of a TFTP reply is not identical to the control port.
Which by itself is not a bad idea.
As it allows a server to handle multiple, parallel connections. It uses the
port number as a session
Pardon vague..
My vote: +1 (binding)
> On Jan 2, 2020, at 12:16 PM, Rob Tompkins wrote:
>
> +1
>
>> On Jan 2, 2020, at 12:15 PM, Gary Gregory wrote:
>>
>> The fix would be to exclude this _test_ fixture file from the RAT check in
>> the POM.
>>
>> Not a blocker IMO.
>>
>> Gary
>>
>> On
+1
> On Jan 2, 2020, at 12:15 PM, Gary Gregory wrote:
>
> The fix would be to exclude this _test_ fixture file from the RAT check in
> the POM.
>
> Not a blocker IMO.
>
> Gary
>
> On Thu, Jan 2, 2020, 11:53 Rob Tompkins wrote:
>
>> +0 (could be convinced of +1)
>>
>> RAT:
>>
>>
The fix would be to exclude this _test_ fixture file from the RAT check in
the POM.
Not a blocker IMO.
Gary
On Thu, Jan 2, 2020, 11:53 Rob Tompkins wrote:
> +0 (could be convinced of +1)
>
> RAT:
>
> *
> Summary
> ---
> Generated at:
+0 (could be convinced of +1)
RAT:
*
Summary
---
Generated at: 2020-01-02T10:45:36-05:00
Notes: 3
Binaries: 4
Archives: 1
Standards: 287
Apache Licensed: 286
Generated Documents: 0
JavaDocs are generated, thus a license header is
Just saw this. Will work on the validation over the next 30 mins.
-Rob
> On Jan 2, 2020, at 9:38 AM, Gary Gregory wrote:
>
> My +1
>
> Gary
>
>
> On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory wrote:
>
>> We have fixed quite a few bugs and added some significant enhancements
>> since Apache
My +1
Gary
On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory wrote:
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Codec 1.13 was released, so I would like to release
> Apache Commons Codec 1.14.
>
> Apache Commons Codec 1.14 RC1 is available for
On 2020-01-02, Oliver Heger wrote:
> The change of the bundle name does not necessarily break all OSGi users.
> AFAIK, the recommended way to use an OSGi bundle is to import the
> packages, not to require a specific bundle - this use case would not be
> affected by the change of the bundle name.
On 2020-01-02, Bruno P. Kinoshita wrote:
> I think if we are going to release it soon, the only option to support java
> 14+ the would be to remove it. Tell users it may be added back later either
> as-was or as a separate artefact.
If we want to cut a new release soon, we can just tell people
Am 02.01.20 um 12:08 schrieb Bruno P. Kinoshita:
> Also not a user of OSGi. But I feel like it is a bug that could be reverted
> and informed in the changelog and release email?
> But not too sure if that's the best option.
> Bruno
>
> Sent from Yahoo Mail on Android
>
> On Thu, 2 Jan
I think if we are going to release it soon, the only option to support java 14+
the would be to remove it. Tell users it may be added back later either as-was
or as a separate artefact.
Just my 0.02 cents
CheersBruno
Sent from Yahoo Mail on Android
On Thu, 2 Jan 2020 at 23:06, Stefan
Also not a user of OSGi. But I feel like it is a bug that could be reverted and
informed in the changelog and release email?
But not too sure if that's the best option.
Bruno
Sent from Yahoo Mail on Android
On Thu, 2 Jan 2020 at 22:56, Stefan Bodewig wrote: Hi
all
due to a change in the
Hi
our travis build also uses the combination
- dist: trusty
jdk: openjdk-ea
which has started to use OpenJDK 14 a while ago and our build has been
failing there ever since. The reason is
https://openjdk.java.net/jeps/367 - the whole Pack200 stuff has been
removed without any
Hi all
due to a change in the parent POM the Bundle-SymbolicName of the
commons-compress JAR changed from org.apache.commons.compress to
org.apache.commons.commons-compress with version 1.18. So we've had a
lot of releases up to 1.17 with one name and two newer releases with a
different name in
19 matches
Mail list logo
