You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2018/11/14 08:17:38 UTC
[VOTE] Release Apache Commons Pool2 2.6.1
Hi folks!
I'm currently preparing the release for commons-pool2-2.6.1
So far I did
* fix the missing parts in changes.xml
* generate + copy the RELEASE_NOTES
* run the maven release (after fixing the setup...)
The ASF staging repository is at
https://repository.apache.org/content/repositories/orgapachecommons-1396/
The source zip is at
https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
The sha512 is 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
I added my KEY (struberg at apache.org) to our dist KEYS file
https://dist.apache.org/repos/dist/release/commons/KEYS
I will now continue with the follow up steps and then call an official VOTE.
Please let me know if something went wrong so far!
LieGrue,
strub
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
We've done this since 2011 in a few projects.
It might seem to not be usual for commons but if you think through then it's perfectly ok (and also acked by the board):
A GIT commit is uniquely identified by the sha1 of the parrent commit + the the diff of the commit.
That's the magic why a repo can be cloned and handled independently at all.
When the VOTE did pass we simply do 2 steps:
1.) propagate the staging repo to proper (and check in the source-release.zip to our dist/release)
2.) push/merge the changes to master and push it to our cannnonical GIT repo at the ASF. + push the tag as well.
The sha1 doesn't change during that step, so it's guaranteed that it's the exact same as we voted on.
LieGrue,
strub
> Am 14.11.2018 um 17:15 schrieb Gary Gregory <ga...@gmail.com>:
>
> Per http://www.apache.org/legal/release-policy.html#host-rc it should be OK
> to host the RC sources on the Apache Nexus repo instead of the dist tree.
>
> This is different from how we usually do RCs but is should be OK.
>
> Not sure about using GitHub though...
>
> Gary
>
> On Wed, Nov 14, 2018, 09:00 Mark Struberg <struberg@yahoo.de.invalid wrote:
>
>> PS: the VOTE is open for 72h from now on.
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 14.11.2018 um 16:58 schrieb Mark Struberg <st...@yahoo.de>:
>>>
>>> Oki, now the full VOTE text!
>>>
>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>>>
>>>
>>> The ASF staging repository is at
>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>
>>> The source zip is at
>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>> The sha1 of the source-release zip is
>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>> The sha512 is
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>
>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>
>>> I've created the release in a GIT manner and pushed the according
>> changes to my ASF-linked github repo
>>>
>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>> the sha1 of the commit is
>>>
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>
>>> the tag is
>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>> c910171
>>>
>>> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
>>>
>>> Site will be updated once the release has passed.
>>>
>>> Please VOTE:
>>>
>>> [+1] go ship it!
>>> [+0] meh, I don't care
>>> [-1] stop there is a ${showstopper} (that means something _important_ is
>> missing!)
>>>
>>>
>>> Here is my own +1
>>> checked:
>>> * signature
>>> * hashes
>>> * LICENSE
>>> * NOTICE
>>> * rat
>>> * builds fine with various JDKs
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>>
>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg <struberg@yahoo.de.INVALID
>>> :
>>>>
>>>> PS: I've created the release in a GIT manner and pushed the according
>> changes to my ASF-linked github repo
>>>>
>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>> the sha1 of the commit is
>>>>
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>
>>>> the tag is
>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>> c910171
>>>>
>>>> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
>>>> Yay, this is the way GIT works and before someone not familiar with GIT
>> screams that this is not hosted on ASF: This got discussed on the board
>> level a long time ago (when we did DeltaSpike and CouchDB as the very first
>> GIT repos at the ASF) and is perfectly fine as all this is based on
>> cryptographically strong steps.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg <struberg@yahoo.de.INVALID
>>> :
>>>>>
>>>>> Hi folks!
>>>>>
>>>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>>>
>>>>> So far I did
>>>>>
>>>>> * fix the missing parts in changes.xml
>>>>> * generate + copy the RELEASE_NOTES
>>>>> * run the maven release (after fixing the setup...)
>>>>>
>>>>> The ASF staging repository is at
>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>
>>>>> The source zip is at
>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>> The sha1 of the source-release zip is
>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>> The sha512 is
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>
>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>
>>>>> I will now continue with the follow up steps and then call an official
>> VOTE.
>>>>>
>>>>> Please let me know if something went wrong so far!
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
Per http://www.apache.org/legal/release-policy.html#host-rc it should be OK
to host the RC sources on the Apache Nexus repo instead of the dist tree.
This is different from how we usually do RCs but is should be OK.
Not sure about using GitHub though...
Gary
On Wed, Nov 14, 2018, 09:00 Mark Struberg <struberg@yahoo.de.invalid wrote:
> PS: the VOTE is open for 72h from now on.
>
> LieGrue,
> strub
>
>
> > Am 14.11.2018 um 16:58 schrieb Mark Struberg <st...@yahoo.de>:
> >
> > Oki, now the full VOTE text!
> >
> > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > The release was run with JDK-1.7 to ensure Java7 compatibility.
> >
> >
> > The ASF staging repository is at
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >
> > The source zip is at
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > The sha512 is
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >
> > I added my KEY (struberg at apache.org) to our dist KEYS file
> > https://dist.apache.org/repos/dist/release/commons/KEYS
> >
> > I've created the release in a GIT manner and pushed the according
> changes to my ASF-linked github repo
> >
> > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > the sha1 of the commit is
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >
> > the tag is
> > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > c910171
> >
> > This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> >
> > Site will be updated once the release has passed.
> >
> > Please VOTE:
> >
> > [+1] go ship it!
> > [+0] meh, I don't care
> > [-1] stop there is a ${showstopper} (that means something _important_ is
> missing!)
> >
> >
> > Here is my own +1
> > checked:
> > * signature
> > * hashes
> > * LICENSE
> > * NOTICE
> > * rat
> > * builds fine with various JDKs
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >
> >> Am 14.11.2018 um 10:13 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> >:
> >>
> >> PS: I've created the release in a GIT manner and pushed the according
> changes to my ASF-linked github repo
> >>
> >> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >> the sha1 of the commit is
> >>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>
> >> the tag is
> >> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >> c910171
> >>
> >> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> >> Yay, this is the way GIT works and before someone not familiar with GIT
> screams that this is not hosted on ASF: This got discussed on the board
> level a long time ago (when we did DeltaSpike and CouchDB as the very first
> GIT repos at the ASF) and is perfectly fine as all this is based on
> cryptographically strong steps.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 14.11.2018 um 09:17 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> >:
> >>>
> >>> Hi folks!
> >>>
> >>> I'm currently preparing the release for commons-pool2-2.6.1
> >>>
> >>> So far I did
> >>>
> >>> * fix the missing parts in changes.xml
> >>> * generate + copy the RELEASE_NOTES
> >>> * run the maven release (after fixing the setup...)
> >>>
> >>> The ASF staging repository is at
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>
> >>> The source zip is at
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>> The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>> The sha512 is
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>
> >>> I added my KEY (struberg at apache.org) to our dist KEYS file
> >>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>
> >>> I will now continue with the follow up steps and then call an official
> VOTE.
> >>>
> >>> Please let me know if something went wrong so far!
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
PS: the VOTE is open for 72h from now on.
LieGrue,
strub
> Am 14.11.2018 um 16:58 schrieb Mark Struberg <st...@yahoo.de>:
>
> Oki, now the full VOTE text!
>
> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> The release was run with JDK-1.7 to ensure Java7 compatibility.
>
>
> The ASF staging repository is at
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>
> The source zip is at
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>
> I added my KEY (struberg at apache.org) to our dist KEYS file
> https://dist.apache.org/repos/dist/release/commons/KEYS
>
> I've created the release in a GIT manner and pushed the according changes to my ASF-linked github repo
>
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> the sha1 of the commit is
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>
> the tag is
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> c910171
>
> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
>
> Site will be updated once the release has passed.
>
> Please VOTE:
>
> [+1] go ship it!
> [+0] meh, I don't care
> [-1] stop there is a ${showstopper} (that means something _important_ is missing!)
>
>
> Here is my own +1
> checked:
> * signature
> * hashes
> * LICENSE
> * NOTICE
> * rat
> * builds fine with various JDKs
>
>
> LieGrue,
> strub
>
>
>
>
>
>> Am 14.11.2018 um 10:13 schrieb Mark Struberg <st...@yahoo.de.INVALID>:
>>
>> PS: I've created the release in a GIT manner and pushed the according changes to my ASF-linked github repo
>>
>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>> the sha1 of the commit is
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>
>> the tag is
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>> c910171
>>
>> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
>> Yay, this is the way GIT works and before someone not familiar with GIT screams that this is not hosted on ASF: This got discussed on the board level a long time ago (when we did DeltaSpike and CouchDB as the very first GIT repos at the ASF) and is perfectly fine as all this is based on cryptographically strong steps.
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg <st...@yahoo.de.INVALID>:
>>>
>>> Hi folks!
>>>
>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>
>>> So far I did
>>>
>>> * fix the missing parts in changes.xml
>>> * generate + copy the RELEASE_NOTES
>>> * run the maven release (after fixing the setup...)
>>>
>>> The ASF staging repository is at
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>
>>> The source zip is at
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>> The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>> The sha512 is 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>
>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>
>>> I will now continue with the follow up steps and then call an official VOTE.
>>>
>>> Please let me know if something went wrong so far!
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
Is there a site available?
Gary
On Wed, Nov 14, 2018, 08:59 Mark Struberg <struberg@yahoo.de.invalid wrote:
> Oki, now the full VOTE text!
>
> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> The release was run with JDK-1.7 to ensure Java7 compatibility.
>
>
> The ASF staging repository is at
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>
> The source zip is at
>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>
> I added my KEY (struberg at apache.org) to our dist KEYS file
> https://dist.apache.org/repos/dist/release/commons/KEYS
>
> I've created the release in a GIT manner and pushed the according changes
> to my ASF-linked github repo
>
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> the sha1 of the commit is
>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>
> the tag is
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> c910171
> <https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171>
>
> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
>
> Site will be updated once the release has passed.
>
> Please VOTE:
>
> [+1] go ship it!
> [+0] meh, I don't care
> [-1] stop there is a ${showstopper} (that means something _important_ is
> missing!)
>
>
> Here is my own +1
> checked:
> * signature
> * hashes
> * LICENSE
> * NOTICE
> * rat
> * builds fine with various JDKs
>
>
> LieGrue,
> strub
>
>
>
>
>
> > Am 14.11.2018 um 10:13 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> >:
> >
> > PS: I've created the release in a GIT manner and pushed the according
> changes to my ASF-linked github repo
> >
> > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > the sha1 of the commit is
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >
> > the tag is
> > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > c910171
> >
> > This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> > Yay, this is the way GIT works and before someone not familiar with GIT
> screams that this is not hosted on ASF: This got discussed on the board
> level a long time ago (when we did DeltaSpike and CouchDB as the very first
> GIT repos at the ASF) and is perfectly fine as all this is based on
> cryptographically strong steps.
> >
> > LieGrue,
> > strub
> >
> >
> >> Am 14.11.2018 um 09:17 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> >:
> >>
> >> Hi folks!
> >>
> >> I'm currently preparing the release for commons-pool2-2.6.1
> >>
> >> So far I did
> >>
> >> * fix the missing parts in changes.xml
> >> * generate + copy the RELEASE_NOTES
> >> * run the maven release (after fixing the setup...)
> >>
> >> The ASF staging repository is at
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>
> >> The source zip is at
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >> The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >> The sha512 is
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>
> >> I added my KEY (struberg at apache.org) to our dist KEYS file
> >> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>
> >> I will now continue with the follow up steps and then call an official
> VOTE.
> >>
> >> Please let me know if something went wrong so far!
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
Site build fails because we refer to
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/pool
instead of
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-pool
Gary
On Sat, Nov 17, 2018 at 7:55 AM Rob Tompkins <ch...@gmail.com> wrote:
> Pardon my being a little late to the party here.
>
> Thoughts in going through release validation (might be a tad redundant):
> - We’re not much used to the maven assemblies being deployed to
> nexus, but that isn’t necessarily a problem.
> - Why do we have a "-source-release” and a “-src” artifact?
> - Do you plan to put the artifacts in the dist.apache.org area
> when you’re ready to promote?
> - There don’t seem to be any build errors with the release.
>
> Given this is considerably different than our standard release paradigm,
> what is your plan on ensuring that the commons site looks like it does
> today (with the new release candidate present)? It seems clear that you
> didn’t follow the directions laid out at
> https://commons.apache.org/releases/prepare.html, how are we to be sure
> you will follow the directions at
> https://commons.apache.org/releases/release.html? That said, the RC
> itself seems to be valid.
>
> Do we want to cancel to include Gary’s
> https://issues.apache.org/jira/browse/POOL-359 <
> https://issues.apache.org/jira/browse/POOL-359> in 2.6.1?
>
> I don’t think that have a solid vote until the questions above get
> answered. But, if we can ensure that the site will look proper and all of
> the requisite artifacts are in their requisite locations, I don’t see any
> reason to block this release.
>
> Let me know what your thoughts are.
>
> Cheers,
> -Rob
>
> > On Nov 14, 2018, at 10:58 AM, Mark Struberg <st...@yahoo.de.INVALID>
> wrote:
> >
> > Oki, now the full VOTE text!
> >
> > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > The release was run with JDK-1.7 to ensure Java7 compatibility.
> >
> >
> > The ASF staging repository is at
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >
> > The source zip is at
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > The sha512 is
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >
> > I added my KEY (struberg at apache.org) to our dist KEYS file
> > https://dist.apache.org/repos/dist/release/commons/KEYS
> >
> > I've created the release in a GIT manner and pushed the according
> changes to my ASF-linked github repo
> >
> > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > the sha1 of the commit is
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >
> > the tag is
> > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > c910171
> >
> > This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> >
> > Site will be updated once the release has passed.
> >
> > Please VOTE:
> >
> > [+1] go ship it!
> > [+0] meh, I don't care
> > [-1] stop there is a ${showstopper} (that means something _important_ is
> missing!)
> >
> >
> > Here is my own +1
> > checked:
> > * signature
> > * hashes
> > * LICENSE
> > * NOTICE
> > * rat
> > * builds fine with various JDKs
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >
> >> Am 14.11.2018 um 10:13 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> >:
> >>
> >> PS: I've created the release in a GIT manner and pushed the according
> changes to my ASF-linked github repo
> >>
> >> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >> the sha1 of the commit is
> >>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>
> >> the tag is
> >> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >> c910171
> >>
> >> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> >> Yay, this is the way GIT works and before someone not familiar with GIT
> screams that this is not hosted on ASF: This got discussed on the board
> level a long time ago (when we did DeltaSpike and CouchDB as the very first
> GIT repos at the ASF) and is perfectly fine as all this is based on
> cryptographically strong steps.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 14.11.2018 um 09:17 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> >:
> >>>
> >>> Hi folks!
> >>>
> >>> I'm currently preparing the release for commons-pool2-2.6.1
> >>>
> >>> So far I did
> >>>
> >>> * fix the missing parts in changes.xml
> >>> * generate + copy the RELEASE_NOTES
> >>> * run the maven release (after fixing the setup...)
> >>>
> >>> The ASF staging repository is at
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>
> >>> The source zip is at
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>> The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>> The sha512 is
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>
> >>> I added my KEY (struberg at apache.org) to our dist KEYS file
> >>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>
> >>> I will now continue with the follow up steps and then call an official
> VOTE.
> >>>
> >>> Please let me know if something went wrong so far!
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Rob Tompkins <ch...@gmail.com>.
Pardon my being a little late to the party here.
Thoughts in going through release validation (might be a tad redundant):
- We’re not much used to the maven assemblies being deployed to nexus, but that isn’t necessarily a problem.
- Why do we have a "-source-release” and a “-src” artifact?
- Do you plan to put the artifacts in the dist.apache.org area when you’re ready to promote?
- There don’t seem to be any build errors with the release.
Given this is considerably different than our standard release paradigm, what is your plan on ensuring that the commons site looks like it does today (with the new release candidate present)? It seems clear that you didn’t follow the directions laid out at https://commons.apache.org/releases/prepare.html, how are we to be sure you will follow the directions at https://commons.apache.org/releases/release.html? That said, the RC itself seems to be valid.
Do we want to cancel to include Gary’s https://issues.apache.org/jira/browse/POOL-359 <https://issues.apache.org/jira/browse/POOL-359> in 2.6.1?
I don’t think that have a solid vote until the questions above get answered. But, if we can ensure that the site will look proper and all of the requisite artifacts are in their requisite locations, I don’t see any reason to block this release.
Let me know what your thoughts are.
Cheers,
-Rob
> On Nov 14, 2018, at 10:58 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>
> Oki, now the full VOTE text!
>
> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> The release was run with JDK-1.7 to ensure Java7 compatibility.
>
>
> The ASF staging repository is at
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>
> The source zip is at
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>
> I added my KEY (struberg at apache.org) to our dist KEYS file
> https://dist.apache.org/repos/dist/release/commons/KEYS
>
> I've created the release in a GIT manner and pushed the according changes to my ASF-linked github repo
>
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> the sha1 of the commit is
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>
> the tag is
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> c910171
>
> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
>
> Site will be updated once the release has passed.
>
> Please VOTE:
>
> [+1] go ship it!
> [+0] meh, I don't care
> [-1] stop there is a ${showstopper} (that means something _important_ is missing!)
>
>
> Here is my own +1
> checked:
> * signature
> * hashes
> * LICENSE
> * NOTICE
> * rat
> * builds fine with various JDKs
>
>
> LieGrue,
> strub
>
>
>
>
>
>> Am 14.11.2018 um 10:13 schrieb Mark Struberg <st...@yahoo.de.INVALID>:
>>
>> PS: I've created the release in a GIT manner and pushed the according changes to my ASF-linked github repo
>>
>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>> the sha1 of the commit is
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>
>> the tag is
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>> c910171
>>
>> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
>> Yay, this is the way GIT works and before someone not familiar with GIT screams that this is not hosted on ASF: This got discussed on the board level a long time ago (when we did DeltaSpike and CouchDB as the very first GIT repos at the ASF) and is perfectly fine as all this is based on cryptographically strong steps.
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg <st...@yahoo.de.INVALID>:
>>>
>>> Hi folks!
>>>
>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>
>>> So far I did
>>>
>>> * fix the missing parts in changes.xml
>>> * generate + copy the RELEASE_NOTES
>>> * run the maven release (after fixing the setup...)
>>>
>>> The ASF staging repository is at
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>
>>> The source zip is at
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>> The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>> The sha512 is 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>
>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>
>>> I will now continue with the follow up steps and then call an official VOTE.
>>>
>>> Please let me know if something went wrong so far!
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com> a écrit
> :
>
> > On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg <struberg@yahoo.de.invalid
> >
> > wrote:
> >
> > > Oki, now the full VOTE text!
> > >
> > > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > > The release was run with JDK-1.7 to ensure Java7 compatibility.
> > >
> > >
> > > The ASF staging repository is at
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > >
> > > The source zip is at
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > > The sha1 of the source-release zip is
> > > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > > The sha512 is
> > >
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> > >
> >
> > For me:
> >
> > $ sha512sum commons-pool2-2.6.1-src.zip
> >
> >
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> > *commons-pool2-2.6.1-src.zip
> >
> > Which is not what you list above. Please advise.
> >
>
> Src vs source-release?
>
Yes, the hash matches source-release, thank you!
Gary
>
>
>
>
>
> > Gary
> >
> >
> > >
> > > I added my KEY (struberg at apache.org) to our dist KEYS file
> > > https://dist.apache.org/repos/dist/release/commons/KEYS
> > >
> > > I've created the release in a GIT manner and pushed the according
> changes
> > > to my ASF-linked github repo
> > >
> > > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > > the sha1 of the commit is
> > >
> > >
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> > >
> > > the tag is
> > > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > > c910171
> > > <
> > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> >
> > >
> > > This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> > >
> > > Site will be updated once the release has passed.
> > >
> > > Please VOTE:
> > >
> > > [+1] go ship it!
> > > [+0] meh, I don't care
> > > [-1] stop there is a ${showstopper} (that means something _important_
> is
> > > missing!)
> > >
> > >
> > > Here is my own +1
> > > checked:
> > > * signature
> > > * hashes
> > > * LICENSE
> > > * NOTICE
> > > * rat
> > > * builds fine with various JDKs
> > >
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > >
> > > > Am 14.11.2018 um 10:13 schrieb Mark Struberg
> <struberg@yahoo.de.INVALID
> > > >:
> > > >
> > > > PS: I've created the release in a GIT manner and pushed the according
> > > changes to my ASF-linked github repo
> > > >
> > > > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > > > the sha1 of the commit is
> > > >
> > >
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> > > >
> > > > the tag is
> > > > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > > > c910171
> > > >
> > > > This will get pushed to the ASF cannonical repo once the VOTE
> succeeds.
> > > > Yay, this is the way GIT works and before someone not familiar with
> GIT
> > > screams that this is not hosted on ASF: This got discussed on the board
> > > level a long time ago (when we did DeltaSpike and CouchDB as the very
> > first
> > > GIT repos at the ASF) and is perfectly fine as all this is based on
> > > cryptographically strong steps.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >
> > > >> Am 14.11.2018 um 09:17 schrieb Mark Struberg
> > <struberg@yahoo.de.INVALID
> > > >:
> > > >>
> > > >> Hi folks!
> > > >>
> > > >> I'm currently preparing the release for commons-pool2-2.6.1
> > > >>
> > > >> So far I did
> > > >>
> > > >> * fix the missing parts in changes.xml
> > > >> * generate + copy the RELEASE_NOTES
> > > >> * run the maven release (after fixing the setup...)
> > > >>
> > > >> The ASF staging repository is at
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > > >>
> > > >> The source zip is at
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > > >> The sha1 of the source-release zip is
> > > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > > >> The sha512 is
> > >
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> > > >>
> > > >> I added my KEY (struberg at apache.org) to our dist KEYS file
> > > >> https://dist.apache.org/repos/dist/release/commons/KEYS
> > > >>
> > > >> I will now continue with the follow up steps and then call an
> official
> > > VOTE.
> > > >>
> > > >> Please let me know if something went wrong so far!
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > >> For additional commands, e-mail: dev-help@commons.apache.org
> > > >>
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 23, 2018 at 11:51 AM Rob Tompkins <ch...@gmail.com> wrote:
>
>
> > On Nov 23, 2018, at 10:51 AM, Phil Steitz <ph...@gmail.com> wrote:
> >
> > On 11/23/18 2:57 AM, Mark Struberg wrote:
> >> should read: This change (putting a new item back to the idle pool) was
> needed to prevent a dead-lock....
> >>
> >> *grabbing a fresh coffee* le
> >
> > I am sorry I did not look carefully enough at this issue before
> reviewing the change. After reviewing the DBCP ticket (OP likely
> unrelated, IMO), I think that the right answer here is WONT_FIX. That
> sounds harsh, but it seems to me that the obvious solution here is for the
> user to set maxIdle to at least 1. What the fix does is effectively that,
> without changing the setting. If waiting threads die or time out while the
> create is happening, there will be an idle instance in the pool and for
> certain one is being put there on the way to getting checked back out. See
> comments on POOL-327.
> >
> > If the consensus is to insert this workaround to enable the pool to
> retain liveness in the use case, it's probably best to use ensureIdle(1,
> false) (see POOL-240). It could be that just moving the call to ensureIdle
> inside destroy would be OK. But as stated above, this breaks the maxIdle
> contract.
> >
> > I see that your original report / use case here is from DBCP, Mark. Was
> it prepared statements or connections that you were trying to limit to 0
> idle? Is there a reason that just using 1 would not work?
>
> Ok holding off on RC3 then from master. Right?
>
I would think that we at least need to documentation added to the code
someplace to help future maintainers.
Are there code changes coming?
Gary
>
> -Rob
>
> >
> > Phil
> >
> >
> >>
> >>> Am 23.11.2018 um 10:49 schrieb Mark Struberg <st...@yahoo.de>:
> >>>
> >>> This change (putting a new item back to the idle pool was needed to
> prevent a dead-pool
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>> .
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Rob Tompkins <ch...@gmail.com>.
> On Nov 23, 2018, at 10:51 AM, Phil Steitz <ph...@gmail.com> wrote:
>
> On 11/23/18 2:57 AM, Mark Struberg wrote:
>> should read: This change (putting a new item back to the idle pool) was needed to prevent a dead-lock....
>>
>> *grabbing a fresh coffee* le
>
> I am sorry I did not look carefully enough at this issue before reviewing the change. After reviewing the DBCP ticket (OP likely unrelated, IMO), I think that the right answer here is WONT_FIX. That sounds harsh, but it seems to me that the obvious solution here is for the user to set maxIdle to at least 1. What the fix does is effectively that, without changing the setting. If waiting threads die or time out while the create is happening, there will be an idle instance in the pool and for certain one is being put there on the way to getting checked back out. See comments on POOL-327.
>
> If the consensus is to insert this workaround to enable the pool to retain liveness in the use case, it's probably best to use ensureIdle(1, false) (see POOL-240). It could be that just moving the call to ensureIdle inside destroy would be OK. But as stated above, this breaks the maxIdle contract.
>
> I see that your original report / use case here is from DBCP, Mark. Was it prepared statements or connections that you were trying to limit to 0 idle? Is there a reason that just using 1 would not work?
Ok holding off on RC3 then from master. Right?
-Rob
>
> Phil
>
>
>>
>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg <st...@yahoo.de>:
>>>
>>> This change (putting a new item back to the idle pool was needed to prevent a dead-pool
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> .
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Phil Steitz <ph...@gmail.com>.
> On Nov 28, 2018, at 9:06 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>
> Yes, not destroying the borrowed object would be an option. I didn't want to go down that route as there are multiple reasons why a borrowed object is not valid anymore.
> E.g. it could be 'consumed', it could be broken, shouldn't be used do to maxUsageTime is over, etc.
Those are good things to worry about but the change I suggested below preserves all of the checks associated with validation and instance state. All it does is effectively recode maxIdle to 1 when it is set to 0 and there are take waiters.
Phil
> That's why I opted for calling create(). But of course, that has other potential issues :/
>
> LieGrue,
> strub
>
>
>> Am 28.11.2018 um 04:21 schrieb Phil Steitz <ph...@gmail.com>:
>>
>> On 11/26/18 1:23 PM, Phil Steitz wrote:
>>>> On 11/26/18 8:29 AM, Phil Steitz wrote:
>>>>> On 11/26/18 6:19 AM, Mark Struberg wrote:
>>>>> Hi Phil!
>>>>
>>>> Let me start by repeating that other than trying to help diagnose bugs and answer user questions, I don't really work on [pool] any more, so I don't really have any standing here. You are the RM, so it is completely up to you and the active Commons committers to decide what to do with the code. So fine to ignore my comments.
>>>>>
>>>>>
>>>>>> I think that the right answer here is WONT_FIX. That sounds harsh, but it seems to me
>>>>>> that the obvious solution here is for the user to set maxIdle to at least 1.
>>>>> I thought about that as well!
>>>>> Setting maxIdle to 1 will make it less likely but a deadlock will STILL happen.
>>>> I am not sure this is right. If maxIdle >0, the fix for POOL-240 (a similar liveness issue) should kick in and work. Each time a validation or passivation failure occurs on return, there is a call to ensureIdle that will create a new instance and add it to the pool if there is capacity to do so.
>>>>> So I fear we really need to tackle this. Stackoverflow and our own bug tracker is full of such reports :(
>>>>
>>>> I see one additional actual report on GKOP (the other linked issue, which should be similarly patched if the consensus is to do this for GOP). The vast majority of the liveness reports that we have gotten over the years in DBCP and pool are just pool exhausted due to failure to return instances.
>>>>
>>>> The workaround violating maxIdle will restore liveness, but is likely the wrong solution here. Again, up to you guys to judge. Note that when you specify maxIdle equal to 1
>>> Crap. Meant 0 there.
>>>> you are telling the pool to destroy all returning instances. To use the pool in this way is silly, IMO. With your patch, new instances are still created for *every* borrow. The pool and all of its machinery is doing nothing other than tracking the number of active instances and making sure life cycle events are fired. If you want the semantics of returning object with threads waiting to be that the returning object is passivated, activated and handed directly to a waiter without every hitting the idle instance pool, that would require rewriting a fair bit of the borrow / return code. It is an interesting idea and would solve the POOL-240 as well.
>>>>
>>>> One final comment. If you stick with something like what is in the code now, you should make sure to passivate the new instance before putting it into the pool. I just noticed that ensureIdle does not do that, which I think is a bug in that method. So if you want to proceed with this fix, I would recommend
>>>>
>>>> 1. Move the ensureIdle activations added in POOL-240 into destroy itself.
>>>> 2. Add passivation to ensureIdle
>>>> 3. Implement corresponding workaround for GKOP
>>
>> Sorry, all. Looking again and thinking a little more, I think the best fix for this is actually to prevent the destroy on return in the first place if there are take waiters. The maxIdle invariant gets violated with the ensureIdle or direct create() fix anyway and just allowing the returning instance to go into the pool avoids the needless destroy / create sequence. A simple way to do this is just to recode maxIdle before the destroy test in returnObject.
>> Instead of
>>
>> final int maxIdleSave = getMaxIdle()
>> explicitly recode it:
>>
>> // If maxIdle is set to 0 and there are take waiters, bump it to 1
>> // to preserve liveness.
>> final int maxIdleSave = idleObjects.hasTakeWaiters() ? Math.max(1,getMaxIdle()) : getMaxIdle();
>>
>> Phil
>>
>>>>
>>>> Phil
>>>>
>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>> Am 23.11.2018 um 16:51 schrieb Phil Steitz<ph...@gmail.com>:
>>>>>>
>>>>>> On 11/23/18 2:57 AM, Mark Struberg wrote:
>>>>>>> should read: This change (putting a new item back to the idle pool) was needed to prevent a dead-lock....
>>>>>>>
>>>>>>> *grabbing a fresh coffee* le
>>>>>> I am sorry I did not look carefully enough at this issue before reviewing the change. After reviewing the DBCP ticket (OP likely unrelated, IMO), I think that the right answer here is WONT_FIX. That sounds harsh, but it seems to me that the obvious solution here is for the user to set maxIdle to at least 1. What the fix does is effectively that, without changing the setting. If waiting threads die or time out while the create is happening, there will be an idle instance in the pool and for certain one is being put there on the way to getting checked back out. See comments on POOL-327.
>>>>>>
>>>>>> If the consensus is to insert this workaround to enable the pool to retain liveness in the use case, it's probably best to use ensureIdle(1, false) (see POOL-240). It could be that just moving the call to ensureIdle inside destroy would be OK. But as stated above, this breaks the maxIdle contract.
>>>>>>
>>>>>> I see that your original report / use case here is from DBCP, Mark. Was it prepared statements or connections that you were trying to limit to 0 idle? Is there a reason that just using 1 would not work?
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>>
>>>>>>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg<st...@yahoo.de>:
>>>>>>>>
>>>>>>>> This change (putting a new item back to the idle pool was needed to prevent a dead-pool
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>>>>>>
>>>>>>>> .
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Yes, not destroying the borrowed object would be an option. I didn't want to go down that route as there are multiple reasons why a borrowed object is not valid anymore.
E.g. it could be 'consumed', it could be broken, shouldn't be used do to maxUsageTime is over, etc.
That's why I opted for calling create(). But of course, that has other potential issues :/
LieGrue,
strub
> Am 28.11.2018 um 04:21 schrieb Phil Steitz <ph...@gmail.com>:
>
> On 11/26/18 1:23 PM, Phil Steitz wrote:
>> On 11/26/18 8:29 AM, Phil Steitz wrote:
>>> On 11/26/18 6:19 AM, Mark Struberg wrote:
>>>> Hi Phil!
>>>
>>> Let me start by repeating that other than trying to help diagnose bugs and answer user questions, I don't really work on [pool] any more, so I don't really have any standing here. You are the RM, so it is completely up to you and the active Commons committers to decide what to do with the code. So fine to ignore my comments.
>>>>
>>>>
>>>>> I think that the right answer here is WONT_FIX. That sounds harsh, but it seems to me
>>>>> that the obvious solution here is for the user to set maxIdle to at least 1.
>>>> I thought about that as well!
>>>> Setting maxIdle to 1 will make it less likely but a deadlock will STILL happen.
>>> I am not sure this is right. If maxIdle >0, the fix for POOL-240 (a similar liveness issue) should kick in and work. Each time a validation or passivation failure occurs on return, there is a call to ensureIdle that will create a new instance and add it to the pool if there is capacity to do so.
>>>> So I fear we really need to tackle this. Stackoverflow and our own bug tracker is full of such reports :(
>>>
>>> I see one additional actual report on GKOP (the other linked issue, which should be similarly patched if the consensus is to do this for GOP). The vast majority of the liveness reports that we have gotten over the years in DBCP and pool are just pool exhausted due to failure to return instances.
>>>
>>> The workaround violating maxIdle will restore liveness, but is likely the wrong solution here. Again, up to you guys to judge. Note that when you specify maxIdle equal to 1
>> Crap. Meant 0 there.
>>> you are telling the pool to destroy all returning instances. To use the pool in this way is silly, IMO. With your patch, new instances are still created for *every* borrow. The pool and all of its machinery is doing nothing other than tracking the number of active instances and making sure life cycle events are fired. If you want the semantics of returning object with threads waiting to be that the returning object is passivated, activated and handed directly to a waiter without every hitting the idle instance pool, that would require rewriting a fair bit of the borrow / return code. It is an interesting idea and would solve the POOL-240 as well.
>>>
>>> One final comment. If you stick with something like what is in the code now, you should make sure to passivate the new instance before putting it into the pool. I just noticed that ensureIdle does not do that, which I think is a bug in that method. So if you want to proceed with this fix, I would recommend
>>>
>>> 1. Move the ensureIdle activations added in POOL-240 into destroy itself.
>>> 2. Add passivation to ensureIdle
>>> 3. Implement corresponding workaround for GKOP
>
> Sorry, all. Looking again and thinking a little more, I think the best fix for this is actually to prevent the destroy on return in the first place if there are take waiters. The maxIdle invariant gets violated with the ensureIdle or direct create() fix anyway and just allowing the returning instance to go into the pool avoids the needless destroy / create sequence. A simple way to do this is just to recode maxIdle before the destroy test in returnObject.
> Instead of
>
> final int maxIdleSave = getMaxIdle()
> explicitly recode it:
>
> // If maxIdle is set to 0 and there are take waiters, bump it to 1
> // to preserve liveness.
> final int maxIdleSave = idleObjects.hasTakeWaiters() ? Math.max(1,getMaxIdle()) : getMaxIdle();
>
> Phil
>
>>>
>>> Phil
>>>
>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>> Am 23.11.2018 um 16:51 schrieb Phil Steitz<ph...@gmail.com>:
>>>>>
>>>>> On 11/23/18 2:57 AM, Mark Struberg wrote:
>>>>>> should read: This change (putting a new item back to the idle pool) was needed to prevent a dead-lock....
>>>>>>
>>>>>> *grabbing a fresh coffee* le
>>>>> I am sorry I did not look carefully enough at this issue before reviewing the change. After reviewing the DBCP ticket (OP likely unrelated, IMO), I think that the right answer here is WONT_FIX. That sounds harsh, but it seems to me that the obvious solution here is for the user to set maxIdle to at least 1. What the fix does is effectively that, without changing the setting. If waiting threads die or time out while the create is happening, there will be an idle instance in the pool and for certain one is being put there on the way to getting checked back out. See comments on POOL-327.
>>>>>
>>>>> If the consensus is to insert this workaround to enable the pool to retain liveness in the use case, it's probably best to use ensureIdle(1, false) (see POOL-240). It could be that just moving the call to ensureIdle inside destroy would be OK. But as stated above, this breaks the maxIdle contract.
>>>>>
>>>>> I see that your original report / use case here is from DBCP, Mark. Was it prepared statements or connections that you were trying to limit to 0 idle? Is there a reason that just using 1 would not work?
>>>>>
>>>>> Phil
>>>>>
>>>>>
>>>>>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg<st...@yahoo.de>:
>>>>>>>
>>>>>>> This change (putting a new item back to the idle pool was needed to prevent a dead-pool
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>>>>>
>>>>>>> .
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>>
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Phil Steitz <ph...@gmail.com>.
On 11/26/18 1:23 PM, Phil Steitz wrote:
> On 11/26/18 8:29 AM, Phil Steitz wrote:
>> On 11/26/18 6:19 AM, Mark Struberg wrote:
>>> Hi Phil!
>>
>> Let me start by repeating that other than trying to help diagnose
>> bugs and answer user questions, I don't really work on [pool] any
>> more, so I don't really have any standing here. You are the RM,
>> so it is completely up to you and the active Commons committers
>> to decide what to do with the code. So fine to ignore my comments.
>>>
>>>
>>>> I think that the right answer here is WONT_FIX. That sounds
>>>> harsh, but it seems to me
>>>> that the obvious solution here is for the user to set maxIdle
>>>> to at least 1.
>>> I thought about that as well!
>>> Setting maxIdle to 1 will make it less likely but a deadlock
>>> will STILL happen.
>> I am not sure this is right. If maxIdle >0, the fix for POOL-240
>> (a similar liveness issue) should kick in and work. Each time a
>> validation or passivation failure occurs on return, there is a
>> call to ensureIdle that will create a new instance and add it to
>> the pool if there is capacity to do so.
>>> So I fear we really need to tackle this. Stackoverflow and our
>>> own bug tracker is full of such reports :(
>>
>> I see one additional actual report on GKOP (the other linked
>> issue, which should be similarly patched if the consensus is to
>> do this for GOP). The vast majority of the liveness reports that
>> we have gotten over the years in DBCP and pool are just pool
>> exhausted due to failure to return instances.
>>
>> The workaround violating maxIdle will restore liveness, but is
>> likely the wrong solution here. Again, up to you guys to judge.
>> Note that when you specify maxIdle equal to 1
> Crap. Meant 0 there.
>> you are telling the pool to destroy all returning instances. To
>> use the pool in this way is silly, IMO. With your patch, new
>> instances are still created for *every* borrow. The pool and all
>> of its machinery is doing nothing other than tracking the number
>> of active instances and making sure life cycle events are fired.
>> If you want the semantics of returning object with threads
>> waiting to be that the returning object is passivated, activated
>> and handed directly to a waiter without every hitting the idle
>> instance pool, that would require rewriting a fair bit of the
>> borrow / return code. It is an interesting idea and would solve
>> the POOL-240 as well.
>>
>> One final comment. If you stick with something like what is in
>> the code now, you should make sure to passivate the new instance
>> before putting it into the pool. I just noticed that ensureIdle
>> does not do that, which I think is a bug in that method. So if
>> you want to proceed with this fix, I would recommend
>>
>> 1. Move the ensureIdle activations added in POOL-240 into
>> destroy itself.
>> 2. Add passivation to ensureIdle
>> 3. Implement corresponding workaround for GKOP
Sorry, all. Looking again and thinking a little more, I think the
best fix for this is actually to prevent the destroy on return in
the first place if there are take waiters. The maxIdle invariant
gets violated with the ensureIdle or direct create() fix anyway and
just allowing the returning instance to go into the pool avoids the
needless destroy / create sequence. A simple way to do this is just
to recode maxIdle before the destroy test in returnObject.
Instead of
final int maxIdleSave = getMaxIdle()
explicitly recode it:
// If maxIdle is set to 0 and there are take waiters, bump it to 1
// to preserve liveness.
final int maxIdleSave = idleObjects.hasTakeWaiters() ?
Math.max(1,getMaxIdle()) : getMaxIdle();
Phil
>>
>> Phil
>>
>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>> Am 23.11.2018 um 16:51 schrieb Phil Steitz<ph...@gmail.com>:
>>>>
>>>> On 11/23/18 2:57 AM, Mark Struberg wrote:
>>>>> should read: This change (putting a new item back to the idle
>>>>> pool) was needed to prevent a dead-lock....
>>>>>
>>>>> *grabbing a fresh coffee* le
>>>> I am sorry I did not look carefully enough at this issue before
>>>> reviewing the change. After reviewing the DBCP ticket (OP
>>>> likely unrelated, IMO), I think that the right answer here is
>>>> WONT_FIX. That sounds harsh, but it seems to me that the
>>>> obvious solution here is for the user to set maxIdle to at
>>>> least 1. What the fix does is effectively that, without
>>>> changing the setting. If waiting threads die or time out while
>>>> the create is happening, there will be an idle instance in the
>>>> pool and for certain one is being put there on the way to
>>>> getting checked back out. See comments on POOL-327.
>>>>
>>>> If the consensus is to insert this workaround to enable the
>>>> pool to retain liveness in the use case, it's probably best to
>>>> use ensureIdle(1, false) (see POOL-240). It could be that just
>>>> moving the call to ensureIdle inside destroy would be OK. But
>>>> as stated above, this breaks the maxIdle contract.
>>>>
>>>> I see that your original report / use case here is from DBCP,
>>>> Mark. Was it prepared statements or connections that you were
>>>> trying to limit to 0 idle? Is there a reason that just using 1
>>>> would not work?
>>>>
>>>> Phil
>>>>
>>>>
>>>>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg<st...@yahoo.de>:
>>>>>>
>>>>>> This change (putting a new item back to the idle pool was
>>>>>> needed to prevent a dead-pool
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>>>>
>>>>>> .
>>>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Phil Steitz <ph...@gmail.com>.
On 11/26/18 8:29 AM, Phil Steitz wrote:
> On 11/26/18 6:19 AM, Mark Struberg wrote:
>> Hi Phil!
>
> Let me start by repeating that other than trying to help diagnose
> bugs and answer user questions, I don't really work on [pool] any
> more, so I don't really have any standing here. You are the RM,
> so it is completely up to you and the active Commons committers to
> decide what to do with the code. So fine to ignore my comments.
>>
>>
>>> I think that the right answer here is WONT_FIX. That sounds
>>> harsh, but it seems to me
>>> that the obvious solution here is for the user to set maxIdle to
>>> at least 1.
>> I thought about that as well!
>> Setting maxIdle to 1 will make it less likely but a deadlock will
>> STILL happen.
> I am not sure this is right. If maxIdle >0, the fix for POOL-240
> (a similar liveness issue) should kick in and work. Each time a
> validation or passivation failure occurs on return, there is a
> call to ensureIdle that will create a new instance and add it to
> the pool if there is capacity to do so.
>> So I fear we really need to tackle this. Stackoverflow and our
>> own bug tracker is full of such reports :(
>
> I see one additional actual report on GKOP (the other linked
> issue, which should be similarly patched if the consensus is to do
> this for GOP). The vast majority of the liveness reports that we
> have gotten over the years in DBCP and pool are just pool
> exhausted due to failure to return instances.
>
> The workaround violating maxIdle will restore liveness, but is
> likely the wrong solution here. Again, up to you guys to judge.
> Note that when you specify maxIdle equal to 1
Crap. Meant 0 there.
> you are telling the pool to destroy all returning instances. To
> use the pool in this way is silly, IMO. With your patch, new
> instances are still created for *every* borrow. The pool and all
> of its machinery is doing nothing other than tracking the number
> of active instances and making sure life cycle events are fired.
> If you want the semantics of returning object with threads waiting
> to be that the returning object is passivated, activated and
> handed directly to a waiter without every hitting the idle
> instance pool, that would require rewriting a fair bit of the
> borrow / return code. It is an interesting idea and would solve
> the POOL-240 as well.
>
> One final comment. If you stick with something like what is in
> the code now, you should make sure to passivate the new instance
> before putting it into the pool. I just noticed that ensureIdle
> does not do that, which I think is a bug in that method. So if
> you want to proceed with this fix, I would recommend
>
> 1. Move the ensureIdle activations added in POOL-240 into destroy
> itself.
> 2. Add passivation to ensureIdle
> 3. Implement corresponding workaround for GKOP
>
> Phil
>
>
>> LieGrue,
>> strub
>>
>>
>>> Am 23.11.2018 um 16:51 schrieb Phil Steitz<ph...@gmail.com>:
>>>
>>> On 11/23/18 2:57 AM, Mark Struberg wrote:
>>>> should read: This change (putting a new item back to the idle
>>>> pool) was needed to prevent a dead-lock....
>>>>
>>>> *grabbing a fresh coffee* le
>>> I am sorry I did not look carefully enough at this issue before
>>> reviewing the change. After reviewing the DBCP ticket (OP
>>> likely unrelated, IMO), I think that the right answer here is
>>> WONT_FIX. That sounds harsh, but it seems to me that the obvious
>>> solution here is for the user to set maxIdle to at least 1.
>>> What the fix does is effectively that, without changing the
>>> setting. If waiting threads die or time out while the create is
>>> happening, there will be an idle instance in the pool and for
>>> certain one is being put there on the way to getting checked
>>> back out. See comments on POOL-327.
>>>
>>> If the consensus is to insert this workaround to enable the pool
>>> to retain liveness in the use case, it's probably best to use
>>> ensureIdle(1, false) (see POOL-240). It could be that just
>>> moving the call to ensureIdle inside destroy would be OK. But
>>> as stated above, this breaks the maxIdle contract.
>>>
>>> I see that your original report / use case here is from DBCP,
>>> Mark. Was it prepared statements or connections that you were
>>> trying to limit to 0 idle? Is there a reason that just using 1
>>> would not work?
>>>
>>> Phil
>>>
>>>
>>>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg<st...@yahoo.de>:
>>>>>
>>>>> This change (putting a new item back to the idle pool was
>>>>> needed to prevent a dead-pool
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>>>
>>>>> .
>>>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail:dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Phil Steitz <ph...@gmail.com>.
On 11/26/18 8:29 AM, Phil Steitz wrote:
> On 11/26/18 6:19 AM, Mark Struberg wrote:
>> Hi Phil!
>
> Let me start by repeating that other than trying to help diagnose
> bugs and answer user questions, I don't really work on [pool] any
> more, so I don't really have any standing here. You are the RM,
> so it is completely up to you and the active Commons committers to
> decide what to do with the code. So fine to ignore my comments.
>>
>>
>>> I think that the right answer here is WONT_FIX. That sounds
>>> harsh, but it seems to me
>>> that the obvious solution here is for the user to set maxIdle to
>>> at least 1.
>> I thought about that as well!
>> Setting maxIdle to 1 will make it less likely but a deadlock will
>> STILL happen.
> I am not sure this is right. If maxIdle >0, the fix for POOL-240
> (a similar liveness issue) should kick in and work. Each time a
> validation or passivation failure occurs on return, there is a
> call to ensureIdle that will create a new instance and add it to
> the pool if there is capacity to do so.
>> So I fear we really need to tackle this. Stackoverflow and our
>> own bug tracker is full of such reports :(
>
> I see one additional actual report on GKOP (the other linked
> issue, which should be similarly patched if the consensus is to do
> this for GOP). The vast majority of the liveness reports that we
> have gotten over the years in DBCP and pool are just pool
> exhausted due to failure to return instances.
>
> The workaround violating maxIdle will restore liveness, but is
> likely the wrong solution here. Again, up to you guys to judge.
> Note that when you specify maxIdle equal to 1 you are telling the
> pool to destroy all returning instances. To use the pool in this
> way is silly, IMO. With your patch, new instances are still
> created for *every* borrow. The pool and all of its machinery is
> doing nothing other than tracking the number of active instances
> and making sure life cycle events are fired. If you want the
> semantics of returning object with threads waiting to be that the
> returning object is passivated, activated and handed directly to a
> waiter without every hitting the idle instance pool, that would
> require rewriting a fair bit of the borrow / return code. It is
> an interesting idea and would solve the POOL-240 as well.
>
> One final comment. If you stick with something like what is in
> the code now, you should make sure to passivate the new instance
> before putting it into the pool. I just noticed that ensureIdle
> does not do that, which I think is a bug in that method. So if
> you want to proceed with this fix, I would recommend
>
> 1. Move the ensureIdle activations added in POOL-240 into destroy
> itself.
> 2. Add passivation to ensureIdle
Sorry, looks to me like this is not actually necessary. So I take
back my comment that this is a bug in ensureIdle.
> 3. Implement corresponding workaround for GKOP
>
> Phil
>
>
>> LieGrue,
>> strub
>>
>>
>>> Am 23.11.2018 um 16:51 schrieb Phil Steitz<ph...@gmail.com>:
>>>
>>> On 11/23/18 2:57 AM, Mark Struberg wrote:
>>>> should read: This change (putting a new item back to the idle
>>>> pool) was needed to prevent a dead-lock....
>>>>
>>>> *grabbing a fresh coffee* le
>>> I am sorry I did not look carefully enough at this issue before
>>> reviewing the change. After reviewing the DBCP ticket (OP
>>> likely unrelated, IMO), I think that the right answer here is
>>> WONT_FIX. That sounds harsh, but it seems to me that the obvious
>>> solution here is for the user to set maxIdle to at least 1.
>>> What the fix does is effectively that, without changing the
>>> setting. If waiting threads die or time out while the create is
>>> happening, there will be an idle instance in the pool and for
>>> certain one is being put there on the way to getting checked
>>> back out. See comments on POOL-327.
>>>
>>> If the consensus is to insert this workaround to enable the pool
>>> to retain liveness in the use case, it's probably best to use
>>> ensureIdle(1, false) (see POOL-240). It could be that just
>>> moving the call to ensureIdle inside destroy would be OK. But
>>> as stated above, this breaks the maxIdle contract.
>>>
>>> I see that your original report / use case here is from DBCP,
>>> Mark. Was it prepared statements or connections that you were
>>> trying to limit to 0 idle? Is there a reason that just using 1
>>> would not work?
>>>
>>> Phil
>>>
>>>
>>>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg<st...@yahoo.de>:
>>>>>
>>>>> This change (putting a new item back to the idle pool was
>>>>> needed to prevent a dead-pool
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>>>
>>>>> .
>>>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail:dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Phil Steitz <ph...@gmail.com>.
On 11/26/18 6:19 AM, Mark Struberg wrote:
> Hi Phil!
Let me start by repeating that other than trying to help diagnose
bugs and answer user questions, I don't really work on [pool] any
more, so I don't really have any standing here. You are the RM, so
it is completely up to you and the active Commons committers to
decide what to do with the code. So fine to ignore my comments.
>
>
>> I think that the right answer here is WONT_FIX. That sounds harsh, but it seems to me
>> that the obvious solution here is for the user to set maxIdle to at least 1.
> I thought about that as well!
> Setting maxIdle to 1 will make it less likely but a deadlock will STILL happen.
I am not sure this is right. If maxIdle >0, the fix for POOL-240 (a
similar liveness issue) should kick in and work. Each time a
validation or passivation failure occurs on return, there is a call
to ensureIdle that will create a new instance and add it to the pool
if there is capacity to do so.
> So I fear we really need to tackle this. Stackoverflow and our own bug tracker is full of such reports :(
I see one additional actual report on GKOP (the other linked issue,
which should be similarly patched if the consensus is to do this for
GOP). The vast majority of the liveness reports that we have gotten
over the years in DBCP and pool are just pool exhausted due to
failure to return instances.
The workaround violating maxIdle will restore liveness, but is
likely the wrong solution here. Again, up to you guys to judge.
Note that when you specify maxIdle equal to 1 you are telling the
pool to destroy all returning instances. To use the pool in this
way is silly, IMO. With your patch, new instances are still created
for *every* borrow. The pool and all of its machinery is doing
nothing other than tracking the number of active instances and
making sure life cycle events are fired. If you want the semantics
of returning object with threads waiting to be that the returning
object is passivated, activated and handed directly to a waiter
without every hitting the idle instance pool, that would require
rewriting a fair bit of the borrow / return code. It is an
interesting idea and would solve the POOL-240 as well.
One final comment. If you stick with something like what is in the
code now, you should make sure to passivate the new instance before
putting it into the pool. I just noticed that ensureIdle does not
do that, which I think is a bug in that method. So if you want to
proceed with this fix, I would recommend
1. Move the ensureIdle activations added in POOL-240 into destroy
itself.
2. Add passivation to ensureIdle
3. Implement corresponding workaround for GKOP
Phil
> LieGrue,
> strub
>
>
>> Am 23.11.2018 um 16:51 schrieb Phil Steitz<ph...@gmail.com>:
>>
>> On 11/23/18 2:57 AM, Mark Struberg wrote:
>>> should read: This change (putting a new item back to the idle pool) was needed to prevent a dead-lock....
>>>
>>> *grabbing a fresh coffee* le
>> I am sorry I did not look carefully enough at this issue before reviewing the change. After reviewing the DBCP ticket (OP likely unrelated, IMO), I think that the right answer here is WONT_FIX. That sounds harsh, but it seems to me that the obvious solution here is for the user to set maxIdle to at least 1. What the fix does is effectively that, without changing the setting. If waiting threads die or time out while the create is happening, there will be an idle instance in the pool and for certain one is being put there on the way to getting checked back out. See comments on POOL-327.
>>
>> If the consensus is to insert this workaround to enable the pool to retain liveness in the use case, it's probably best to use ensureIdle(1, false) (see POOL-240). It could be that just moving the call to ensureIdle inside destroy would be OK. But as stated above, this breaks the maxIdle contract.
>>
>> I see that your original report / use case here is from DBCP, Mark. Was it prepared statements or connections that you were trying to limit to 0 idle? Is there a reason that just using 1 would not work?
>>
>> Phil
>>
>>
>>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg<st...@yahoo.de>:
>>>>
>>>> This change (putting a new item back to the idle pool was needed to prevent a dead-pool
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail:dev-help@commons.apache.org
>>>>
>>>> .
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail:dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:dev-unsubscribe@commons.apache.org
> For additional commands, e-mail:dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Hi Phil!
> I think that the right answer here is WONT_FIX. That sounds harsh, but it seems to me
> that the obvious solution here is for the user to set maxIdle to at least 1.
I thought about that as well!
Setting maxIdle to 1 will make it less likely but a deadlock will STILL happen.
So I fear we really need to tackle this. Stackoverflow and our own bug tracker is full of such reports :(
LieGrue,
strub
> Am 23.11.2018 um 16:51 schrieb Phil Steitz <ph...@gmail.com>:
>
> On 11/23/18 2:57 AM, Mark Struberg wrote:
>> should read: This change (putting a new item back to the idle pool) was needed to prevent a dead-lock....
>>
>> *grabbing a fresh coffee* le
>
> I am sorry I did not look carefully enough at this issue before reviewing the change. After reviewing the DBCP ticket (OP likely unrelated, IMO), I think that the right answer here is WONT_FIX. That sounds harsh, but it seems to me that the obvious solution here is for the user to set maxIdle to at least 1. What the fix does is effectively that, without changing the setting. If waiting threads die or time out while the create is happening, there will be an idle instance in the pool and for certain one is being put there on the way to getting checked back out. See comments on POOL-327.
>
> If the consensus is to insert this workaround to enable the pool to retain liveness in the use case, it's probably best to use ensureIdle(1, false) (see POOL-240). It could be that just moving the call to ensureIdle inside destroy would be OK. But as stated above, this breaks the maxIdle contract.
>
> I see that your original report / use case here is from DBCP, Mark. Was it prepared statements or connections that you were trying to limit to 0 idle? Is there a reason that just using 1 would not work?
>
> Phil
>
>
>>
>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg <st...@yahoo.de>:
>>>
>>> This change (putting a new item back to the idle pool was needed to prevent a dead-pool
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> .
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Phil Steitz <ph...@gmail.com>.
On 11/23/18 2:57 AM, Mark Struberg wrote:
> should read: This change (putting a new item back to the idle pool) was needed to prevent a dead-lock....
>
> *grabbing a fresh coffee* le
I am sorry I did not look carefully enough at this issue before
reviewing the change. After reviewing the DBCP ticket (OP likely
unrelated, IMO), I think that the right answer here is WONT_FIX.
That sounds harsh, but it seems to me that the obvious solution here
is for the user to set maxIdle to at least 1. What the fix does is
effectively that, without changing the setting. If waiting threads
die or time out while the create is happening, there will be an idle
instance in the pool and for certain one is being put there on the
way to getting checked back out. See comments on POOL-327.
If the consensus is to insert this workaround to enable the pool to
retain liveness in the use case, it's probably best to use
ensureIdle(1, false) (see POOL-240). It could be that just moving
the call to ensureIdle inside destroy would be OK. But as stated
above, this breaks the maxIdle contract.
I see that your original report / use case here is from DBCP, Mark.
Was it prepared statements or connections that you were trying to
limit to 0 idle? Is there a reason that just using 1 would not work?
Phil
>
>> Am 23.11.2018 um 10:49 schrieb Mark Struberg <st...@yahoo.de>:
>>
>> This change (putting a new item back to the idle pool was needed to prevent a dead-pool
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> .
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
I think we still need to address what happens if null gets returned in create().
This was something I missed.
Not sure if it got addressed in the meantime?
LieGrue,
strub
> Am 26.11.2018 um 14:26 schrieb Rob Tompkins <ch...@gmail.com>:
>
>
>
>> On Nov 26, 2018, at 8:16 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>>
>> Hi Gary!
>>
>> I've added multi-line comments in the middle of code blocks I touched.
>> e.g. https://github.com/apache/commons-pool/blob/016a1f67263fe1cde1d910dc7002d972811951c5/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java#L919
>>
>> I also tried to write extensive commit comments.
>
> Sounds good. I’ll try to get to starting the release today.
>
> -Rob
>
>>
>> LieGrue,
>> strub
>>
>>> Am 23.11.2018 um 16:18 schrieb Gary Gregory <ga...@gmail.com>:
>>>
>>> On Fri, Nov 23, 2018 at 2:57 AM Mark Struberg <st...@yahoo.de.invalid>
>>> wrote:
>>>
>>>> should read: This change (putting a new item back to the idle pool) was
>>>> needed to prevent a dead-lock....
>>>>
>>>> *grabbing a fresh coffee*
>>>>
>>>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg <st...@yahoo.de>:
>>>>>
>>>>> This change (putting a new item back to the idle pool was needed to
>>>> prevent a dead-pool
>>>>
>>>
>>> Hi Mark,
>>>
>>> Would you mind adding some comments to the code to help future maintainers?
>>>
>>> Gary (currently sipping coffee)
>>>
>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Rob Tompkins <ch...@gmail.com>.
> On Nov 26, 2018, at 8:16 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>
> Hi Gary!
>
> I've added multi-line comments in the middle of code blocks I touched.
> e.g. https://github.com/apache/commons-pool/blob/016a1f67263fe1cde1d910dc7002d972811951c5/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java#L919
>
> I also tried to write extensive commit comments.
Sounds good. I’ll try to get to starting the release today.
-Rob
>
> LieGrue,
> strub
>
>> Am 23.11.2018 um 16:18 schrieb Gary Gregory <ga...@gmail.com>:
>>
>> On Fri, Nov 23, 2018 at 2:57 AM Mark Struberg <st...@yahoo.de.invalid>
>> wrote:
>>
>>> should read: This change (putting a new item back to the idle pool) was
>>> needed to prevent a dead-lock....
>>>
>>> *grabbing a fresh coffee*
>>>
>>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg <st...@yahoo.de>:
>>>>
>>>> This change (putting a new item back to the idle pool was needed to
>>> prevent a dead-pool
>>>
>>
>> Hi Mark,
>>
>> Would you mind adding some comments to the code to help future maintainers?
>>
>> Gary (currently sipping coffee)
>>
>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Hi Gary!
I've added multi-line comments in the middle of code blocks I touched.
e.g. https://github.com/apache/commons-pool/blob/016a1f67263fe1cde1d910dc7002d972811951c5/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java#L919
I also tried to write extensive commit comments.
LieGrue,
strub
> Am 23.11.2018 um 16:18 schrieb Gary Gregory <ga...@gmail.com>:
>
> On Fri, Nov 23, 2018 at 2:57 AM Mark Struberg <st...@yahoo.de.invalid>
> wrote:
>
>> should read: This change (putting a new item back to the idle pool) was
>> needed to prevent a dead-lock....
>>
>> *grabbing a fresh coffee*
>>
>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg <st...@yahoo.de>:
>>>
>>> This change (putting a new item back to the idle pool was needed to
>> prevent a dead-pool
>>
>
> Hi Mark,
>
> Would you mind adding some comments to the code to help future maintainers?
>
> Gary (currently sipping coffee)
>
>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 23, 2018 at 2:57 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> should read: This change (putting a new item back to the idle pool) was
> needed to prevent a dead-lock....
>
> *grabbing a fresh coffee*
>
> > Am 23.11.2018 um 10:49 schrieb Mark Struberg <st...@yahoo.de>:
> >
> > This change (putting a new item back to the idle pool was needed to
> prevent a dead-pool
>
Hi Mark,
Would you mind adding some comments to the code to help future maintainers?
Gary (currently sipping coffee)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
should read: This change (putting a new item back to the idle pool) was needed to prevent a dead-lock....
*grabbing a fresh coffee*
> Am 23.11.2018 um 10:49 schrieb Mark Struberg <st...@yahoo.de>:
>
> This change (putting a new item back to the idle pool was needed to prevent a dead-pool
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
In Nexus, I see
https://repository.apache.org/content/repositories/orgapachecommons-1396
owned by struberg. Where are we on this?
Gary
On Fri, Nov 23, 2018 at 4:58 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> To clarify why this change was done:
> This change (putting a new item back to the idle pool was needed to
> prevent a dead-pool which caused an efective shutdown of all the server by
> staling the pool in various cases.
>
> This solved my problem. I created test to make sure to not introduce new
> ones. But the code is way too much organically grown to be 100% sure. it
> probably need a clean rewrite.
> I had another solution which created too many pooled instances. My hope
> was that the create() method will prevent exactly that! If this doesn't
> work.
> Yes, we need to have a null-check on the return param of create and deal
> with that case. But if we still get too many idle objects, then create() is
> broken as well, isn't?
>
> LieGrue,
> strub
>
>
>
> > Am 19.11.2018 um 23:34 schrieb Gary Gregory <ga...@gmail.com>:
> >
> >
> > diff --git
> > a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> > b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> > index 0575f7e..6d81dbc 100644
> > --- a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> > +++ b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> > @@ -920,8 +920,7 @@
> > // In case there are already threads waiting on something in
> > the pool
> > // (e.g. idleObjects.takeFirst(); then we need to provide
> them
> > a fresh instance.
> > // Otherwise they will be stuck forever (or until timeout)
> > - PooledObject<T> freshPooled = create();
> > - idleObjects.put(freshPooled);
> > + addObject();
> > }
> > }
> >
> > But causes a failure:
> >
> > [INFO] Running org.apache.commons.pool2.impl.TestAbandonedObjectPool
> > [ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> > 12.253 s <<< FAILURE! - in
> > org.apache.commons.pool2.impl.TestAbandonedObjectPool
> > [ERROR]
> >
> testAbandonedInvalidate(org.apache.commons.pool2.impl.TestAbandonedObjectPool)
> > Time elapsed: 3.668 s <<< FAILURE!
> > java.lang.AssertionError: expected:<5> but was:<4>
> > at
> >
> org.apache.commons.pool2.impl.TestAbandonedObjectPool.testAbandonedInvalidate(TestAbandonedObjectPool.java:202)
> >
> > Maybe this is due to my busy CPU, not sure.
> >
> > Gary
> >
> >
> >>
> >> Phil
> >>
> >> On 11/19/18 2:31 PM, Gary Gregory wrote:
> >>> A unit test? Yes please! :-)
> >>>
> >>> Gary
> >>>
> >>> On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg
> <struberg@yahoo.de.invalid
> >>>
> >>> wrote:
> >>>
> >>>> +1 for the null check.
> >>>>
> >>>> Do you want to re-open the ticket and create a patch?
> >>>>
> >>>> I've created a unit test which proves my original problem with the
> >>>> dead-lock.
> >>>> So any improvement should be rather on the safe side from here on.
> >>>>
> >>>>
> >>>> Regarding the RC: this is really not needed anymore when working with
> >> GIT
> >>>> as nothing gets pushed/released to the main repository! See the config
> >>>> changes I did to the maven-release-plugin.
> >>>>
> >>>> txs and LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>
> >>>>> Am 19.11.2018 um 16:43 schrieb Phil Steitz <ph...@gmail.com>:
> >>>>>
> >>>>> On 11/19/18 8:19 AM, Gary Gregory wrote:
> >>>>>> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins <ch...@gmail.com>
> >>>> wrote:
> >>>>>>> I’d be happy to roll the release if we get master to where you want
> >>>> it.
> >>>>>> IMO, we should integrate the recent PR I mentioned and roll RC3.
> Note
> >>>> that this vote subject thread did not contain an RC number. Sticking
> to
> >> the
> >>>> usual process would be less troublesome IMO.
> >>>>> I have not had a chance to fully review and am not really active in
> >>>> [pool] any more, but I did notice that the fix for POOL-356 is
> missing a
> >>>> null check between these two added statements:
> >>>>> PooledObject<T> freshPooled = create();
> >>>>> idleObjects.put(freshPooled);
> >>>>>
> >>>>> create() can return null and while in general it won't in this
> >>>> activation context, given the lack of sync control, it is possible
> that
> >> a
> >>>> return hits between the if test and execution resulting in no capacity
> >> to
> >>>> create.
> >>>>> I also notice some system.outs made it into the test code in one of
> the
> >>>> commits related to POOL-340.
> >>>>> Phil
> >>>>>> Gary
> >>>>>>
> >>>>>>
> >>>>>>> Cheers,
> >>>>>>> -Rob
> >>>>>>>
> >>>>>>>> On Nov 19, 2018, at 7:18 AM, Mark Struberg
> >> <struberg@yahoo.de.INVALID
> >>>>>>> wrote:
> >>>>>>>> Oki, I now see what you mean.
> >>>>>>>>
> >>>>>>>> We actually have 3 source zips now.
> >>>>>>>>
> >>>>>>>> .src.zip
> >>>>>>>> .source-release.zip
> >>>>>>>> src.jar
> >>>>>>>>
> >>>>>>>> That's a mess.
> >>>>>>>>
> >>>>>>>> There should only be 2:
> >>>>>>>> * source-release.zip is the official ASF packages whole build
> >> sources.
> >>>>>>> This includes the pom, build structure etc.
> >>>>>>>> * src.jar is the sources which are automatically downloaded by the
> >>>> IDEs
> >>>>>>> for debugging purpose.
> >>>>>>>> We have both of them because commons-pool2 is a single-module
> >> project.
> >>>>>>>> And yes, we need both of them. What we do not need is the
> src.zip. I
> >>>>>>> have no clue yet where this comes from but it shouldn't be here.
> >>>>>>>> The good news:
> >>>>>>>> By leveraging native GIT we now can simply a.) drop the maven
> >> stating
> >>>>>>> repo in repository.a.o and b.) drop the release branch and tag from
> >> my
> >>>>>>> github account and re-roll the release without any weird RC hacks.
> >>>>>>>> Will do that,
> >>>>>>>> * fix the maven setup
> >>>>>>>> * happy to also include the new ticket
> >>>>>>>> * re-roll the release this afternoon.
> >>>>>>>>
> >>>>>>>> LieGrue,
> >>>>>>>> strub
> >>>>>>>>
> >>>>>>>>> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
> >>>>>>> rmannibucau@gmail.com>:
> >>>>>>>>> Le ven. 16 nov. 2018 22:54, Gary Gregory <garydgregory@gmail.com
> >
> >> a
> >>>>>>> écrit :
> >>>>>>>>>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> >>>>>>> rmannibucau@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Le ven. 16 nov. 2018 21:23, Gary Gregory <
> garydgregory@gmail.com
> >>>
> >>>> a
> >>>>>>>>>> écrit
> >>>>>>>>>>> :
> >>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> >>>>>>>>>> <struberg@yahoo.de.invalid
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Oki, now the full VOTE text!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'd like to call a VOTE on releasing Apache Commons pool2
> 2.6.1
> >>>>>>>>>>>>> The release was run with JDK-1.7 to ensure Java7
> compatibility.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The ASF staging repository is at
> >>>>>>>>>>>>>
> >>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>>>>>>>>>>> The source zip is at
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>>>>>>>>>>>> The sha1 of the source-release zip is
> >>>>>>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>>>>>>>>>>>> The sha512 is
> >>>>>>>>>>>>>
> >>>>
> >>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>>>>>>>>>> For me:
> >>>>>>>>>>>>
> >>>>>>>>>>>> $ sha512sum commons-pool2-2.6.1-src.zip
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>
> >>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> >>>>>>>>>>>> *commons-pool2-2.6.1-src.zip
> >>>>>>>>>>>>
> >>>>>>>>>>>> Which is not what you list above. Please advise.
> >>>>>>>>>>>>
> >>>>>>>>>>> Src vs source-release?
> >>>>>>>>>>>
> >>>>>>>>>> That's the problem with inventing a new release process... why
> do
> >> we
> >>>>>>> have
> >>>>>>>>>> BOTH:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> >>>>>>>>>> AND
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> >>>>>>>>>> And more importantly why are they _different_? Which one will be
> >>>> used
> >>>>>>> in
> >>>>>>>>>> the dist/release area?
> >>>>>>>>>>
> >>>>>>>>> Looks like pool didnt do its homework and kept the old assembly
> >>>> (src),
> >>>>>>>>> source-release comes from the parent and is likely the one to
> keep
> >>>> IMHO
> >>>>>>>>>
> >>>>>>>>>> Gary
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Gary
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS
> file
> >>>>>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I've created the release in a GIT manner and pushed the
> >> according
> >>>>>>>>>>> changes
> >>>>>>>>>>>>> to my ASF-linked github repo
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >>>>>>>>>>>>> the sha1 of the commit is
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>
> >>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>>>>>>>>>>>> the tag is
> >>>>>>>>>>>>>
> >>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >>>>>>>>>>>>> c910171
> >>>>>>>>>>>>> <
> >>>>
> >>
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> >>>>>>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
> >>>>>>>>>> succeeds.
> >>>>>>>>>>>>> Site will be updated once the release has passed.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Please VOTE:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [+1] go ship it!
> >>>>>>>>>>>>> [+0] meh, I don't care
> >>>>>>>>>>>>> [-1] stop there is a ${showstopper} (that means something
> >>>>>>> _important_
> >>>>>>>>>>> is
> >>>>>>>>>>>>> missing!)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Here is my own +1
> >>>>>>>>>>>>> checked:
> >>>>>>>>>>>>> * signature
> >>>>>>>>>>>>> * hashes
> >>>>>>>>>>>>> * LICENSE
> >>>>>>>>>>>>> * NOTICE
> >>>>>>>>>>>>> * rat
> >>>>>>>>>>>>> * builds fine with various JDKs
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>>> strub
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
> >>>>>>>>>>> <struberg@yahoo.de.INVALID
> >>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> PS: I've created the release in a GIT manner and pushed the
> >>>>>>>>>> according
> >>>>>>>>>>>>> changes to my ASF-linked github repo
> >>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >>>>>>>>>>>>>> the sha1 of the commit is
> >>>>>>>>>>>>>>
> >>>>
> >>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>>>>>>>>>>>>> the tag is
> >>>>>>>>>>>>>>
> >>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >>>>>>>>>>>>>> c910171
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This will get pushed to the ASF cannonical repo once the
> VOTE
> >>>>>>>>>>> succeeds.
> >>>>>>>>>>>>>> Yay, this is the way GIT works and before someone not
> familiar
> >>>> with
> >>>>>>>>>>> GIT
> >>>>>>>>>>>>> screams that this is not hosted on ASF: This got discussed on
> >> the
> >>>>>>>>>> board
> >>>>>>>>>>>>> level a long time ago (when we did DeltaSpike and CouchDB as
> >> the
> >>>>>>> very
> >>>>>>>>>>>> first
> >>>>>>>>>>>>> GIT repos at the ASF) and is perfectly fine as all this is
> >> based
> >>>> on
> >>>>>>>>>>>>> cryptographically strong steps.
> >>>>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>>>> strub
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
> >>>>>>>>>>>> <struberg@yahoo.de.INVALID
> >>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>> Hi folks!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So far I did
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> * fix the missing parts in changes.xml
> >>>>>>>>>>>>>>> * generate + copy the RELEASE_NOTES
> >>>>>>>>>>>>>>> * run the maven release (after fixing the setup...)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The ASF staging repository is at
> >>>>>>>>>>>>>>>
> >>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>>>>>>>>>>>>> The source zip is at
> >>>>>>>>>>>>>>>
> >>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>>>>>>>>>>>>>> The sha1 of the source-release zip is
> >>>>>>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>>>>>>>>>>>>>> The sha512 is
> >>>>
> >>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>>>>>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS
> >> file
> >>>>>>>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I will now continue with the follow up steps and then call
> an
> >>>>>>>>>>> official
> >>>>>>>>>>>>> VOTE.
> >>>>>>>>>>>>>>> Please let me know if something went wrong so far!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>>>>> strub
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
To clarify why this change was done:
This change (putting a new item back to the idle pool was needed to prevent a dead-pool which caused an efective shutdown of all the server by staling the pool in various cases.
This solved my problem. I created test to make sure to not introduce new ones. But the code is way too much organically grown to be 100% sure. it probably need a clean rewrite.
I had another solution which created too many pooled instances. My hope was that the create() method will prevent exactly that! If this doesn't work.
Yes, we need to have a null-check on the return param of create and deal with that case. But if we still get too many idle objects, then create() is broken as well, isn't?
LieGrue,
strub
> Am 19.11.2018 um 23:34 schrieb Gary Gregory <ga...@gmail.com>:
>
>
> diff --git
> a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> index 0575f7e..6d81dbc 100644
> --- a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> +++ b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> @@ -920,8 +920,7 @@
> // In case there are already threads waiting on something in
> the pool
> // (e.g. idleObjects.takeFirst(); then we need to provide them
> a fresh instance.
> // Otherwise they will be stuck forever (or until timeout)
> - PooledObject<T> freshPooled = create();
> - idleObjects.put(freshPooled);
> + addObject();
> }
> }
>
> But causes a failure:
>
> [INFO] Running org.apache.commons.pool2.impl.TestAbandonedObjectPool
> [ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 12.253 s <<< FAILURE! - in
> org.apache.commons.pool2.impl.TestAbandonedObjectPool
> [ERROR]
> testAbandonedInvalidate(org.apache.commons.pool2.impl.TestAbandonedObjectPool)
> Time elapsed: 3.668 s <<< FAILURE!
> java.lang.AssertionError: expected:<5> but was:<4>
> at
> org.apache.commons.pool2.impl.TestAbandonedObjectPool.testAbandonedInvalidate(TestAbandonedObjectPool.java:202)
>
> Maybe this is due to my busy CPU, not sure.
>
> Gary
>
>
>>
>> Phil
>>
>> On 11/19/18 2:31 PM, Gary Gregory wrote:
>>> A unit test? Yes please! :-)
>>>
>>> Gary
>>>
>>> On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg <struberg@yahoo.de.invalid
>>>
>>> wrote:
>>>
>>>> +1 for the null check.
>>>>
>>>> Do you want to re-open the ticket and create a patch?
>>>>
>>>> I've created a unit test which proves my original problem with the
>>>> dead-lock.
>>>> So any improvement should be rather on the safe side from here on.
>>>>
>>>>
>>>> Regarding the RC: this is really not needed anymore when working with
>> GIT
>>>> as nothing gets pushed/released to the main repository! See the config
>>>> changes I did to the maven-release-plugin.
>>>>
>>>> txs and LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>> Am 19.11.2018 um 16:43 schrieb Phil Steitz <ph...@gmail.com>:
>>>>>
>>>>> On 11/19/18 8:19 AM, Gary Gregory wrote:
>>>>>> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins <ch...@gmail.com>
>>>> wrote:
>>>>>>> I’d be happy to roll the release if we get master to where you want
>>>> it.
>>>>>> IMO, we should integrate the recent PR I mentioned and roll RC3. Note
>>>> that this vote subject thread did not contain an RC number. Sticking to
>> the
>>>> usual process would be less troublesome IMO.
>>>>> I have not had a chance to fully review and am not really active in
>>>> [pool] any more, but I did notice that the fix for POOL-356 is missing a
>>>> null check between these two added statements:
>>>>> PooledObject<T> freshPooled = create();
>>>>> idleObjects.put(freshPooled);
>>>>>
>>>>> create() can return null and while in general it won't in this
>>>> activation context, given the lack of sync control, it is possible that
>> a
>>>> return hits between the if test and execution resulting in no capacity
>> to
>>>> create.
>>>>> I also notice some system.outs made it into the test code in one of the
>>>> commits related to POOL-340.
>>>>> Phil
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>> Cheers,
>>>>>>> -Rob
>>>>>>>
>>>>>>>> On Nov 19, 2018, at 7:18 AM, Mark Struberg
>> <struberg@yahoo.de.INVALID
>>>>>>> wrote:
>>>>>>>> Oki, I now see what you mean.
>>>>>>>>
>>>>>>>> We actually have 3 source zips now.
>>>>>>>>
>>>>>>>> .src.zip
>>>>>>>> .source-release.zip
>>>>>>>> src.jar
>>>>>>>>
>>>>>>>> That's a mess.
>>>>>>>>
>>>>>>>> There should only be 2:
>>>>>>>> * source-release.zip is the official ASF packages whole build
>> sources.
>>>>>>> This includes the pom, build structure etc.
>>>>>>>> * src.jar is the sources which are automatically downloaded by the
>>>> IDEs
>>>>>>> for debugging purpose.
>>>>>>>> We have both of them because commons-pool2 is a single-module
>> project.
>>>>>>>> And yes, we need both of them. What we do not need is the src.zip. I
>>>>>>> have no clue yet where this comes from but it shouldn't be here.
>>>>>>>> The good news:
>>>>>>>> By leveraging native GIT we now can simply a.) drop the maven
>> stating
>>>>>>> repo in repository.a.o and b.) drop the release branch and tag from
>> my
>>>>>>> github account and re-roll the release without any weird RC hacks.
>>>>>>>> Will do that,
>>>>>>>> * fix the maven setup
>>>>>>>> * happy to also include the new ticket
>>>>>>>> * re-roll the release this afternoon.
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>>
>>>>>>>>> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
>>>>>>> rmannibucau@gmail.com>:
>>>>>>>>> Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com>
>> a
>>>>>>> écrit :
>>>>>>>>>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Le ven. 16 nov. 2018 21:23, Gary Gregory <garydgregory@gmail.com
>>>
>>>> a
>>>>>>>>>> écrit
>>>>>>>>>>> :
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>>>>>>>>>> <struberg@yahoo.de.invalid
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Oki, now the full VOTE text!
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>>>>>>>>>>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The ASF staging repository is at
>>>>>>>>>>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>>>>>>> The source zip is at
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>>>>>>>> The sha1 of the source-release zip is
>>>>>>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>>>>>>>> The sha512 is
>>>>>>>>>>>>>
>>>>
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>>>>>>> For me:
>>>>>>>>>>>>
>>>>>>>>>>>> $ sha512sum commons-pool2-2.6.1-src.zip
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>
>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
>>>>>>>>>>>> *commons-pool2-2.6.1-src.zip
>>>>>>>>>>>>
>>>>>>>>>>>> Which is not what you list above. Please advise.
>>>>>>>>>>>>
>>>>>>>>>>> Src vs source-release?
>>>>>>>>>>>
>>>>>>>>>> That's the problem with inventing a new release process... why do
>> we
>>>>>>> have
>>>>>>>>>> BOTH:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>>>>>>>>>> AND
>>>>>>>>>>
>>>>>>>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>>>>>>>>>> And more importantly why are they _different_? Which one will be
>>>> used
>>>>>>> in
>>>>>>>>>> the dist/release area?
>>>>>>>>>>
>>>>>>>>> Looks like pool didnt do its homework and kept the old assembly
>>>> (src),
>>>>>>>>> source-release comes from the parent and is likely the one to keep
>>>> IMHO
>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've created the release in a GIT manner and pushed the
>> according
>>>>>>>>>>> changes
>>>>>>>>>>>>> to my ASF-linked github repo
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>>>>>>>>>> the sha1 of the commit is
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>>>>>>>>> the tag is
>>>>>>>>>>>>>
>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>>>>>>>>>> c910171
>>>>>>>>>>>>> <
>>>>
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
>>>>>>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>>>>>>>>>> succeeds.
>>>>>>>>>>>>> Site will be updated once the release has passed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please VOTE:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [+1] go ship it!
>>>>>>>>>>>>> [+0] meh, I don't care
>>>>>>>>>>>>> [-1] stop there is a ${showstopper} (that means something
>>>>>>> _important_
>>>>>>>>>>> is
>>>>>>>>>>>>> missing!)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is my own +1
>>>>>>>>>>>>> checked:
>>>>>>>>>>>>> * signature
>>>>>>>>>>>>> * hashes
>>>>>>>>>>>>> * LICENSE
>>>>>>>>>>>>> * NOTICE
>>>>>>>>>>>>> * rat
>>>>>>>>>>>>> * builds fine with various JDKs
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>> strub
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
>>>>>>>>>>> <struberg@yahoo.de.INVALID
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> PS: I've created the release in a GIT manner and pushed the
>>>>>>>>>> according
>>>>>>>>>>>>> changes to my ASF-linked github repo
>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>>>>>>>>>>> the sha1 of the commit is
>>>>>>>>>>>>>>
>>>>
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>>>>>>>>>> the tag is
>>>>>>>>>>>>>>
>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>>>>>>>>>>> c910171
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>>>>>>>>>>> succeeds.
>>>>>>>>>>>>>> Yay, this is the way GIT works and before someone not familiar
>>>> with
>>>>>>>>>>> GIT
>>>>>>>>>>>>> screams that this is not hosted on ASF: This got discussed on
>> the
>>>>>>>>>> board
>>>>>>>>>>>>> level a long time ago (when we did DeltaSpike and CouchDB as
>> the
>>>>>>> very
>>>>>>>>>>>> first
>>>>>>>>>>>>> GIT repos at the ASF) and is perfectly fine as all this is
>> based
>>>> on
>>>>>>>>>>>>> cryptographically strong steps.
>>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
>>>>>>>>>>>> <struberg@yahoo.de.INVALID
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>> Hi folks!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So far I did
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * fix the missing parts in changes.xml
>>>>>>>>>>>>>>> * generate + copy the RELEASE_NOTES
>>>>>>>>>>>>>>> * run the maven release (after fixing the setup...)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The ASF staging repository is at
>>>>>>>>>>>>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>>>>>>>>> The source zip is at
>>>>>>>>>>>>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>>>>>>>>>> The sha1 of the source-release zip is
>>>>>>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>>>>>>>>>> The sha512 is
>>>>
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS
>> file
>>>>>>>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will now continue with the follow up steps and then call an
>>>>>>>>>>> official
>>>>>>>>>>>>> VOTE.
>>>>>>>>>>>>>>> Please let me know if something went wrong so far!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Nov 19, 2018 at 2:48 PM Phil Steitz <ph...@gmail.com> wrote:
> Sorry ENOTIME, but I remembered that there is a nullsafe
> addIdleObject (see how addObject does it). In fact, you might just
> replace the manual create and add with just a call to addObject
> itself. That will also passivate the object before putting it into
> the pool, which is IIRC an invariant (objects put into the idle pool
> are passivated first).
>
> If you want to see the current code blow up, you will have to
> arrange a test with lots of borrows and returns mixed with destroys
> on validate and hope you can get the if test to succeed and then a
> return/borrow sequence before the create.
>
Like this then:
diff --git
a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
index 0575f7e..6d81dbc 100644
--- a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
+++ b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
@@ -920,8 +920,7 @@
// In case there are already threads waiting on something in
the pool
// (e.g. idleObjects.takeFirst(); then we need to provide them
a fresh instance.
// Otherwise they will be stuck forever (or until timeout)
- PooledObject<T> freshPooled = create();
- idleObjects.put(freshPooled);
+ addObject();
}
}
But causes a failure:
[INFO] Running org.apache.commons.pool2.impl.TestAbandonedObjectPool
[ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
12.253 s <<< FAILURE! - in
org.apache.commons.pool2.impl.TestAbandonedObjectPool
[ERROR]
testAbandonedInvalidate(org.apache.commons.pool2.impl.TestAbandonedObjectPool)
Time elapsed: 3.668 s <<< FAILURE!
java.lang.AssertionError: expected:<5> but was:<4>
at
org.apache.commons.pool2.impl.TestAbandonedObjectPool.testAbandonedInvalidate(TestAbandonedObjectPool.java:202)
Maybe this is due to my busy CPU, not sure.
Gary
>
> Phil
>
> On 11/19/18 2:31 PM, Gary Gregory wrote:
> > A unit test? Yes please! :-)
> >
> > Gary
> >
> > On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg <struberg@yahoo.de.invalid
> >
> > wrote:
> >
> >> +1 for the null check.
> >>
> >> Do you want to re-open the ticket and create a patch?
> >>
> >> I've created a unit test which proves my original problem with the
> >> dead-lock.
> >> So any improvement should be rather on the safe side from here on.
> >>
> >>
> >> Regarding the RC: this is really not needed anymore when working with
> GIT
> >> as nothing gets pushed/released to the main repository! See the config
> >> changes I did to the maven-release-plugin.
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 19.11.2018 um 16:43 schrieb Phil Steitz <ph...@gmail.com>:
> >>>
> >>> On 11/19/18 8:19 AM, Gary Gregory wrote:
> >>>> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins <ch...@gmail.com>
> >> wrote:
> >>>>> I’d be happy to roll the release if we get master to where you want
> >> it.
> >>>> IMO, we should integrate the recent PR I mentioned and roll RC3. Note
> >> that this vote subject thread did not contain an RC number. Sticking to
> the
> >> usual process would be less troublesome IMO.
> >>> I have not had a chance to fully review and am not really active in
> >> [pool] any more, but I did notice that the fix for POOL-356 is missing a
> >> null check between these two added statements:
> >>> PooledObject<T> freshPooled = create();
> >>> idleObjects.put(freshPooled);
> >>>
> >>> create() can return null and while in general it won't in this
> >> activation context, given the lack of sync control, it is possible that
> a
> >> return hits between the if test and execution resulting in no capacity
> to
> >> create.
> >>> I also notice some system.outs made it into the test code in one of the
> >> commits related to POOL-340.
> >>> Phil
> >>>> Gary
> >>>>
> >>>>
> >>>>> Cheers,
> >>>>> -Rob
> >>>>>
> >>>>>> On Nov 19, 2018, at 7:18 AM, Mark Struberg
> <struberg@yahoo.de.INVALID
> >>>>> wrote:
> >>>>>> Oki, I now see what you mean.
> >>>>>>
> >>>>>> We actually have 3 source zips now.
> >>>>>>
> >>>>>> .src.zip
> >>>>>> .source-release.zip
> >>>>>> src.jar
> >>>>>>
> >>>>>> That's a mess.
> >>>>>>
> >>>>>> There should only be 2:
> >>>>>> * source-release.zip is the official ASF packages whole build
> sources.
> >>>>> This includes the pom, build structure etc.
> >>>>>> * src.jar is the sources which are automatically downloaded by the
> >> IDEs
> >>>>> for debugging purpose.
> >>>>>> We have both of them because commons-pool2 is a single-module
> project.
> >>>>>> And yes, we need both of them. What we do not need is the src.zip. I
> >>>>> have no clue yet where this comes from but it shouldn't be here.
> >>>>>> The good news:
> >>>>>> By leveraging native GIT we now can simply a.) drop the maven
> stating
> >>>>> repo in repository.a.o and b.) drop the release branch and tag from
> my
> >>>>> github account and re-roll the release without any weird RC hacks.
> >>>>>> Will do that,
> >>>>>> * fix the maven setup
> >>>>>> * happy to also include the new ticket
> >>>>>> * re-roll the release this afternoon.
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
> >>>>> rmannibucau@gmail.com>:
> >>>>>>> Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com>
> a
> >>>>> écrit :
> >>>>>>>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> >>>>> rmannibucau@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Le ven. 16 nov. 2018 21:23, Gary Gregory <garydgregory@gmail.com
> >
> >> a
> >>>>>>>> écrit
> >>>>>>>>> :
> >>>>>>>>>
> >>>>>>>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> >>>>>>>> <struberg@yahoo.de.invalid
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Oki, now the full VOTE text!
> >>>>>>>>>>>
> >>>>>>>>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> >>>>>>>>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The ASF staging repository is at
> >>>>>>>>>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>>>>>>>>> The source zip is at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>>>>>>>>>> The sha1 of the source-release zip is
> >>>>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>>>>>>>>>> The sha512 is
> >>>>>>>>>>>
> >>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>>>>>>>> For me:
> >>>>>>>>>>
> >>>>>>>>>> $ sha512sum commons-pool2-2.6.1-src.zip
> >>>>>>>>>>
> >>>>>>>>>>
> >>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> >>>>>>>>>> *commons-pool2-2.6.1-src.zip
> >>>>>>>>>>
> >>>>>>>>>> Which is not what you list above. Please advise.
> >>>>>>>>>>
> >>>>>>>>> Src vs source-release?
> >>>>>>>>>
> >>>>>>>> That's the problem with inventing a new release process... why do
> we
> >>>>> have
> >>>>>>>> BOTH:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> >>>>>>>> AND
> >>>>>>>>
> >>>>>>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> >>>>>>>> And more importantly why are they _different_? Which one will be
> >> used
> >>>>> in
> >>>>>>>> the dist/release area?
> >>>>>>>>
> >>>>>>> Looks like pool didnt do its homework and kept the old assembly
> >> (src),
> >>>>>>> source-release comes from the parent and is likely the one to keep
> >> IMHO
> >>>>>>>
> >>>>>>>> Gary
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Gary
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
> >>>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>>>>>>>>>
> >>>>>>>>>>> I've created the release in a GIT manner and pushed the
> according
> >>>>>>>>> changes
> >>>>>>>>>>> to my ASF-linked github repo
> >>>>>>>>>>>
> >>>>>>>>>>>
> >> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >>>>>>>>>>> the sha1 of the commit is
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>>>>>>>>>> the tag is
> >>>>>>>>>>>
> >> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >>>>>>>>>>> c910171
> >>>>>>>>>>> <
> >>
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> >>>>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
> >>>>>>>> succeeds.
> >>>>>>>>>>> Site will be updated once the release has passed.
> >>>>>>>>>>>
> >>>>>>>>>>> Please VOTE:
> >>>>>>>>>>>
> >>>>>>>>>>> [+1] go ship it!
> >>>>>>>>>>> [+0] meh, I don't care
> >>>>>>>>>>> [-1] stop there is a ${showstopper} (that means something
> >>>>> _important_
> >>>>>>>>> is
> >>>>>>>>>>> missing!)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Here is my own +1
> >>>>>>>>>>> checked:
> >>>>>>>>>>> * signature
> >>>>>>>>>>> * hashes
> >>>>>>>>>>> * LICENSE
> >>>>>>>>>>> * NOTICE
> >>>>>>>>>>> * rat
> >>>>>>>>>>> * builds fine with various JDKs
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> LieGrue,
> >>>>>>>>>>> strub
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
> >>>>>>>>> <struberg@yahoo.de.INVALID
> >>>>>>>>>>>> :
> >>>>>>>>>>>>
> >>>>>>>>>>>> PS: I've created the release in a GIT manner and pushed the
> >>>>>>>> according
> >>>>>>>>>>> changes to my ASF-linked github repo
> >> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >>>>>>>>>>>> the sha1 of the commit is
> >>>>>>>>>>>>
> >>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>>>>>>>>>>> the tag is
> >>>>>>>>>>>>
> >> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >>>>>>>>>>>> c910171
> >>>>>>>>>>>>
> >>>>>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
> >>>>>>>>> succeeds.
> >>>>>>>>>>>> Yay, this is the way GIT works and before someone not familiar
> >> with
> >>>>>>>>> GIT
> >>>>>>>>>>> screams that this is not hosted on ASF: This got discussed on
> the
> >>>>>>>> board
> >>>>>>>>>>> level a long time ago (when we did DeltaSpike and CouchDB as
> the
> >>>>> very
> >>>>>>>>>> first
> >>>>>>>>>>> GIT repos at the ASF) and is perfectly fine as all this is
> based
> >> on
> >>>>>>>>>>> cryptographically strong steps.
> >>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>> strub
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
> >>>>>>>>>> <struberg@yahoo.de.INVALID
> >>>>>>>>>>>> :
> >>>>>>>>>>>>> Hi folks!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So far I did
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> * fix the missing parts in changes.xml
> >>>>>>>>>>>>> * generate + copy the RELEASE_NOTES
> >>>>>>>>>>>>> * run the maven release (after fixing the setup...)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The ASF staging repository is at
> >>>>>>>>>>>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>>>>>>>>>>> The source zip is at
> >>>>>>>>>>>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>>>>>>>>>>>> The sha1 of the source-release zip is
> >>>>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>>>>>>>>>>>> The sha512 is
> >>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>>>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS
> file
> >>>>>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I will now continue with the follow up steps and then call an
> >>>>>>>>> official
> >>>>>>>>>>> VOTE.
> >>>>>>>>>>>>> Please let me know if something went wrong so far!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>>> strub
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Phil Steitz <ph...@gmail.com>.
Sorry ENOTIME, but I remembered that there is a nullsafe
addIdleObject (see how addObject does it). In fact, you might just
replace the manual create and add with just a call to addObject
itself. That will also passivate the object before putting it into
the pool, which is IIRC an invariant (objects put into the idle pool
are passivated first).
If you want to see the current code blow up, you will have to
arrange a test with lots of borrows and returns mixed with destroys
on validate and hope you can get the if test to succeed and then a
return/borrow sequence before the create.
Phil
On 11/19/18 2:31 PM, Gary Gregory wrote:
> A unit test? Yes please! :-)
>
> Gary
>
> On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg <st...@yahoo.de.invalid>
> wrote:
>
>> +1 for the null check.
>>
>> Do you want to re-open the ticket and create a patch?
>>
>> I've created a unit test which proves my original problem with the
>> dead-lock.
>> So any improvement should be rather on the safe side from here on.
>>
>>
>> Regarding the RC: this is really not needed anymore when working with GIT
>> as nothing gets pushed/released to the main repository! See the config
>> changes I did to the maven-release-plugin.
>>
>> txs and LieGrue,
>> strub
>>
>>
>>
>>> Am 19.11.2018 um 16:43 schrieb Phil Steitz <ph...@gmail.com>:
>>>
>>> On 11/19/18 8:19 AM, Gary Gregory wrote:
>>>> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins <ch...@gmail.com>
>> wrote:
>>>>> I’d be happy to roll the release if we get master to where you want
>> it.
>>>> IMO, we should integrate the recent PR I mentioned and roll RC3. Note
>> that this vote subject thread did not contain an RC number. Sticking to the
>> usual process would be less troublesome IMO.
>>> I have not had a chance to fully review and am not really active in
>> [pool] any more, but I did notice that the fix for POOL-356 is missing a
>> null check between these two added statements:
>>> PooledObject<T> freshPooled = create();
>>> idleObjects.put(freshPooled);
>>>
>>> create() can return null and while in general it won't in this
>> activation context, given the lack of sync control, it is possible that a
>> return hits between the if test and execution resulting in no capacity to
>> create.
>>> I also notice some system.outs made it into the test code in one of the
>> commits related to POOL-340.
>>> Phil
>>>> Gary
>>>>
>>>>
>>>>> Cheers,
>>>>> -Rob
>>>>>
>>>>>> On Nov 19, 2018, at 7:18 AM, Mark Struberg <struberg@yahoo.de.INVALID
>>>>> wrote:
>>>>>> Oki, I now see what you mean.
>>>>>>
>>>>>> We actually have 3 source zips now.
>>>>>>
>>>>>> .src.zip
>>>>>> .source-release.zip
>>>>>> src.jar
>>>>>>
>>>>>> That's a mess.
>>>>>>
>>>>>> There should only be 2:
>>>>>> * source-release.zip is the official ASF packages whole build sources.
>>>>> This includes the pom, build structure etc.
>>>>>> * src.jar is the sources which are automatically downloaded by the
>> IDEs
>>>>> for debugging purpose.
>>>>>> We have both of them because commons-pool2 is a single-module project.
>>>>>> And yes, we need both of them. What we do not need is the src.zip. I
>>>>> have no clue yet where this comes from but it shouldn't be here.
>>>>>> The good news:
>>>>>> By leveraging native GIT we now can simply a.) drop the maven stating
>>>>> repo in repository.a.o and b.) drop the release branch and tag from my
>>>>> github account and re-roll the release without any weird RC hacks.
>>>>>> Will do that,
>>>>>> * fix the maven setup
>>>>>> * happy to also include the new ticket
>>>>>> * re-roll the release this afternoon.
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com>:
>>>>>>> Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com> a
>>>>> écrit :
>>>>>>>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com>
>> a
>>>>>>>> écrit
>>>>>>>>> :
>>>>>>>>>
>>>>>>>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>>>>>>>> <struberg@yahoo.de.invalid
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Oki, now the full VOTE text!
>>>>>>>>>>>
>>>>>>>>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>>>>>>>>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The ASF staging repository is at
>>>>>>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>>>>> The source zip is at
>>>>>>>>>>>
>>>>>>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>>>>>> The sha1 of the source-release zip is
>>>>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>>>>>> The sha512 is
>>>>>>>>>>>
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>>>>> For me:
>>>>>>>>>>
>>>>>>>>>> $ sha512sum commons-pool2-2.6.1-src.zip
>>>>>>>>>>
>>>>>>>>>>
>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
>>>>>>>>>> *commons-pool2-2.6.1-src.zip
>>>>>>>>>>
>>>>>>>>>> Which is not what you list above. Please advise.
>>>>>>>>>>
>>>>>>>>> Src vs source-release?
>>>>>>>>>
>>>>>>>> That's the problem with inventing a new release process... why do we
>>>>> have
>>>>>>>> BOTH:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>>>>>>>> AND
>>>>>>>>
>>>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>>>>>>>> And more importantly why are they _different_? Which one will be
>> used
>>>>> in
>>>>>>>> the dist/release area?
>>>>>>>>
>>>>>>> Looks like pool didnt do its homework and kept the old assembly
>> (src),
>>>>>>> source-release comes from the parent and is likely the one to keep
>> IMHO
>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>>>>>>
>>>>>>>>>>> I've created the release in a GIT manner and pushed the according
>>>>>>>>> changes
>>>>>>>>>>> to my ASF-linked github repo
>>>>>>>>>>>
>>>>>>>>>>>
>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>>>>>>>> the sha1 of the commit is
>>>>>>>>>>>
>>>>>>>>>>>
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>>>>>>> the tag is
>>>>>>>>>>>
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>>>>>>>> c910171
>>>>>>>>>>> <
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
>>>>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>>>>>>>> succeeds.
>>>>>>>>>>> Site will be updated once the release has passed.
>>>>>>>>>>>
>>>>>>>>>>> Please VOTE:
>>>>>>>>>>>
>>>>>>>>>>> [+1] go ship it!
>>>>>>>>>>> [+0] meh, I don't care
>>>>>>>>>>> [-1] stop there is a ${showstopper} (that means something
>>>>> _important_
>>>>>>>>> is
>>>>>>>>>>> missing!)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Here is my own +1
>>>>>>>>>>> checked:
>>>>>>>>>>> * signature
>>>>>>>>>>> * hashes
>>>>>>>>>>> * LICENSE
>>>>>>>>>>> * NOTICE
>>>>>>>>>>> * rat
>>>>>>>>>>> * builds fine with various JDKs
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> LieGrue,
>>>>>>>>>>> strub
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
>>>>>>>>> <struberg@yahoo.de.INVALID
>>>>>>>>>>>> :
>>>>>>>>>>>>
>>>>>>>>>>>> PS: I've created the release in a GIT manner and pushed the
>>>>>>>> according
>>>>>>>>>>> changes to my ASF-linked github repo
>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>>>>>>>>> the sha1 of the commit is
>>>>>>>>>>>>
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>>>>>>>> the tag is
>>>>>>>>>>>>
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>>>>>>>>> c910171
>>>>>>>>>>>>
>>>>>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>>>>>>>>> succeeds.
>>>>>>>>>>>> Yay, this is the way GIT works and before someone not familiar
>> with
>>>>>>>>> GIT
>>>>>>>>>>> screams that this is not hosted on ASF: This got discussed on the
>>>>>>>> board
>>>>>>>>>>> level a long time ago (when we did DeltaSpike and CouchDB as the
>>>>> very
>>>>>>>>>> first
>>>>>>>>>>> GIT repos at the ASF) and is perfectly fine as all this is based
>> on
>>>>>>>>>>> cryptographically strong steps.
>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>> strub
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
>>>>>>>>>> <struberg@yahoo.de.INVALID
>>>>>>>>>>>> :
>>>>>>>>>>>>> Hi folks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>>>>>>>>>>>
>>>>>>>>>>>>> So far I did
>>>>>>>>>>>>>
>>>>>>>>>>>>> * fix the missing parts in changes.xml
>>>>>>>>>>>>> * generate + copy the RELEASE_NOTES
>>>>>>>>>>>>> * run the maven release (after fixing the setup...)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The ASF staging repository is at
>>>>>>>>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>>>>>>> The source zip is at
>>>>>>>>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>>>>>>>> The sha1 of the source-release zip is
>>>>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>>>>>>>> The sha512 is
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will now continue with the follow up steps and then call an
>>>>>>>>> official
>>>>>>>>>>> VOTE.
>>>>>>>>>>>>> Please let me know if something went wrong so far!
>>>>>>>>>>>>>
>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>> strub
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
A unit test? Yes please! :-)
Gary
On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> +1 for the null check.
>
> Do you want to re-open the ticket and create a patch?
>
> I've created a unit test which proves my original problem with the
> dead-lock.
> So any improvement should be rather on the safe side from here on.
>
>
> Regarding the RC: this is really not needed anymore when working with GIT
> as nothing gets pushed/released to the main repository! See the config
> changes I did to the maven-release-plugin.
>
> txs and LieGrue,
> strub
>
>
>
> > Am 19.11.2018 um 16:43 schrieb Phil Steitz <ph...@gmail.com>:
> >
> > On 11/19/18 8:19 AM, Gary Gregory wrote:
> >> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins <ch...@gmail.com>
> wrote:
> >>> I’d be happy to roll the release if we get master to where you want
> it.
> >> IMO, we should integrate the recent PR I mentioned and roll RC3. Note
> that this vote subject thread did not contain an RC number. Sticking to the
> usual process would be less troublesome IMO.
> >
> > I have not had a chance to fully review and am not really active in
> [pool] any more, but I did notice that the fix for POOL-356 is missing a
> null check between these two added statements:
> >
> > PooledObject<T> freshPooled = create();
> > idleObjects.put(freshPooled);
> >
> > create() can return null and while in general it won't in this
> activation context, given the lack of sync control, it is possible that a
> return hits between the if test and execution resulting in no capacity to
> create.
> >
> > I also notice some system.outs made it into the test code in one of the
> commits related to POOL-340.
> >
> > Phil
> >>
> >> Gary
> >>
> >>
> >>> Cheers,
> >>> -Rob
> >>>
> >>>> On Nov 19, 2018, at 7:18 AM, Mark Struberg <struberg@yahoo.de.INVALID
> >
> >>> wrote:
> >>>> Oki, I now see what you mean.
> >>>>
> >>>> We actually have 3 source zips now.
> >>>>
> >>>> .src.zip
> >>>> .source-release.zip
> >>>> src.jar
> >>>>
> >>>> That's a mess.
> >>>>
> >>>> There should only be 2:
> >>>> * source-release.zip is the official ASF packages whole build sources.
> >>> This includes the pom, build structure etc.
> >>>> * src.jar is the sources which are automatically downloaded by the
> IDEs
> >>> for debugging purpose.
> >>>> We have both of them because commons-pool2 is a single-module project.
> >>>> And yes, we need both of them. What we do not need is the src.zip. I
> >>> have no clue yet where this comes from but it shouldn't be here.
> >>>>
> >>>> The good news:
> >>>> By leveraging native GIT we now can simply a.) drop the maven stating
> >>> repo in repository.a.o and b.) drop the release branch and tag from my
> >>> github account and re-roll the release without any weird RC hacks.
> >>>> Will do that,
> >>>> * fix the maven setup
> >>>> * happy to also include the new ticket
> >>>> * re-roll the release this afternoon.
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
> >>> rmannibucau@gmail.com>:
> >>>>> Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com> a
> >>> écrit :
> >>>>>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> >>> rmannibucau@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com>
> a
> >>>>>> écrit
> >>>>>>> :
> >>>>>>>
> >>>>>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> >>>>>> <struberg@yahoo.de.invalid
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Oki, now the full VOTE text!
> >>>>>>>>>
> >>>>>>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> >>>>>>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The ASF staging repository is at
> >>>>>>>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>>>>>>> The source zip is at
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>>>>>>>> The sha1 of the source-release zip is
> >>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>>>>>>>> The sha512 is
> >>>>>>>>>
> >>>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>>>>>> For me:
> >>>>>>>>
> >>>>>>>> $ sha512sum commons-pool2-2.6.1-src.zip
> >>>>>>>>
> >>>>>>>>
> >>>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> >>>>>>>> *commons-pool2-2.6.1-src.zip
> >>>>>>>>
> >>>>>>>> Which is not what you list above. Please advise.
> >>>>>>>>
> >>>>>>> Src vs source-release?
> >>>>>>>
> >>>>>> That's the problem with inventing a new release process... why do we
> >>> have
> >>>>>> BOTH:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> >>>>>> AND
> >>>>>>
> >>>>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> >>>>>> And more importantly why are they _different_? Which one will be
> used
> >>> in
> >>>>>> the dist/release area?
> >>>>>>
> >>>>>
> >>>>> Looks like pool didnt do its homework and kept the old assembly
> (src),
> >>>>> source-release comes from the parent and is likely the one to keep
> IMHO
> >>>>>
> >>>>>
> >>>>>> Gary
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Gary
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
> >>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>>>>>>>
> >>>>>>>>> I've created the release in a GIT manner and pushed the according
> >>>>>>> changes
> >>>>>>>>> to my ASF-linked github repo
> >>>>>>>>>
> >>>>>>>>>
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >>>>>>>>> the sha1 of the commit is
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>>>>>>>> the tag is
> >>>>>>>>>
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >>>>>>>>> c910171
> >>>>>>>>> <
> >>>
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> >>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
> >>>>>> succeeds.
> >>>>>>>>> Site will be updated once the release has passed.
> >>>>>>>>>
> >>>>>>>>> Please VOTE:
> >>>>>>>>>
> >>>>>>>>> [+1] go ship it!
> >>>>>>>>> [+0] meh, I don't care
> >>>>>>>>> [-1] stop there is a ${showstopper} (that means something
> >>> _important_
> >>>>>>> is
> >>>>>>>>> missing!)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Here is my own +1
> >>>>>>>>> checked:
> >>>>>>>>> * signature
> >>>>>>>>> * hashes
> >>>>>>>>> * LICENSE
> >>>>>>>>> * NOTICE
> >>>>>>>>> * rat
> >>>>>>>>> * builds fine with various JDKs
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> LieGrue,
> >>>>>>>>> strub
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
> >>>>>>> <struberg@yahoo.de.INVALID
> >>>>>>>>>> :
> >>>>>>>>>>
> >>>>>>>>>> PS: I've created the release in a GIT manner and pushed the
> >>>>>> according
> >>>>>>>>> changes to my ASF-linked github repo
> >>>>>>>>>>
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >>>>>>>>>> the sha1 of the commit is
> >>>>>>>>>>
> >>>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>>>>>>>>> the tag is
> >>>>>>>>>>
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >>>>>>>>>> c910171
> >>>>>>>>>>
> >>>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
> >>>>>>> succeeds.
> >>>>>>>>>> Yay, this is the way GIT works and before someone not familiar
> with
> >>>>>>> GIT
> >>>>>>>>> screams that this is not hosted on ASF: This got discussed on the
> >>>>>> board
> >>>>>>>>> level a long time ago (when we did DeltaSpike and CouchDB as the
> >>> very
> >>>>>>>> first
> >>>>>>>>> GIT repos at the ASF) and is perfectly fine as all this is based
> on
> >>>>>>>>> cryptographically strong steps.
> >>>>>>>>>> LieGrue,
> >>>>>>>>>> strub
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
> >>>>>>>> <struberg@yahoo.de.INVALID
> >>>>>>>>>> :
> >>>>>>>>>>> Hi folks!
> >>>>>>>>>>>
> >>>>>>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
> >>>>>>>>>>>
> >>>>>>>>>>> So far I did
> >>>>>>>>>>>
> >>>>>>>>>>> * fix the missing parts in changes.xml
> >>>>>>>>>>> * generate + copy the RELEASE_NOTES
> >>>>>>>>>>> * run the maven release (after fixing the setup...)
> >>>>>>>>>>>
> >>>>>>>>>>> The ASF staging repository is at
> >>>>>>>>>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>>>>>>>>> The source zip is at
> >>>>>>>>>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>>>>>>>>>> The sha1 of the source-release zip is
> >>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>>>>>>>>>> The sha512 is
> >>>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
> >>>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>>>>>>>>>
> >>>>>>>>>>> I will now continue with the follow up steps and then call an
> >>>>>>> official
> >>>>>>>>> VOTE.
> >>>>>>>>>>> Please let me know if something went wrong so far!
> >>>>>>>>>>>
> >>>>>>>>>>> LieGrue,
> >>>>>>>>>>> strub
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
+1 for the null check.
Do you want to re-open the ticket and create a patch?
I've created a unit test which proves my original problem with the dead-lock.
So any improvement should be rather on the safe side from here on.
Regarding the RC: this is really not needed anymore when working with GIT as nothing gets pushed/released to the main repository! See the config changes I did to the maven-release-plugin.
txs and LieGrue,
strub
> Am 19.11.2018 um 16:43 schrieb Phil Steitz <ph...@gmail.com>:
>
> On 11/19/18 8:19 AM, Gary Gregory wrote:
>> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins <ch...@gmail.com> wrote:
>>> I’d be happy to roll the release if we get master to where you want it.
>> IMO, we should integrate the recent PR I mentioned and roll RC3. Note that this vote subject thread did not contain an RC number. Sticking to the usual process would be less troublesome IMO.
>
> I have not had a chance to fully review and am not really active in [pool] any more, but I did notice that the fix for POOL-356 is missing a null check between these two added statements:
>
> PooledObject<T> freshPooled = create();
> idleObjects.put(freshPooled);
>
> create() can return null and while in general it won't in this activation context, given the lack of sync control, it is possible that a return hits between the if test and execution resulting in no capacity to create.
>
> I also notice some system.outs made it into the test code in one of the commits related to POOL-340.
>
> Phil
>>
>> Gary
>>
>>
>>> Cheers,
>>> -Rob
>>>
>>>> On Nov 19, 2018, at 7:18 AM, Mark Struberg <st...@yahoo.de.INVALID>
>>> wrote:
>>>> Oki, I now see what you mean.
>>>>
>>>> We actually have 3 source zips now.
>>>>
>>>> .src.zip
>>>> .source-release.zip
>>>> src.jar
>>>>
>>>> That's a mess.
>>>>
>>>> There should only be 2:
>>>> * source-release.zip is the official ASF packages whole build sources.
>>> This includes the pom, build structure etc.
>>>> * src.jar is the sources which are automatically downloaded by the IDEs
>>> for debugging purpose.
>>>> We have both of them because commons-pool2 is a single-module project.
>>>> And yes, we need both of them. What we do not need is the src.zip. I
>>> have no clue yet where this comes from but it shouldn't be here.
>>>>
>>>> The good news:
>>>> By leveraging native GIT we now can simply a.) drop the maven stating
>>> repo in repository.a.o and b.) drop the release branch and tag from my
>>> github account and re-roll the release without any weird RC hacks.
>>>> Will do that,
>>>> * fix the maven setup
>>>> * happy to also include the new ticket
>>>> * re-roll the release this afternoon.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
>>> rmannibucau@gmail.com>:
>>>>> Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com> a
>>> écrit :
>>>>>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
>>> rmannibucau@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com> a
>>>>>> écrit
>>>>>>> :
>>>>>>>
>>>>>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>>>>>> <struberg@yahoo.de.invalid
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Oki, now the full VOTE text!
>>>>>>>>>
>>>>>>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>>>>>>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The ASF staging repository is at
>>>>>>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>>> The source zip is at
>>>>>>>>>
>>>>>>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>>>> The sha1 of the source-release zip is
>>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>>>> The sha512 is
>>>>>>>>>
>>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>>> For me:
>>>>>>>>
>>>>>>>> $ sha512sum commons-pool2-2.6.1-src.zip
>>>>>>>>
>>>>>>>>
>>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
>>>>>>>> *commons-pool2-2.6.1-src.zip
>>>>>>>>
>>>>>>>> Which is not what you list above. Please advise.
>>>>>>>>
>>>>>>> Src vs source-release?
>>>>>>>
>>>>>> That's the problem with inventing a new release process... why do we
>>> have
>>>>>> BOTH:
>>>>>>
>>>>>>
>>>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>>>>>> AND
>>>>>>
>>>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>>>>>> And more importantly why are they _different_? Which one will be used
>>> in
>>>>>> the dist/release area?
>>>>>>
>>>>>
>>>>> Looks like pool didnt do its homework and kept the old assembly (src),
>>>>> source-release comes from the parent and is likely the one to keep IMHO
>>>>>
>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>
>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>>>>
>>>>>>>>> I've created the release in a GIT manner and pushed the according
>>>>>>> changes
>>>>>>>>> to my ASF-linked github repo
>>>>>>>>>
>>>>>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>>>>>> the sha1 of the commit is
>>>>>>>>>
>>>>>>>>>
>>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>>>>> the tag is
>>>>>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>>>>>> c910171
>>>>>>>>> <
>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
>>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>>>>>> succeeds.
>>>>>>>>> Site will be updated once the release has passed.
>>>>>>>>>
>>>>>>>>> Please VOTE:
>>>>>>>>>
>>>>>>>>> [+1] go ship it!
>>>>>>>>> [+0] meh, I don't care
>>>>>>>>> [-1] stop there is a ${showstopper} (that means something
>>> _important_
>>>>>>> is
>>>>>>>>> missing!)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here is my own +1
>>>>>>>>> checked:
>>>>>>>>> * signature
>>>>>>>>> * hashes
>>>>>>>>> * LICENSE
>>>>>>>>> * NOTICE
>>>>>>>>> * rat
>>>>>>>>> * builds fine with various JDKs
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> LieGrue,
>>>>>>>>> strub
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
>>>>>>> <struberg@yahoo.de.INVALID
>>>>>>>>>> :
>>>>>>>>>>
>>>>>>>>>> PS: I've created the release in a GIT manner and pushed the
>>>>>> according
>>>>>>>>> changes to my ASF-linked github repo
>>>>>>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>>>>>>> the sha1 of the commit is
>>>>>>>>>>
>>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>>>>>> the tag is
>>>>>>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>>>>>>> c910171
>>>>>>>>>>
>>>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>>>>>>> succeeds.
>>>>>>>>>> Yay, this is the way GIT works and before someone not familiar with
>>>>>>> GIT
>>>>>>>>> screams that this is not hosted on ASF: This got discussed on the
>>>>>> board
>>>>>>>>> level a long time ago (when we did DeltaSpike and CouchDB as the
>>> very
>>>>>>>> first
>>>>>>>>> GIT repos at the ASF) and is perfectly fine as all this is based on
>>>>>>>>> cryptographically strong steps.
>>>>>>>>>> LieGrue,
>>>>>>>>>> strub
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
>>>>>>>> <struberg@yahoo.de.INVALID
>>>>>>>>>> :
>>>>>>>>>>> Hi folks!
>>>>>>>>>>>
>>>>>>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>>>>>>>>>
>>>>>>>>>>> So far I did
>>>>>>>>>>>
>>>>>>>>>>> * fix the missing parts in changes.xml
>>>>>>>>>>> * generate + copy the RELEASE_NOTES
>>>>>>>>>>> * run the maven release (after fixing the setup...)
>>>>>>>>>>>
>>>>>>>>>>> The ASF staging repository is at
>>>>>>>>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>>>>> The source zip is at
>>>>>>>>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>>>>>> The sha1 of the source-release zip is
>>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>>>>>> The sha512 is
>>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>>>>>>
>>>>>>>>>>> I will now continue with the follow up steps and then call an
>>>>>>> official
>>>>>>>>> VOTE.
>>>>>>>>>>> Please let me know if something went wrong so far!
>>>>>>>>>>>
>>>>>>>>>>> LieGrue,
>>>>>>>>>>> strub
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Phil Steitz <ph...@gmail.com>.
On 11/19/18 8:19 AM, Gary Gregory wrote:
> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins <ch...@gmail.com>
> wrote:
>> I’d be happy to roll the release if we get master to where you
>> want it.
> IMO, we should integrate the recent PR I mentioned and roll RC3.
> Note that this vote subject thread did not contain an RC number.
> Sticking to the usual process would be less troublesome IMO.
I have not had a chance to fully review and am not really active in
[pool] any more, but I did notice that the fix for POOL-356 is
missing a null check between these two added statements:
PooledObject<T> freshPooled = create();
idleObjects.put(freshPooled);
create() can return null and while in general it won't in this
activation context, given the lack of sync control, it is possible
that a return hits between the if test and execution resulting in no
capacity to create.
I also notice some system.outs made it into the test code in one of
the commits related to POOL-340.
Phil
>
> Gary
>
>
>> Cheers,
>> -Rob
>>
>>> On Nov 19, 2018, at 7:18 AM, Mark Struberg <st...@yahoo.de.INVALID>
>> wrote:
>>> Oki, I now see what you mean.
>>>
>>> We actually have 3 source zips now.
>>>
>>> .src.zip
>>> .source-release.zip
>>> src.jar
>>>
>>> That's a mess.
>>>
>>> There should only be 2:
>>> * source-release.zip is the official ASF packages whole build sources.
>> This includes the pom, build structure etc.
>>> * src.jar is the sources which are automatically downloaded by the IDEs
>> for debugging purpose.
>>> We have both of them because commons-pool2 is a single-module project.
>>> And yes, we need both of them. What we do not need is the src.zip. I
>> have no clue yet where this comes from but it shouldn't be here.
>>>
>>> The good news:
>>> By leveraging native GIT we now can simply a.) drop the maven stating
>> repo in repository.a.o and b.) drop the release branch and tag from my
>> github account and re-roll the release without any weird RC hacks.
>>> Will do that,
>>> * fix the maven setup
>>> * happy to also include the new ticket
>>> * re-roll the release this afternoon.
>>>
>>> LieGrue,
>>> strub
>>>
>>>> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
>> rmannibucau@gmail.com>:
>>>> Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com> a
>> écrit :
>>>>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com> a
>>>>> écrit
>>>>>> :
>>>>>>
>>>>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>>>>> <struberg@yahoo.de.invalid
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Oki, now the full VOTE text!
>>>>>>>>
>>>>>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>>>>>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>>>>>>>>
>>>>>>>>
>>>>>>>> The ASF staging repository is at
>>>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>> The source zip is at
>>>>>>>>
>>>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>>> The sha1 of the source-release zip is
>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>>> The sha512 is
>>>>>>>>
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>> For me:
>>>>>>>
>>>>>>> $ sha512sum commons-pool2-2.6.1-src.zip
>>>>>>>
>>>>>>>
>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
>>>>>>> *commons-pool2-2.6.1-src.zip
>>>>>>>
>>>>>>> Which is not what you list above. Please advise.
>>>>>>>
>>>>>> Src vs source-release?
>>>>>>
>>>>> That's the problem with inventing a new release process... why do we
>> have
>>>>> BOTH:
>>>>>
>>>>>
>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>>>>> AND
>>>>>
>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>>>>> And more importantly why are they _different_? Which one will be used
>> in
>>>>> the dist/release area?
>>>>>
>>>>
>>>> Looks like pool didnt do its homework and kept the old assembly (src),
>>>> source-release comes from the parent and is likely the one to keep IMHO
>>>>
>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>
>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>>>
>>>>>>>> I've created the release in a GIT manner and pushed the according
>>>>>> changes
>>>>>>>> to my ASF-linked github repo
>>>>>>>>
>>>>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>>>>> the sha1 of the commit is
>>>>>>>>
>>>>>>>>
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>>>> the tag is
>>>>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>>>>> c910171
>>>>>>>> <
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>>>>> succeeds.
>>>>>>>> Site will be updated once the release has passed.
>>>>>>>>
>>>>>>>> Please VOTE:
>>>>>>>>
>>>>>>>> [+1] go ship it!
>>>>>>>> [+0] meh, I don't care
>>>>>>>> [-1] stop there is a ${showstopper} (that means something
>> _important_
>>>>>> is
>>>>>>>> missing!)
>>>>>>>>
>>>>>>>>
>>>>>>>> Here is my own +1
>>>>>>>> checked:
>>>>>>>> * signature
>>>>>>>> * hashes
>>>>>>>> * LICENSE
>>>>>>>> * NOTICE
>>>>>>>> * rat
>>>>>>>> * builds fine with various JDKs
>>>>>>>>
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
>>>>>> <struberg@yahoo.de.INVALID
>>>>>>>>> :
>>>>>>>>>
>>>>>>>>> PS: I've created the release in a GIT manner and pushed the
>>>>> according
>>>>>>>> changes to my ASF-linked github repo
>>>>>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>>>>>> the sha1 of the commit is
>>>>>>>>>
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>>>>> the tag is
>>>>>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>>>>>> c910171
>>>>>>>>>
>>>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>>>>>> succeeds.
>>>>>>>>> Yay, this is the way GIT works and before someone not familiar with
>>>>>> GIT
>>>>>>>> screams that this is not hosted on ASF: This got discussed on the
>>>>> board
>>>>>>>> level a long time ago (when we did DeltaSpike and CouchDB as the
>> very
>>>>>>> first
>>>>>>>> GIT repos at the ASF) and is perfectly fine as all this is based on
>>>>>>>> cryptographically strong steps.
>>>>>>>>> LieGrue,
>>>>>>>>> strub
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
>>>>>>> <struberg@yahoo.de.INVALID
>>>>>>>>> :
>>>>>>>>>> Hi folks!
>>>>>>>>>>
>>>>>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>>>>>>>>
>>>>>>>>>> So far I did
>>>>>>>>>>
>>>>>>>>>> * fix the missing parts in changes.xml
>>>>>>>>>> * generate + copy the RELEASE_NOTES
>>>>>>>>>> * run the maven release (after fixing the setup...)
>>>>>>>>>>
>>>>>>>>>> The ASF staging repository is at
>>>>>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>>>> The source zip is at
>>>>>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>>>>> The sha1 of the source-release zip is
>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>>>>> The sha512 is
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>>>>>
>>>>>>>>>> I will now continue with the follow up steps and then call an
>>>>>> official
>>>>>>>> VOTE.
>>>>>>>>>> Please let me know if something went wrong so far!
>>>>>>>>>>
>>>>>>>>>> LieGrue,
>>>>>>>>>> strub
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins <ch...@gmail.com> wrote:
> I’d be happy to roll the release if we get master to where you want it.
>
IMO, we should integrate the recent PR I mentioned and roll RC3. Note that
this vote subject thread did not contain an RC number. Sticking to the
usual process would be less troublesome IMO.
Gary
>
> Cheers,
> -Rob
>
> > On Nov 19, 2018, at 7:18 AM, Mark Struberg <st...@yahoo.de.INVALID>
> wrote:
> >
> > Oki, I now see what you mean.
> >
> > We actually have 3 source zips now.
> >
> > .src.zip
> > .source-release.zip
> > src.jar
> >
> > That's a mess.
> >
> > There should only be 2:
> > * source-release.zip is the official ASF packages whole build sources.
> This includes the pom, build structure etc.
> > * src.jar is the sources which are automatically downloaded by the IDEs
> for debugging purpose.
> >
> > We have both of them because commons-pool2 is a single-module project.
> > And yes, we need both of them. What we do not need is the src.zip. I
> have no clue yet where this comes from but it shouldn't be here.
> >
> >
> > The good news:
> > By leveraging native GIT we now can simply a.) drop the maven stating
> repo in repository.a.o and b.) drop the release branch and tag from my
> github account and re-roll the release without any weird RC hacks.
> >
> > Will do that,
> > * fix the maven setup
> > * happy to also include the new ticket
> > * re-roll the release this afternoon.
> >
> > LieGrue,
> > strub
> >
> >> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com>:
> >>
> >> Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com> a
> écrit :
> >>
> >>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >>> wrote:
> >>>
> >>>> Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com> a
> >>> écrit
> >>>> :
> >>>>
> >>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> >>> <struberg@yahoo.de.invalid
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Oki, now the full VOTE text!
> >>>>>>
> >>>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> >>>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
> >>>>>>
> >>>>>>
> >>>>>> The ASF staging repository is at
> >>>>>>
> >>>>>
> >>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>>>>
> >>>>>> The source zip is at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>>>>> The sha1 of the source-release zip is
> >>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>>>>> The sha512 is
> >>>>>>
> >>>>>
> >>>>
> >>>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>>>>
> >>>>>
> >>>>> For me:
> >>>>>
> >>>>> $ sha512sum commons-pool2-2.6.1-src.zip
> >>>>>
> >>>>>
> >>>>
> >>>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> >>>>> *commons-pool2-2.6.1-src.zip
> >>>>>
> >>>>> Which is not what you list above. Please advise.
> >>>>>
> >>>>
> >>>> Src vs source-release?
> >>>>
> >>>
> >>> That's the problem with inventing a new release process... why do we
> have
> >>> BOTH:
> >>>
> >>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> >>> AND
> >>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> >>>
> >>> And more importantly why are they _different_? Which one will be used
> in
> >>> the dist/release area?
> >>>
> >>
> >>
> >> Looks like pool didnt do its homework and kept the old assembly (src),
> >> source-release comes from the parent and is likely the one to keep IMHO
> >>
> >>
> >>> Gary
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Gary
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
> >>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>>>>
> >>>>>> I've created the release in a GIT manner and pushed the according
> >>>> changes
> >>>>>> to my ASF-linked github repo
> >>>>>>
> >>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >>>>>> the sha1 of the commit is
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>>>>>
> >>>>>> the tag is
> >>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >>>>>> c910171
> >>>>>> <
> >>>>>
> >>>
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> >>>>>
> >>>>>>
> >>>>>> This will get pushed to the ASF cannonical repo once the VOTE
> >>> succeeds.
> >>>>>>
> >>>>>> Site will be updated once the release has passed.
> >>>>>>
> >>>>>> Please VOTE:
> >>>>>>
> >>>>>> [+1] go ship it!
> >>>>>> [+0] meh, I don't care
> >>>>>> [-1] stop there is a ${showstopper} (that means something
> _important_
> >>>> is
> >>>>>> missing!)
> >>>>>>
> >>>>>>
> >>>>>> Here is my own +1
> >>>>>> checked:
> >>>>>> * signature
> >>>>>> * hashes
> >>>>>> * LICENSE
> >>>>>> * NOTICE
> >>>>>> * rat
> >>>>>> * builds fine with various JDKs
> >>>>>>
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
> >>>> <struberg@yahoo.de.INVALID
> >>>>>>> :
> >>>>>>>
> >>>>>>> PS: I've created the release in a GIT manner and pushed the
> >>> according
> >>>>>> changes to my ASF-linked github repo
> >>>>>>>
> >>>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >>>>>>> the sha1 of the commit is
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>>>>>>
> >>>>>>> the tag is
> >>>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >>>>>>> c910171
> >>>>>>>
> >>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
> >>>> succeeds.
> >>>>>>> Yay, this is the way GIT works and before someone not familiar with
> >>>> GIT
> >>>>>> screams that this is not hosted on ASF: This got discussed on the
> >>> board
> >>>>>> level a long time ago (when we did DeltaSpike and CouchDB as the
> very
> >>>>> first
> >>>>>> GIT repos at the ASF) and is perfectly fine as all this is based on
> >>>>>> cryptographically strong steps.
> >>>>>>>
> >>>>>>> LieGrue,
> >>>>>>> strub
> >>>>>>>
> >>>>>>>
> >>>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
> >>>>> <struberg@yahoo.de.INVALID
> >>>>>>> :
> >>>>>>>>
> >>>>>>>> Hi folks!
> >>>>>>>>
> >>>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
> >>>>>>>>
> >>>>>>>> So far I did
> >>>>>>>>
> >>>>>>>> * fix the missing parts in changes.xml
> >>>>>>>> * generate + copy the RELEASE_NOTES
> >>>>>>>> * run the maven release (after fixing the setup...)
> >>>>>>>>
> >>>>>>>> The ASF staging repository is at
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>>>>>>
> >>>>>>>> The source zip is at
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>>>>>>> The sha1 of the source-release zip is
> >>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>>>>>>> The sha512 is
> >>>>>>
> >>>>>
> >>>>
> >>>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>>>>>>
> >>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
> >>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>>>>>>
> >>>>>>>> I will now continue with the follow up steps and then call an
> >>>> official
> >>>>>> VOTE.
> >>>>>>>>
> >>>>>>>> Please let me know if something went wrong so far!
> >>>>>>>>
> >>>>>>>> LieGrue,
> >>>>>>>> strub
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Rob Tompkins <ch...@gmail.com>.
I’d be happy to roll the release if we get master to where you want it.
Cheers,
-Rob
> On Nov 19, 2018, at 7:18 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>
> Oki, I now see what you mean.
>
> We actually have 3 source zips now.
>
> .src.zip
> .source-release.zip
> src.jar
>
> That's a mess.
>
> There should only be 2:
> * source-release.zip is the official ASF packages whole build sources. This includes the pom, build structure etc.
> * src.jar is the sources which are automatically downloaded by the IDEs for debugging purpose.
>
> We have both of them because commons-pool2 is a single-module project.
> And yes, we need both of them. What we do not need is the src.zip. I have no clue yet where this comes from but it shouldn't be here.
>
>
> The good news:
> By leveraging native GIT we now can simply a.) drop the maven stating repo in repository.a.o and b.) drop the release branch and tag from my github account and re-roll the release without any weird RC hacks.
>
> Will do that,
> * fix the maven setup
> * happy to also include the new ticket
> * re-roll the release this afternoon.
>
> LieGrue,
> strub
>
>> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>>
>> Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com> a écrit :
>>
>>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>>
>>>> Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com> a
>>> écrit
>>>> :
>>>>
>>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>>> <struberg@yahoo.de.invalid
>>>>>
>>>>> wrote:
>>>>>
>>>>>> Oki, now the full VOTE text!
>>>>>>
>>>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>>>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>>>>>>
>>>>>>
>>>>>> The ASF staging repository is at
>>>>>>
>>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>
>>>>>> The source zip is at
>>>>>>
>>>>>>
>>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>> The sha1 of the source-release zip is
>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>> The sha512 is
>>>>>>
>>>>>
>>>>
>>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>
>>>>>
>>>>> For me:
>>>>>
>>>>> $ sha512sum commons-pool2-2.6.1-src.zip
>>>>>
>>>>>
>>>>
>>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
>>>>> *commons-pool2-2.6.1-src.zip
>>>>>
>>>>> Which is not what you list above. Please advise.
>>>>>
>>>>
>>>> Src vs source-release?
>>>>
>>>
>>> That's the problem with inventing a new release process... why do we have
>>> BOTH:
>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>>> AND
>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>>>
>>> And more importantly why are they _different_? Which one will be used in
>>> the dist/release area?
>>>
>>
>>
>> Looks like pool didnt do its homework and kept the old assembly (src),
>> source-release comes from the parent and is likely the one to keep IMHO
>>
>>
>>> Gary
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>>
>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>
>>>>>> I've created the release in a GIT manner and pushed the according
>>>> changes
>>>>>> to my ASF-linked github repo
>>>>>>
>>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>>> the sha1 of the commit is
>>>>>>
>>>>>>
>>>>>
>>>>
>>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>>
>>>>>> the tag is
>>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>>> c910171
>>>>>> <
>>>>>
>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
>>>>>
>>>>>>
>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>>> succeeds.
>>>>>>
>>>>>> Site will be updated once the release has passed.
>>>>>>
>>>>>> Please VOTE:
>>>>>>
>>>>>> [+1] go ship it!
>>>>>> [+0] meh, I don't care
>>>>>> [-1] stop there is a ${showstopper} (that means something _important_
>>>> is
>>>>>> missing!)
>>>>>>
>>>>>>
>>>>>> Here is my own +1
>>>>>> checked:
>>>>>> * signature
>>>>>> * hashes
>>>>>> * LICENSE
>>>>>> * NOTICE
>>>>>> * rat
>>>>>> * builds fine with various JDKs
>>>>>>
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
>>>> <struberg@yahoo.de.INVALID
>>>>>>> :
>>>>>>>
>>>>>>> PS: I've created the release in a GIT manner and pushed the
>>> according
>>>>>> changes to my ASF-linked github repo
>>>>>>>
>>>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>>>> the sha1 of the commit is
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>>>
>>>>>>> the tag is
>>>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>>>> c910171
>>>>>>>
>>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>>>> succeeds.
>>>>>>> Yay, this is the way GIT works and before someone not familiar with
>>>> GIT
>>>>>> screams that this is not hosted on ASF: This got discussed on the
>>> board
>>>>>> level a long time ago (when we did DeltaSpike and CouchDB as the very
>>>>> first
>>>>>> GIT repos at the ASF) and is perfectly fine as all this is based on
>>>>>> cryptographically strong steps.
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
>>>>> <struberg@yahoo.de.INVALID
>>>>>>> :
>>>>>>>>
>>>>>>>> Hi folks!
>>>>>>>>
>>>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>>>>>>
>>>>>>>> So far I did
>>>>>>>>
>>>>>>>> * fix the missing parts in changes.xml
>>>>>>>> * generate + copy the RELEASE_NOTES
>>>>>>>> * run the maven release (after fixing the setup...)
>>>>>>>>
>>>>>>>> The ASF staging repository is at
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>>
>>>>>>>> The source zip is at
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>>> The sha1 of the source-release zip is
>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>>> The sha512 is
>>>>>>
>>>>>
>>>>
>>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>>>
>>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>>>
>>>>>>>> I will now continue with the follow up steps and then call an
>>>> official
>>>>>> VOTE.
>>>>>>>>
>>>>>>>> Please let me know if something went wrong so far!
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Romain Manni-Bucau <rm...@gmail.com>.
AFAIK source-release is quite standard @asf so likely saner to use that
from now on IMHO.
Agree sources is needed but Think Mark's point was more about assemblies
than default release artifacts.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 19 nov. 2018 à 15:54, Gary Gregory <ga...@gmail.com> a
écrit :
> On Mon, Nov 19, 2018 at 5:22 AM Mark Struberg <st...@yahoo.de.invalid>
> wrote:
>
> > Oki, I now see what you mean.
> >
> > We actually have 3 source zips now.
> >
> > .src.zip
> > .source-release.zip
> > src.jar
> >
> > That's a mess.
> >
> > There should only be 2:
> > * source-release.zip is the official ASF packages whole build sources.
> > This includes the pom, build structure etc.
> > * src.jar is the sources which are automatically downloaded by the IDEs
> > for debugging purpose.
> >
>
> Nope, it's the "-sources" jar that is used in IDEs. The "-src" jar is what
> _should_ contain all sources needed to build the jar and site.
>
> "source-release" is not something we've used here before IIRC.
>
> Gary
>
>
> >
> > We have both of them because commons-pool2 is a single-module project.
> > And yes, we need both of them. What we do not need is the src.zip. I have
> > no clue yet where this comes from but it shouldn't be here.
> >
> >
> > The good news:
> > By leveraging native GIT we now can simply a.) drop the maven stating
> repo
> > in repository.a.o and b.) drop the release branch and tag from my github
> > account and re-roll the release without any weird RC hacks.
> >
> > Will do that,
> > * fix the maven setup
> > * happy to also include the new ticket
> > * re-roll the release this afternoon.
> >
> > LieGrue,
> > strub
> >
> > > Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >:
> > >
> > > Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com> a
> > écrit :
> > >
> > >> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > >> wrote:
> > >>
> > >>> Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com> a
> > >> écrit
> > >>> :
> > >>>
> > >>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> > >> <struberg@yahoo.de.invalid
> > >>>>
> > >>>> wrote:
> > >>>>
> > >>>>> Oki, now the full VOTE text!
> > >>>>>
> > >>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > >>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
> > >>>>>
> > >>>>>
> > >>>>> The ASF staging repository is at
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > >>>>>
> > >>>>> The source zip is at
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > >>>>> The sha1 of the source-release zip is
> > >>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > >>>>> The sha512 is
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> > >>>>>
> > >>>>
> > >>>> For me:
> > >>>>
> > >>>> $ sha512sum commons-pool2-2.6.1-src.zip
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> > >>>> *commons-pool2-2.6.1-src.zip
> > >>>>
> > >>>> Which is not what you list above. Please advise.
> > >>>>
> > >>>
> > >>> Src vs source-release?
> > >>>
> > >>
> > >> That's the problem with inventing a new release process... why do we
> > have
> > >> BOTH:
> > >>
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> > >> AND
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> > >>
> > >> And more importantly why are they _different_? Which one will be used
> in
> > >> the dist/release area?
> > >>
> > >
> > >
> > > Looks like pool didnt do its homework and kept the old assembly (src),
> > > source-release comes from the parent and is likely the one to keep IMHO
> > >
> > >
> > >> Gary
> > >>
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> Gary
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
> > >>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> > >>>>>
> > >>>>> I've created the release in a GIT manner and pushed the according
> > >>> changes
> > >>>>> to my ASF-linked github repo
> > >>>>>
> > >>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > >>>>> the sha1 of the commit is
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> > >>>>>
> > >>>>> the tag is
> > >>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > >>>>> c910171
> > >>>>> <
> > >>>>
> > >>
> > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> > >>>>
> > >>>>>
> > >>>>> This will get pushed to the ASF cannonical repo once the VOTE
> > >> succeeds.
> > >>>>>
> > >>>>> Site will be updated once the release has passed.
> > >>>>>
> > >>>>> Please VOTE:
> > >>>>>
> > >>>>> [+1] go ship it!
> > >>>>> [+0] meh, I don't care
> > >>>>> [-1] stop there is a ${showstopper} (that means something
> _important_
> > >>> is
> > >>>>> missing!)
> > >>>>>
> > >>>>>
> > >>>>> Here is my own +1
> > >>>>> checked:
> > >>>>> * signature
> > >>>>> * hashes
> > >>>>> * LICENSE
> > >>>>> * NOTICE
> > >>>>> * rat
> > >>>>> * builds fine with various JDKs
> > >>>>>
> > >>>>>
> > >>>>> LieGrue,
> > >>>>> strub
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
> > >>> <struberg@yahoo.de.INVALID
> > >>>>>> :
> > >>>>>>
> > >>>>>> PS: I've created the release in a GIT manner and pushed the
> > >> according
> > >>>>> changes to my ASF-linked github repo
> > >>>>>>
> > >>>>>>
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > >>>>>> the sha1 of the commit is
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> > >>>>>>
> > >>>>>> the tag is
> > >>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > >>>>>> c910171
> > >>>>>>
> > >>>>>> This will get pushed to the ASF cannonical repo once the VOTE
> > >>> succeeds.
> > >>>>>> Yay, this is the way GIT works and before someone not familiar
> with
> > >>> GIT
> > >>>>> screams that this is not hosted on ASF: This got discussed on the
> > >> board
> > >>>>> level a long time ago (when we did DeltaSpike and CouchDB as the
> very
> > >>>> first
> > >>>>> GIT repos at the ASF) and is perfectly fine as all this is based on
> > >>>>> cryptographically strong steps.
> > >>>>>>
> > >>>>>> LieGrue,
> > >>>>>> strub
> > >>>>>>
> > >>>>>>
> > >>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
> > >>>> <struberg@yahoo.de.INVALID
> > >>>>>> :
> > >>>>>>>
> > >>>>>>> Hi folks!
> > >>>>>>>
> > >>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
> > >>>>>>>
> > >>>>>>> So far I did
> > >>>>>>>
> > >>>>>>> * fix the missing parts in changes.xml
> > >>>>>>> * generate + copy the RELEASE_NOTES
> > >>>>>>> * run the maven release (after fixing the setup...)
> > >>>>>>>
> > >>>>>>> The ASF staging repository is at
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > >>>>>>>
> > >>>>>>> The source zip is at
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > >>>>>>> The sha1 of the source-release zip is
> > >>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > >>>>>>> The sha512 is
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> > >>>>>>>
> > >>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
> > >>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> > >>>>>>>
> > >>>>>>> I will now continue with the follow up steps and then call an
> > >>> official
> > >>>>> VOTE.
> > >>>>>>>
> > >>>>>>> Please let me know if something went wrong so far!
> > >>>>>>>
> > >>>>>>> LieGrue,
> > >>>>>>> strub
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>> ---------------------------------------------------------------------
> > >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >> ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Nov 19, 2018 at 5:22 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> Oki, I now see what you mean.
>
> We actually have 3 source zips now.
>
> .src.zip
> .source-release.zip
> src.jar
>
> That's a mess.
>
> There should only be 2:
> * source-release.zip is the official ASF packages whole build sources.
> This includes the pom, build structure etc.
> * src.jar is the sources which are automatically downloaded by the IDEs
> for debugging purpose.
>
Nope, it's the "-sources" jar that is used in IDEs. The "-src" jar is what
_should_ contain all sources needed to build the jar and site.
"source-release" is not something we've used here before IIRC.
Gary
>
> We have both of them because commons-pool2 is a single-module project.
> And yes, we need both of them. What we do not need is the src.zip. I have
> no clue yet where this comes from but it shouldn't be here.
>
>
> The good news:
> By leveraging native GIT we now can simply a.) drop the maven stating repo
> in repository.a.o and b.) drop the release branch and tag from my github
> account and re-roll the release without any weird RC hacks.
>
> Will do that,
> * fix the maven setup
> * happy to also include the new ticket
> * re-roll the release this afternoon.
>
> LieGrue,
> strub
>
> > Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com> a
> écrit :
> >
> >> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >> wrote:
> >>
> >>> Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com> a
> >> écrit
> >>> :
> >>>
> >>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> >> <struberg@yahoo.de.invalid
> >>>>
> >>>> wrote:
> >>>>
> >>>>> Oki, now the full VOTE text!
> >>>>>
> >>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> >>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
> >>>>>
> >>>>>
> >>>>> The ASF staging repository is at
> >>>>>
> >>>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>>>
> >>>>> The source zip is at
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>>>> The sha1 of the source-release zip is
> >>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>>>> The sha512 is
> >>>>>
> >>>>
> >>>
> >>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>>>
> >>>>
> >>>> For me:
> >>>>
> >>>> $ sha512sum commons-pool2-2.6.1-src.zip
> >>>>
> >>>>
> >>>
> >>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> >>>> *commons-pool2-2.6.1-src.zip
> >>>>
> >>>> Which is not what you list above. Please advise.
> >>>>
> >>>
> >>> Src vs source-release?
> >>>
> >>
> >> That's the problem with inventing a new release process... why do we
> have
> >> BOTH:
> >>
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> >> AND
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> >>
> >> And more importantly why are they _different_? Which one will be used in
> >> the dist/release area?
> >>
> >
> >
> > Looks like pool didnt do its homework and kept the old assembly (src),
> > source-release comes from the parent and is likely the one to keep IMHO
> >
> >
> >> Gary
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> Gary
> >>>>
> >>>>
> >>>>>
> >>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
> >>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>>>
> >>>>> I've created the release in a GIT manner and pushed the according
> >>> changes
> >>>>> to my ASF-linked github repo
> >>>>>
> >>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >>>>> the sha1 of the commit is
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>>>>
> >>>>> the tag is
> >>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >>>>> c910171
> >>>>> <
> >>>>
> >>
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> >>>>
> >>>>>
> >>>>> This will get pushed to the ASF cannonical repo once the VOTE
> >> succeeds.
> >>>>>
> >>>>> Site will be updated once the release has passed.
> >>>>>
> >>>>> Please VOTE:
> >>>>>
> >>>>> [+1] go ship it!
> >>>>> [+0] meh, I don't care
> >>>>> [-1] stop there is a ${showstopper} (that means something _important_
> >>> is
> >>>>> missing!)
> >>>>>
> >>>>>
> >>>>> Here is my own +1
> >>>>> checked:
> >>>>> * signature
> >>>>> * hashes
> >>>>> * LICENSE
> >>>>> * NOTICE
> >>>>> * rat
> >>>>> * builds fine with various JDKs
> >>>>>
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
> >>> <struberg@yahoo.de.INVALID
> >>>>>> :
> >>>>>>
> >>>>>> PS: I've created the release in a GIT manner and pushed the
> >> according
> >>>>> changes to my ASF-linked github repo
> >>>>>>
> >>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >>>>>> the sha1 of the commit is
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>>>>>
> >>>>>> the tag is
> >>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >>>>>> c910171
> >>>>>>
> >>>>>> This will get pushed to the ASF cannonical repo once the VOTE
> >>> succeeds.
> >>>>>> Yay, this is the way GIT works and before someone not familiar with
> >>> GIT
> >>>>> screams that this is not hosted on ASF: This got discussed on the
> >> board
> >>>>> level a long time ago (when we did DeltaSpike and CouchDB as the very
> >>>> first
> >>>>> GIT repos at the ASF) and is perfectly fine as all this is based on
> >>>>> cryptographically strong steps.
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>
> >>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
> >>>> <struberg@yahoo.de.INVALID
> >>>>>> :
> >>>>>>>
> >>>>>>> Hi folks!
> >>>>>>>
> >>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
> >>>>>>>
> >>>>>>> So far I did
> >>>>>>>
> >>>>>>> * fix the missing parts in changes.xml
> >>>>>>> * generate + copy the RELEASE_NOTES
> >>>>>>> * run the maven release (after fixing the setup...)
> >>>>>>>
> >>>>>>> The ASF staging repository is at
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>>>>>
> >>>>>>> The source zip is at
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>>>>>> The sha1 of the source-release zip is
> >>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>>>>>> The sha512 is
> >>>>>
> >>>>
> >>>
> >>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>>>>>
> >>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
> >>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>>>>>
> >>>>>>> I will now continue with the follow up steps and then call an
> >>> official
> >>>>> VOTE.
> >>>>>>>
> >>>>>>> Please let me know if something went wrong so far!
> >>>>>>>
> >>>>>>> LieGrue,
> >>>>>>> strub
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Oki, I now see what you mean.
We actually have 3 source zips now.
.src.zip
.source-release.zip
src.jar
That's a mess.
There should only be 2:
* source-release.zip is the official ASF packages whole build sources. This includes the pom, build structure etc.
* src.jar is the sources which are automatically downloaded by the IDEs for debugging purpose.
We have both of them because commons-pool2 is a single-module project.
And yes, we need both of them. What we do not need is the src.zip. I have no clue yet where this comes from but it shouldn't be here.
The good news:
By leveraging native GIT we now can simply a.) drop the maven stating repo in repository.a.o and b.) drop the release branch and tag from my github account and re-roll the release without any weird RC hacks.
Will do that,
* fix the maven setup
* happy to also include the new ticket
* re-roll the release this afternoon.
LieGrue,
strub
> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com> a écrit :
>
>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>>> Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com> a
>> écrit
>>> :
>>>
>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>> <struberg@yahoo.de.invalid
>>>>
>>>> wrote:
>>>>
>>>>> Oki, now the full VOTE text!
>>>>>
>>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>>>>>
>>>>>
>>>>> The ASF staging repository is at
>>>>>
>>>>
>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>
>>>>> The source zip is at
>>>>>
>>>>>
>>>>
>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>> The sha1 of the source-release zip is
>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>> The sha512 is
>>>>>
>>>>
>>>
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>
>>>>
>>>> For me:
>>>>
>>>> $ sha512sum commons-pool2-2.6.1-src.zip
>>>>
>>>>
>>>
>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
>>>> *commons-pool2-2.6.1-src.zip
>>>>
>>>> Which is not what you list above. Please advise.
>>>>
>>>
>>> Src vs source-release?
>>>
>>
>> That's the problem with inventing a new release process... why do we have
>> BOTH:
>>
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>> AND
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>>
>> And more importantly why are they _different_? Which one will be used in
>> the dist/release area?
>>
>
>
> Looks like pool didnt do its homework and kept the old assembly (src),
> source-release comes from the parent and is likely the one to keep IMHO
>
>
>> Gary
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>
>>>>> I've created the release in a GIT manner and pushed the according
>>> changes
>>>>> to my ASF-linked github repo
>>>>>
>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>> the sha1 of the commit is
>>>>>
>>>>>
>>>>
>>>
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>
>>>>> the tag is
>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>> c910171
>>>>> <
>>>>
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
>>>>
>>>>>
>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>> succeeds.
>>>>>
>>>>> Site will be updated once the release has passed.
>>>>>
>>>>> Please VOTE:
>>>>>
>>>>> [+1] go ship it!
>>>>> [+0] meh, I don't care
>>>>> [-1] stop there is a ${showstopper} (that means something _important_
>>> is
>>>>> missing!)
>>>>>
>>>>>
>>>>> Here is my own +1
>>>>> checked:
>>>>> * signature
>>>>> * hashes
>>>>> * LICENSE
>>>>> * NOTICE
>>>>> * rat
>>>>> * builds fine with various JDKs
>>>>>
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
>>> <struberg@yahoo.de.INVALID
>>>>>> :
>>>>>>
>>>>>> PS: I've created the release in a GIT manner and pushed the
>> according
>>>>> changes to my ASF-linked github repo
>>>>>>
>>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>>> the sha1 of the commit is
>>>>>>
>>>>>
>>>>
>>>
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>>>
>>>>>> the tag is
>>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>>> c910171
>>>>>>
>>>>>> This will get pushed to the ASF cannonical repo once the VOTE
>>> succeeds.
>>>>>> Yay, this is the way GIT works and before someone not familiar with
>>> GIT
>>>>> screams that this is not hosted on ASF: This got discussed on the
>> board
>>>>> level a long time ago (when we did DeltaSpike and CouchDB as the very
>>>> first
>>>>> GIT repos at the ASF) and is perfectly fine as all this is based on
>>>>> cryptographically strong steps.
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg
>>>> <struberg@yahoo.de.INVALID
>>>>>> :
>>>>>>>
>>>>>>> Hi folks!
>>>>>>>
>>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>>>>>
>>>>>>> So far I did
>>>>>>>
>>>>>>> * fix the missing parts in changes.xml
>>>>>>> * generate + copy the RELEASE_NOTES
>>>>>>> * run the maven release (after fixing the setup...)
>>>>>>>
>>>>>>> The ASF staging repository is at
>>>>>>>
>>>>>
>>>>
>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>
>>>>>>> The source zip is at
>>>>>>>
>>>>>
>>>>
>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>> The sha1 of the source-release zip is
>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>> The sha512 is
>>>>>
>>>>
>>>
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>>
>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>>
>>>>>>> I will now continue with the follow up steps and then call an
>>> official
>>>>> VOTE.
>>>>>>>
>>>>>>> Please let me know if something went wrong so far!
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 16 nov. 2018 22:54, Gary Gregory <ga...@gmail.com> a écrit :
> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com> a
> écrit
> > :
> >
> > > On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> <struberg@yahoo.de.invalid
> > >
> > > wrote:
> > >
> > > > Oki, now the full VOTE text!
> > > >
> > > > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > > > The release was run with JDK-1.7 to ensure Java7 compatibility.
> > > >
> > > >
> > > > The ASF staging repository is at
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > > >
> > > > The source zip is at
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > > > The sha1 of the source-release zip is
> > > > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > > > The sha512 is
> > > >
> > >
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> > > >
> > >
> > > For me:
> > >
> > > $ sha512sum commons-pool2-2.6.1-src.zip
> > >
> > >
> >
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> > > *commons-pool2-2.6.1-src.zip
> > >
> > > Which is not what you list above. Please advise.
> > >
> >
> > Src vs source-release?
> >
>
> That's the problem with inventing a new release process... why do we have
> BOTH:
>
>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> AND
>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>
> And more importantly why are they _different_? Which one will be used in
> the dist/release area?
>
Looks like pool didnt do its homework and kept the old assembly (src),
source-release comes from the parent and is likely the one to keep IMHO
> Gary
>
>
>
> >
> >
> >
> >
> >
> > > Gary
> > >
> > >
> > > >
> > > > I added my KEY (struberg at apache.org) to our dist KEYS file
> > > > https://dist.apache.org/repos/dist/release/commons/KEYS
> > > >
> > > > I've created the release in a GIT manner and pushed the according
> > changes
> > > > to my ASF-linked github repo
> > > >
> > > > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > > > the sha1 of the commit is
> > > >
> > > >
> > >
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> > > >
> > > > the tag is
> > > > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > > > c910171
> > > > <
> > >
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> > >
> > > >
> > > > This will get pushed to the ASF cannonical repo once the VOTE
> succeeds.
> > > >
> > > > Site will be updated once the release has passed.
> > > >
> > > > Please VOTE:
> > > >
> > > > [+1] go ship it!
> > > > [+0] meh, I don't care
> > > > [-1] stop there is a ${showstopper} (that means something _important_
> > is
> > > > missing!)
> > > >
> > > >
> > > > Here is my own +1
> > > > checked:
> > > > * signature
> > > > * hashes
> > > > * LICENSE
> > > > * NOTICE
> > > > * rat
> > > > * builds fine with various JDKs
> > > >
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > Am 14.11.2018 um 10:13 schrieb Mark Struberg
> > <struberg@yahoo.de.INVALID
> > > > >:
> > > > >
> > > > > PS: I've created the release in a GIT manner and pushed the
> according
> > > > changes to my ASF-linked github repo
> > > > >
> > > > > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > > > > the sha1 of the commit is
> > > > >
> > > >
> > >
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> > > > >
> > > > > the tag is
> > > > > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > > > > c910171
> > > > >
> > > > > This will get pushed to the ASF cannonical repo once the VOTE
> > succeeds.
> > > > > Yay, this is the way GIT works and before someone not familiar with
> > GIT
> > > > screams that this is not hosted on ASF: This got discussed on the
> board
> > > > level a long time ago (when we did DeltaSpike and CouchDB as the very
> > > first
> > > > GIT repos at the ASF) and is perfectly fine as all this is based on
> > > > cryptographically strong steps.
> > > > >
> > > > > LieGrue,
> > > > > strub
> > > > >
> > > > >
> > > > >> Am 14.11.2018 um 09:17 schrieb Mark Struberg
> > > <struberg@yahoo.de.INVALID
> > > > >:
> > > > >>
> > > > >> Hi folks!
> > > > >>
> > > > >> I'm currently preparing the release for commons-pool2-2.6.1
> > > > >>
> > > > >> So far I did
> > > > >>
> > > > >> * fix the missing parts in changes.xml
> > > > >> * generate + copy the RELEASE_NOTES
> > > > >> * run the maven release (after fixing the setup...)
> > > > >>
> > > > >> The ASF staging repository is at
> > > > >>
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > > > >>
> > > > >> The source zip is at
> > > > >>
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > > > >> The sha1 of the source-release zip is
> > > > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > > > >> The sha512 is
> > > >
> > >
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> > > > >>
> > > > >> I added my KEY (struberg at apache.org) to our dist KEYS file
> > > > >> https://dist.apache.org/repos/dist/release/commons/KEYS
> > > > >>
> > > > >> I will now continue with the follow up steps and then call an
> > official
> > > > VOTE.
> > > > >>
> > > > >> Please let me know if something went wrong so far!
> > > > >>
> > > > >> LieGrue,
> > > > >> strub
> > > > >>
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > >> For additional commands, e-mail: dev-help@commons.apache.org
> > > > >>
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> >
>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com> a écrit
> :
>
> > On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg <struberg@yahoo.de.invalid
> >
> > wrote:
> >
> > > Oki, now the full VOTE text!
> > >
> > > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > > The release was run with JDK-1.7 to ensure Java7 compatibility.
> > >
> > >
> > > The ASF staging repository is at
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > >
> > > The source zip is at
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > > The sha1 of the source-release zip is
> > > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > > The sha512 is
> > >
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> > >
> >
> > For me:
> >
> > $ sha512sum commons-pool2-2.6.1-src.zip
> >
> >
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> > *commons-pool2-2.6.1-src.zip
> >
> > Which is not what you list above. Please advise.
> >
>
> Src vs source-release?
>
That's the problem with inventing a new release process... why do we have
BOTH:
https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
AND
https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
And more importantly why are they _different_? Which one will be used in
the dist/release area?
Gary
>
>
>
>
>
> > Gary
> >
> >
> > >
> > > I added my KEY (struberg at apache.org) to our dist KEYS file
> > > https://dist.apache.org/repos/dist/release/commons/KEYS
> > >
> > > I've created the release in a GIT manner and pushed the according
> changes
> > > to my ASF-linked github repo
> > >
> > > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > > the sha1 of the commit is
> > >
> > >
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> > >
> > > the tag is
> > > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > > c910171
> > > <
> > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> >
> > >
> > > This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> > >
> > > Site will be updated once the release has passed.
> > >
> > > Please VOTE:
> > >
> > > [+1] go ship it!
> > > [+0] meh, I don't care
> > > [-1] stop there is a ${showstopper} (that means something _important_
> is
> > > missing!)
> > >
> > >
> > > Here is my own +1
> > > checked:
> > > * signature
> > > * hashes
> > > * LICENSE
> > > * NOTICE
> > > * rat
> > > * builds fine with various JDKs
> > >
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > >
> > > > Am 14.11.2018 um 10:13 schrieb Mark Struberg
> <struberg@yahoo.de.INVALID
> > > >:
> > > >
> > > > PS: I've created the release in a GIT manner and pushed the according
> > > changes to my ASF-linked github repo
> > > >
> > > > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > > > the sha1 of the commit is
> > > >
> > >
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> > > >
> > > > the tag is
> > > > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > > > c910171
> > > >
> > > > This will get pushed to the ASF cannonical repo once the VOTE
> succeeds.
> > > > Yay, this is the way GIT works and before someone not familiar with
> GIT
> > > screams that this is not hosted on ASF: This got discussed on the board
> > > level a long time ago (when we did DeltaSpike and CouchDB as the very
> > first
> > > GIT repos at the ASF) and is perfectly fine as all this is based on
> > > cryptographically strong steps.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >
> > > >> Am 14.11.2018 um 09:17 schrieb Mark Struberg
> > <struberg@yahoo.de.INVALID
> > > >:
> > > >>
> > > >> Hi folks!
> > > >>
> > > >> I'm currently preparing the release for commons-pool2-2.6.1
> > > >>
> > > >> So far I did
> > > >>
> > > >> * fix the missing parts in changes.xml
> > > >> * generate + copy the RELEASE_NOTES
> > > >> * run the maven release (after fixing the setup...)
> > > >>
> > > >> The ASF staging repository is at
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > > >>
> > > >> The source zip is at
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > > >> The sha1 of the source-release zip is
> > > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > > >> The sha512 is
> > >
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> > > >>
> > > >> I added my KEY (struberg at apache.org) to our dist KEYS file
> > > >> https://dist.apache.org/repos/dist/release/commons/KEYS
> > > >>
> > > >> I will now continue with the follow up steps and then call an
> official
> > > VOTE.
> > > >>
> > > >> Please let me know if something went wrong so far!
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > >> For additional commands, e-mail: dev-help@commons.apache.org
> > > >>
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 16 nov. 2018 21:23, Gary Gregory <ga...@gmail.com> a écrit :
> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg <st...@yahoo.de.invalid>
> wrote:
>
> > Oki, now the full VOTE text!
> >
> > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > The release was run with JDK-1.7 to ensure Java7 compatibility.
> >
> >
> > The ASF staging repository is at
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >
> > The source zip is at
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > The sha1 of the source-release zip is
> > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > The sha512 is
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >
>
> For me:
>
> $ sha512sum commons-pool2-2.6.1-src.zip
>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> *commons-pool2-2.6.1-src.zip
>
> Which is not what you list above. Please advise.
>
Src vs source-release?
> Gary
>
>
> >
> > I added my KEY (struberg at apache.org) to our dist KEYS file
> > https://dist.apache.org/repos/dist/release/commons/KEYS
> >
> > I've created the release in a GIT manner and pushed the according changes
> > to my ASF-linked github repo
> >
> > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > the sha1 of the commit is
> >
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >
> > the tag is
> > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > c910171
> > <
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171>
> >
> > This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> >
> > Site will be updated once the release has passed.
> >
> > Please VOTE:
> >
> > [+1] go ship it!
> > [+0] meh, I don't care
> > [-1] stop there is a ${showstopper} (that means something _important_ is
> > missing!)
> >
> >
> > Here is my own +1
> > checked:
> > * signature
> > * hashes
> > * LICENSE
> > * NOTICE
> > * rat
> > * builds fine with various JDKs
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >
> > > Am 14.11.2018 um 10:13 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> > >:
> > >
> > > PS: I've created the release in a GIT manner and pushed the according
> > changes to my ASF-linked github repo
> > >
> > > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > > the sha1 of the commit is
> > >
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> > >
> > > the tag is
> > > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > > c910171
> > >
> > > This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> > > Yay, this is the way GIT works and before someone not familiar with GIT
> > screams that this is not hosted on ASF: This got discussed on the board
> > level a long time ago (when we did DeltaSpike and CouchDB as the very
> first
> > GIT repos at the ASF) and is perfectly fine as all this is based on
> > cryptographically strong steps.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >> Am 14.11.2018 um 09:17 schrieb Mark Struberg
> <struberg@yahoo.de.INVALID
> > >:
> > >>
> > >> Hi folks!
> > >>
> > >> I'm currently preparing the release for commons-pool2-2.6.1
> > >>
> > >> So far I did
> > >>
> > >> * fix the missing parts in changes.xml
> > >> * generate + copy the RELEASE_NOTES
> > >> * run the maven release (after fixing the setup...)
> > >>
> > >> The ASF staging repository is at
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > >>
> > >> The source zip is at
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > >> The sha1 of the source-release zip is
> > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > >> The sha512 is
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> > >>
> > >> I added my KEY (struberg at apache.org) to our dist KEYS file
> > >> https://dist.apache.org/repos/dist/release/commons/KEYS
> > >>
> > >> I will now continue with the follow up steps and then call an official
> > VOTE.
> > >>
> > >> Please let me know if something went wrong so far!
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> Oki, now the full VOTE text!
>
> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> The release was run with JDK-1.7 to ensure Java7 compatibility.
>
>
> The ASF staging repository is at
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>
> The source zip is at
>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>
For me:
$ sha512sum commons-pool2-2.6.1-src.zip
2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
*commons-pool2-2.6.1-src.zip
Which is not what you list above. Please advise.
Gary
>
> I added my KEY (struberg at apache.org) to our dist KEYS file
> https://dist.apache.org/repos/dist/release/commons/KEYS
>
> I've created the release in a GIT manner and pushed the according changes
> to my ASF-linked github repo
>
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> the sha1 of the commit is
>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>
> the tag is
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> c910171
> <https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171>
>
> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
>
> Site will be updated once the release has passed.
>
> Please VOTE:
>
> [+1] go ship it!
> [+0] meh, I don't care
> [-1] stop there is a ${showstopper} (that means something _important_ is
> missing!)
>
>
> Here is my own +1
> checked:
> * signature
> * hashes
> * LICENSE
> * NOTICE
> * rat
> * builds fine with various JDKs
>
>
> LieGrue,
> strub
>
>
>
>
>
> > Am 14.11.2018 um 10:13 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> >:
> >
> > PS: I've created the release in a GIT manner and pushed the according
> changes to my ASF-linked github repo
> >
> > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > the sha1 of the commit is
> >
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >
> > the tag is
> > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > c910171
> >
> > This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> > Yay, this is the way GIT works and before someone not familiar with GIT
> screams that this is not hosted on ASF: This got discussed on the board
> level a long time ago (when we did DeltaSpike and CouchDB as the very first
> GIT repos at the ASF) and is perfectly fine as all this is based on
> cryptographically strong steps.
> >
> > LieGrue,
> > strub
> >
> >
> >> Am 14.11.2018 um 09:17 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> >:
> >>
> >> Hi folks!
> >>
> >> I'm currently preparing the release for commons-pool2-2.6.1
> >>
> >> So far I did
> >>
> >> * fix the missing parts in changes.xml
> >> * generate + copy the RELEASE_NOTES
> >> * run the maven release (after fixing the setup...)
> >>
> >> The ASF staging repository is at
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>
> >> The source zip is at
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >> The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >> The sha512 is
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>
> >> I added my KEY (struberg at apache.org) to our dist KEYS file
> >> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>
> >> I will now continue with the follow up steps and then call an official
> VOTE.
> >>
> >> Please let me know if something went wrong so far!
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Oki, now the full VOTE text!
I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
The release was run with JDK-1.7 to ensure Java7 compatibility.
The ASF staging repository is at
https://repository.apache.org/content/repositories/orgapachecommons-1396/
The source zip is at
https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
The sha512 is 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
I added my KEY (struberg at apache.org) to our dist KEYS file
https://dist.apache.org/repos/dist/release/commons/KEYS
I've created the release in a GIT manner and pushed the according changes to my ASF-linked github repo
https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
the sha1 of the commit is
https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
the tag is
https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
c910171
This will get pushed to the ASF cannonical repo once the VOTE succeeds.
Site will be updated once the release has passed.
Please VOTE:
[+1] go ship it!
[+0] meh, I don't care
[-1] stop there is a ${showstopper} (that means something _important_ is missing!)
Here is my own +1
checked:
* signature
* hashes
* LICENSE
* NOTICE
* rat
* builds fine with various JDKs
LieGrue,
strub
> Am 14.11.2018 um 10:13 schrieb Mark Struberg <st...@yahoo.de.INVALID>:
>
> PS: I've created the release in a GIT manner and pushed the according changes to my ASF-linked github repo
>
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> the sha1 of the commit is
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>
> the tag is
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> c910171
>
> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> Yay, this is the way GIT works and before someone not familiar with GIT screams that this is not hosted on ASF: This got discussed on the board level a long time ago (when we did DeltaSpike and CouchDB as the very first GIT repos at the ASF) and is perfectly fine as all this is based on cryptographically strong steps.
>
> LieGrue,
> strub
>
>
>> Am 14.11.2018 um 09:17 schrieb Mark Struberg <st...@yahoo.de.INVALID>:
>>
>> Hi folks!
>>
>> I'm currently preparing the release for commons-pool2-2.6.1
>>
>> So far I did
>>
>> * fix the missing parts in changes.xml
>> * generate + copy the RELEASE_NOTES
>> * run the maven release (after fixing the setup...)
>>
>> The ASF staging repository is at
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>
>> The source zip is at
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>> The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>> The sha512 is 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>
>> I added my KEY (struberg at apache.org) to our dist KEYS file
>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>
>> I will now continue with the follow up steps and then call an official VOTE.
>>
>> Please let me know if something went wrong so far!
>>
>> LieGrue,
>> strub
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
PS: I've created the release in a GIT manner and pushed the according changes to my ASF-linked github repo
https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
the sha1 of the commit is
https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
the tag is
https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
c910171
This will get pushed to the ASF cannonical repo once the VOTE succeeds.
Yay, this is the way GIT works and before someone not familiar with GIT screams that this is not hosted on ASF: This got discussed on the board level a long time ago (when we did DeltaSpike and CouchDB as the very first GIT repos at the ASF) and is perfectly fine as all this is based on cryptographically strong steps.
LieGrue,
strub
> Am 14.11.2018 um 09:17 schrieb Mark Struberg <st...@yahoo.de.INVALID>:
>
> Hi folks!
>
> I'm currently preparing the release for commons-pool2-2.6.1
>
> So far I did
>
> * fix the missing parts in changes.xml
> * generate + copy the RELEASE_NOTES
> * run the maven release (after fixing the setup...)
>
> The ASF staging repository is at
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>
> The source zip is at
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>
> I added my KEY (struberg at apache.org) to our dist KEYS file
> https://dist.apache.org/repos/dist/release/commons/KEYS
>
> I will now continue with the follow up steps and then call an official VOTE.
>
> Please let me know if something went wrong so far!
>
> LieGrue,
> strub
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Rob Tompkins <ch...@gmail.com>.
> On Nov 22, 2018, at 1:11 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Thu, Nov 22, 2018 at 10:08 AM Rob Tompkins <chtompki@gmail.com <ma...@gmail.com>> wrote:
>
>>
>>
>>> On Nov 22, 2018, at 11:49 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>
>>> On Fri, Nov 16, 2018 at 2:55 PM Gary Gregory <ga...@gmail.com>
>> wrote:
>>>
>>>> Should we cancel this RC to include:
>>>>
>>>> https://issues.apache.org/jira/browse/POOL-359
>>>>
>>>
>>> This is now in git master.
>>>
>>> Feel free to roll RC3.
>>
>> Who’s on for this one? Is it me or Mark?
>>
>
> If you have the time, go for it :-)
>
> Can you make sure that Commons DBCP git master builds and tests OK with
> Commons Pool 2.6.1-SNAPSHOT as part of the release?
Thanks for making that validation easy for me….so far so good on:
mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T14:33:14-04:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.1", arch: "x86_64", family: "mac"
>
> Thank you!
> Gary
>
>
>>
>> -Rob
>>
>>
>>>
>>> Gary
>>>
>>>>
>>>>
>>>> ?
>>>>
>>>> Gary
>>>>
>>>> On Wed, Nov 14, 2018 at 1:17 AM Mark Struberg <struberg@yahoo.de.invalid
>>>
>>>> wrote:
>>>>
>>>>> Hi folks!
>>>>>
>>>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>>>
>>>>> So far I did
>>>>>
>>>>> * fix the missing parts in changes.xml
>>>>> * generate + copy the RELEASE_NOTES
>>>>> * run the maven release (after fixing the setup...)
>>>>>
>>>>> The ASF staging repository is at
>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>
>>>>> The source zip is at
>>>>>
>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>> The sha1 of the source-release zip is
>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>> The sha512 is
>>>>>
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>
>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>
>>>>> I will now continue with the follow up steps and then call an official
>>>>> VOTE.
>>>>>
>>>>> Please let me know if something went wrong so far!
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Rob Tompkins <ch...@gmail.com>.
> On Nov 22, 2018, at 3:26 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Thu, Nov 22, 2018, 12:55 Rob Tompkins <chtompki@gmail.com wrote:
>>
>> Yeah. I can try to start pulling that together between now and tomorrow
>> sort of time frame.
>
>
> Enjoy the turkey!
>
Thanks. You too.
> Gary
>
>
>>> On Nov 22, 2018, at 1:11 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>
>>>> On Thu, Nov 22, 2018 at 10:08 AM Rob Tompkins <ch...@gmail.com>
>> wrote:
>>>>
>>>>
>>>>
>>>>> On Nov 22, 2018, at 11:49 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Fri, Nov 16, 2018 at 2:55 PM Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> Should we cancel this RC to include:
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/POOL-359
>>>>>>
>>>>>
>>>>> This is now in git master.
>>>>>
>>>>> Feel free to roll RC3.
>>>>
>>>> Who’s on for this one? Is it me or Mark?
>>>>
>>>
>>> If you have the time, go for it :-)
>>>
>>> Can you make sure that Commons DBCP git master builds and tests OK with
>>> Commons Pool 2.6.1-SNAPSHOT as part of the release?
>>>
>>> Thank you!
>>> Gary
>>>
>>>
>>>>
>>>> -Rob
>>>>
>>>>
>>>>>
>>>>> Gary
>>>>>
>>>>>>
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Wed, Nov 14, 2018 at 1:17 AM Mark Struberg
>> <struberg@yahoo.de.invalid
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi folks!
>>>>>>>
>>>>>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>>>>>
>>>>>>> So far I did
>>>>>>>
>>>>>>> * fix the missing parts in changes.xml
>>>>>>> * generate + copy the RELEASE_NOTES
>>>>>>> * run the maven release (after fixing the setup...)
>>>>>>>
>>>>>>> The ASF staging repository is at
>>>>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>
>>>>>>> The source zip is at
>>>>>>>
>>>>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>> The sha1 of the source-release zip is
>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>> The sha512 is
>>>>>>>
>>>>
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>>>
>>>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>>>
>>>>>>> I will now continue with the follow up steps and then call an
>> official
>>>>>>> VOTE.
>>>>>>>
>>>>>>> Please let me know if something went wrong so far!
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Nov 22, 2018, 12:55 Rob Tompkins <chtompki@gmail.com wrote:
> Yeah. I can try to start pulling that together between now and tomorrow
> sort of time frame.
Enjoy the turkey!
Gary
> > On Nov 22, 2018, at 1:11 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> >> On Thu, Nov 22, 2018 at 10:08 AM Rob Tompkins <ch...@gmail.com>
> wrote:
> >>
> >>
> >>
> >>> On Nov 22, 2018, at 11:49 AM, Gary Gregory <ga...@gmail.com>
> >> wrote:
> >>>
> >>> On Fri, Nov 16, 2018 at 2:55 PM Gary Gregory <ga...@gmail.com>
> >> wrote:
> >>>
> >>>> Should we cancel this RC to include:
> >>>>
> >>>> https://issues.apache.org/jira/browse/POOL-359
> >>>>
> >>>
> >>> This is now in git master.
> >>>
> >>> Feel free to roll RC3.
> >>
> >> Who’s on for this one? Is it me or Mark?
> >>
> >
> > If you have the time, go for it :-)
> >
> > Can you make sure that Commons DBCP git master builds and tests OK with
> > Commons Pool 2.6.1-SNAPSHOT as part of the release?
> >
> > Thank you!
> > Gary
> >
> >
> >>
> >> -Rob
> >>
> >>
> >>>
> >>> Gary
> >>>
> >>>>
> >>>>
> >>>> ?
> >>>>
> >>>> Gary
> >>>>
> >>>> On Wed, Nov 14, 2018 at 1:17 AM Mark Struberg
> <struberg@yahoo.de.invalid
> >>>
> >>>> wrote:
> >>>>
> >>>>> Hi folks!
> >>>>>
> >>>>> I'm currently preparing the release for commons-pool2-2.6.1
> >>>>>
> >>>>> So far I did
> >>>>>
> >>>>> * fix the missing parts in changes.xml
> >>>>> * generate + copy the RELEASE_NOTES
> >>>>> * run the maven release (after fixing the setup...)
> >>>>>
> >>>>> The ASF staging repository is at
> >>>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>>>
> >>>>> The source zip is at
> >>>>>
> >>>>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>>>> The sha1 of the source-release zip is
> >>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>>>> The sha512 is
> >>>>>
> >>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>>>
> >>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
> >>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>>>
> >>>>> I will now continue with the follow up steps and then call an
> official
> >>>>> VOTE.
> >>>>>
> >>>>> Please let me know if something went wrong so far!
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Rob Tompkins <ch...@gmail.com>.
Yeah. I can try to start pulling that together between now and tomorrow sort of time frame.
> On Nov 22, 2018, at 1:11 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Thu, Nov 22, 2018 at 10:08 AM Rob Tompkins <ch...@gmail.com> wrote:
>>
>>
>>
>>> On Nov 22, 2018, at 11:49 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>
>>> On Fri, Nov 16, 2018 at 2:55 PM Gary Gregory <ga...@gmail.com>
>> wrote:
>>>
>>>> Should we cancel this RC to include:
>>>>
>>>> https://issues.apache.org/jira/browse/POOL-359
>>>>
>>>
>>> This is now in git master.
>>>
>>> Feel free to roll RC3.
>>
>> Who’s on for this one? Is it me or Mark?
>>
>
> If you have the time, go for it :-)
>
> Can you make sure that Commons DBCP git master builds and tests OK with
> Commons Pool 2.6.1-SNAPSHOT as part of the release?
>
> Thank you!
> Gary
>
>
>>
>> -Rob
>>
>>
>>>
>>> Gary
>>>
>>>>
>>>>
>>>> ?
>>>>
>>>> Gary
>>>>
>>>> On Wed, Nov 14, 2018 at 1:17 AM Mark Struberg <struberg@yahoo.de.invalid
>>>
>>>> wrote:
>>>>
>>>>> Hi folks!
>>>>>
>>>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>>>
>>>>> So far I did
>>>>>
>>>>> * fix the missing parts in changes.xml
>>>>> * generate + copy the RELEASE_NOTES
>>>>> * run the maven release (after fixing the setup...)
>>>>>
>>>>> The ASF staging repository is at
>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>
>>>>> The source zip is at
>>>>>
>>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>> The sha1 of the source-release zip is
>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>> The sha512 is
>>>>>
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>>
>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>>
>>>>> I will now continue with the follow up steps and then call an official
>>>>> VOTE.
>>>>>
>>>>> Please let me know if something went wrong so far!
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Nov 22, 2018 at 10:08 AM Rob Tompkins <ch...@gmail.com> wrote:
>
>
> > On Nov 22, 2018, at 11:49 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > On Fri, Nov 16, 2018 at 2:55 PM Gary Gregory <ga...@gmail.com>
> wrote:
> >
> >> Should we cancel this RC to include:
> >>
> >> https://issues.apache.org/jira/browse/POOL-359
> >>
> >
> > This is now in git master.
> >
> > Feel free to roll RC3.
>
> Who’s on for this one? Is it me or Mark?
>
If you have the time, go for it :-)
Can you make sure that Commons DBCP git master builds and tests OK with
Commons Pool 2.6.1-SNAPSHOT as part of the release?
Thank you!
Gary
>
> -Rob
>
>
> >
> > Gary
> >
> >>
> >>
> >> ?
> >>
> >> Gary
> >>
> >> On Wed, Nov 14, 2018 at 1:17 AM Mark Struberg <struberg@yahoo.de.invalid
> >
> >> wrote:
> >>
> >>> Hi folks!
> >>>
> >>> I'm currently preparing the release for commons-pool2-2.6.1
> >>>
> >>> So far I did
> >>>
> >>> * fix the missing parts in changes.xml
> >>> * generate + copy the RELEASE_NOTES
> >>> * run the maven release (after fixing the setup...)
> >>>
> >>> The ASF staging repository is at
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>>
> >>> The source zip is at
> >>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >>> The sha1 of the source-release zip is
> >>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >>> The sha512 is
> >>>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>>
> >>> I added my KEY (struberg at apache.org) to our dist KEYS file
> >>> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>
> >>> I will now continue with the follow up steps and then call an official
> >>> VOTE.
> >>>
> >>> Please let me know if something went wrong so far!
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Rob Tompkins <ch...@gmail.com>.
> On Nov 22, 2018, at 11:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Fri, Nov 16, 2018 at 2:55 PM Gary Gregory <ga...@gmail.com> wrote:
>
>> Should we cancel this RC to include:
>>
>> https://issues.apache.org/jira/browse/POOL-359
>>
>
> This is now in git master.
>
> Feel free to roll RC3.
Who’s on for this one? Is it me or Mark?
-Rob
>
> Gary
>
>>
>>
>> ?
>>
>> Gary
>>
>> On Wed, Nov 14, 2018 at 1:17 AM Mark Struberg <st...@yahoo.de.invalid>
>> wrote:
>>
>>> Hi folks!
>>>
>>> I'm currently preparing the release for commons-pool2-2.6.1
>>>
>>> So far I did
>>>
>>> * fix the missing parts in changes.xml
>>> * generate + copy the RELEASE_NOTES
>>> * run the maven release (after fixing the setup...)
>>>
>>> The ASF staging repository is at
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>
>>> The source zip is at
>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>> The sha1 of the source-release zip is
>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>> The sha512 is
>>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>
>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>
>>> I will now continue with the follow up steps and then call an official
>>> VOTE.
>>>
>>> Please let me know if something went wrong so far!
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 16, 2018 at 2:55 PM Gary Gregory <ga...@gmail.com> wrote:
> Should we cancel this RC to include:
>
> https://issues.apache.org/jira/browse/POOL-359
>
This is now in git master.
Feel free to roll RC3.
Gary
>
>
> ?
>
> Gary
>
> On Wed, Nov 14, 2018 at 1:17 AM Mark Struberg <st...@yahoo.de.invalid>
> wrote:
>
>> Hi folks!
>>
>> I'm currently preparing the release for commons-pool2-2.6.1
>>
>> So far I did
>>
>> * fix the missing parts in changes.xml
>> * generate + copy the RELEASE_NOTES
>> * run the maven release (after fixing the setup...)
>>
>> The ASF staging repository is at
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>
>> The source zip is at
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>> The sha1 of the source-release zip is
>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>> The sha512 is
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>
>> I added my KEY (struberg at apache.org) to our dist KEYS file
>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>
>> I will now continue with the follow up steps and then call an official
>> VOTE.
>>
>> Please let me know if something went wrong so far!
>>
>> LieGrue,
>> strub
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
Re: [VOTE] Release Apache Commons Pool2 2.6.1
Posted by Gary Gregory <ga...@gmail.com>.
Should we cancel this RC to include:
https://issues.apache.org/jira/browse/POOL-359
?
Gary
On Wed, Nov 14, 2018 at 1:17 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> Hi folks!
>
> I'm currently preparing the release for commons-pool2-2.6.1
>
> So far I did
>
> * fix the missing parts in changes.xml
> * generate + copy the RELEASE_NOTES
> * run the maven release (after fixing the setup...)
>
> The ASF staging repository is at
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>
> The source zip is at
>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>
> I added my KEY (struberg at apache.org) to our dist KEYS file
> https://dist.apache.org/repos/dist/release/commons/KEYS
>
> I will now continue with the follow up steps and then call an official
> VOTE.
>
> Please let me know if something went wrong so far!
>
> LieGrue,
> strub
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>