Re: [build-plugin] Re-engineering/release streamlining

[Chas Honton]

Take a look at how the maven team votes and publishes

Chas

> On Nov 11, 2017, at 8:26 PM, Matt Benson  wrote:
> 
> On Nov 11, 2017 9:32 PM, "Rob Tompkins"  wrote:
> 
> 
> 
>>> On Nov 11, 2017, at 10:24 PM, Gary Gregory  wrote:
>>> 
>>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins  wrote:
>>> 
>>> Hello all,
>>> 
>>> I was wondering if we might think about a 2.X line in the [build-plugin]
>>> to better facilitate our release mechanics so that we don’t have to jump
>>> through all of these hoops that we do when building a release candidate?
>>> 
>>> Steps:
>>> 1. Move the commons-build-plugin to git.
>>> 
>> 
>> +1
>> 
>> 
>>> 2. Fully rewrite it so that it retains its site/github templating, but
>>> adds functionality to perform our releases in git (maybe withholding svn
> on
>>> purpose to incentivize moving repositories to git).
>>> 
>>> Thoughts?
>>> 
>> 
>> I agree, it's a pain. I wonder if we should step back first and see if we
>> can simplify our release requirements. For example, I find it a huge pain
>> that we have to release to both Nexus and the dist folder. I wonder if we
>> could get away with putting ALL we need in Nexus. After it's all on Apache
>> infra...
>> 
> 
> 
> I'm going to go out on a limb and say this won't fly. BUT there is no
> reason we can't script all this kind of stuff to our hearts' content.
> 
> Matt
> 
> 
> Sure. What’s the process for changing the requirements? Proposal...vote? I
> can try to work from the existent requirements, trim some fat, and bring it
> back for edits.
> 
> -Rob
> 
>> Gary
>> 
>> 
>>> 
>>> Cheers,
>>> -Rob
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [build-plugin] Re-engineering/release streamlining

[Matt Benson]

On Nov 11, 2017 9:32 PM, "Rob Tompkins"  wrote:



> On Nov 11, 2017, at 10:24 PM, Gary Gregory  wrote:
>
>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins  wrote:
>>
>> Hello all,
>>
>> I was wondering if we might think about a 2.X line in the [build-plugin]
>> to better facilitate our release mechanics so that we don’t have to jump
>> through all of these hoops that we do when building a release candidate?
>>
>> Steps:
>> 1. Move the commons-build-plugin to git.
>>
>
> +1
>
>
>> 2. Fully rewrite it so that it retains its site/github templating, but
>> adds functionality to perform our releases in git (maybe withholding svn
on
>> purpose to incentivize moving repositories to git).
>>
>> Thoughts?
>>
>
> I agree, it's a pain. I wonder if we should step back first and see if we
> can simplify our release requirements. For example, I find it a huge pain
> that we have to release to both Nexus and the dist folder. I wonder if we
> could get away with putting ALL we need in Nexus. After it's all on Apache
> infra...
>


I'm going to go out on a limb and say this won't fly. BUT there is no
reason we can't script all this kind of stuff to our hearts' content.

Matt


Sure. What’s the process for changing the requirements? Proposal...vote? I
can try to work from the existent requirements, trim some fat, and bring it
back for edits.

-Rob

> Gary
>
>
>>
>> Cheers,
>> -Rob
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

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

Re: [build-plugin] Re-engineering/release streamlining

[Rob Tompkins]

> On Nov 11, 2017, at 10:24 PM, Gary Gregory  wrote:
> 
>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins  wrote:
>> 
>> Hello all,
>> 
>> I was wondering if we might think about a 2.X line in the [build-plugin]
>> to better facilitate our release mechanics so that we don’t have to jump
>> through all of these hoops that we do when building a release candidate?
>> 
>> Steps:
>> 1. Move the commons-build-plugin to git.
>> 
> 
> +1
> 
> 
>> 2. Fully rewrite it so that it retains its site/github templating, but
>> adds functionality to perform our releases in git (maybe withholding svn on
>> purpose to incentivize moving repositories to git).
>> 
>> Thoughts?
>> 
> 
> I agree, it's a pain. I wonder if we should step back first and see if we
> can simplify our release requirements. For example, I find it a huge pain
> that we have to release to both Nexus and the dist folder. I wonder if we
> could get away with putting ALL we need in Nexus. After it's all on Apache
> infra...
> 

Sure. What’s the process for changing the requirements? Proposal...vote? I can 
try to work from the existent requirements, trim some fat, and bring it back 
for edits.

-Rob

> Gary
> 
> 
>> 
>> Cheers,
>> -Rob
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 

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

Re: [build-plugin] Re-engineering/release streamlining

[Gary Gregory]

On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins  wrote:

> Hello all,
>
> I was wondering if we might think about a 2.X line in the [build-plugin]
> to better facilitate our release mechanics so that we don’t have to jump
> through all of these hoops that we do when building a release candidate?
>
> Steps:
> 1. Move the commons-build-plugin to git.
>

+1


> 2. Fully rewrite it so that it retains its site/github templating, but
> adds functionality to perform our releases in git (maybe withholding svn on
> purpose to incentivize moving repositories to git).
>
> Thoughts?
>

I agree, it's a pain. I wonder if we should step back first and see if we
can simplify our release requirements. For example, I find it a huge pain
that we have to release to both Nexus and the dist folder. I wonder if we
could get away with putting ALL we need in Nexus. After it's all on Apache
infra...

Gary


>
> Cheers,
> -Rob
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[build-plugin] Re-engineering/release streamlining

[Rob Tompkins]

Hello all,

I was wondering if we might think about a 2.X line in the [build-plugin] to 
better facilitate our release mechanics so that we don’t have to jump through 
all of these hoops that we do when building a release candidate?

Steps:
1. Move the commons-build-plugin to git.
2. Fully rewrite it so that it retains its site/github templating, but adds 
functionality to perform our releases in git (maybe withholding svn on purpose 
to incentivize moving repositories to git).

Thoughts?

Cheers,
-Rob



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

Re: [dbcp] update to pool 2.4.3.

[Matt Sicker]

The last time I tried to RM a Commons project, I had a lot of blockers. I'm
not sure if they were all resolved.

Anyways, I may have time to try that out tomorrow. Otherwise, most of this
week is taken up by a hackathon going on at work.

On 11 November 2017 at 14:57, Gary Gregory  wrote:

> I was able to build master commons-dbcp based on commons-pool2
> master/2.5.0-SNAPSHOT. All tests pass in both builds :-)
>
> Do you have time to push out a release commons-pool2 release? A branch for
> 2.4.4 or master for 2.5.0, either way would be OK with me.
>
> Gary
>
> On Fri, Nov 10, 2017 at 2:17 PM, Matt Sicker  wrote:
>
> > Oh, I may have missed that since it didn't follow the naming scheme of
> all
> > the other tags.
> >
> > On 10 November 2017 at 13:33, Gary Gregory 
> wrote:
> >
> > > I mean "Hi Matt" !
> > >
> > > On Fri, Nov 10, 2017 at 12:32 PM, Gary Gregory  >
> > > wrote:
> > >
> > > > Hi Amtt,
> > > >
> > > > The tags are:
> > > >
> > > > POOL_2.4.3
> > > > POOL_2.4.3-RC1
> > > >
> > > > Gary
> > > >
> > > > On Fri, Nov 10, 2017 at 10:40 AM, Matt Sicker 
> > wrote:
> > > >
> > > >> Added in https://issues.apache.org/jira/browse/POOL-335
> > > >>
> > > >> There's no git tag for 2.4.3, so I can't really even find a way to
> > > >> backport
> > > >> the option as it is.
> > > >>
> > > >> On 5 November 2017 at 22:01, Matt Sicker  wrote:
> > > >>
> > > >> > I probably can, yeah. Totally slipped my mind about this, though!
> > > >> >
> > > >> > On 5 November 2017 at 21:46, Gary Gregory  >
> > > >> wrote:
> > > >> >
> > > >> >> Hi Matt,
> > > >> >>
> > > >> >> Any chance you get take a look this week?
> > > >> >>
> > > >> >> Gary
> > > >> >>
> > > >> >> On Tue, Oct 31, 2017 at 10:58 AM, Mark Thomas 
> > > >> wrote:
> > > >> >>
> > > >> >> > On 31/10/17 14:44, Gary Gregory wrote:
> > > >> >> > > On Tue, Oct 31, 2017 at 8:33 AM, Matt Sicker <
> boa...@gmail.com
> > >
> > > >> >> wrote:
> > > >> >> > >
> > > >> >> > >> On 31 October 2017 at 04:21, Mark Thomas 
> > > >> wrote:
> > > >> >> > >>>
> > > >> >> > >>> If the methods are required then that makes 2.4.3 broken in
> > my
> > > >> >> view. In
> > > >> >> > >>> which case we should wait for 2.4.4 before updating the
> > version
> > > >> DBCP
> > > >> >> > >>> depends on. I don't think we should adapt the test. The
> test
> > is
> > > >> >> telling
> > > >> >> > >>> us something is broken. We should fix the root cause not
> > change
> > > >> the
> > > >> >> > test.
> > > >> >> > >>>
> > > >> >> > >>
> > > >> >> > >> Regarding this, if the method names were expected in the
> > output,
> > > >> >> then a
> > > >> >> > >> unit test should have existed to verify that. The existing
> > test
> > > >> was
> > > >> >> only
> > > >> >> > >> checking for class names, so I'm assuming that's why I made
> > the
> > > >> >> change a
> > > >> >> > >> while back to optimize it for that use case. I think I asked
> > on
> > > >> the
> > > >> >> > mailing
> > > >> >> > >> lists first, but that was a while ago.
> > > >> >> > >>
> > > >> >> > >
> > > >> >> > > It sounds like the missing unit test in [pool] was actually
> in
> > > >> [dbcp]!
> > > >> >> > :-p
> > > >> >> > >
> > > >> >> > > Matt or Mark, would you mind pitching in to fill out this
> > missing
> > > >> >> test?
> > > >> >> >
> > > >> >> > I'll help out when I can but I'm heads down working through the
> > > >> DAEMON
> > > >> >> > issues at the moment. It is probably going to be a few days
> > before
> > > >> I'm
> > > >> >> > done there.
> > > >> >> >
> > > >> >> > Mark
> > > >> >> >
> > > >> >> >
> > > >> >> > >
> > > >> >> > > Thank you,
> > > >> >> > > Gary
> > > >> >> > >
> > > >> >> > >
> > > >> >> > >>
> > > >> >> > >>> - fix pool
> > > >> >> > >>> - release pool 2.4.4
> > > >> >> > >>> - update DBCP to pool 2.4.4
> > > >> >> > >>> - release DBCP
> > > >> >> > >>>
> > > >> >> > >>
> > > >> >> > >> Sounds good to me. This can be done by just removing the
> > > >> >> SecurityManager
> > > >> >> > >> version since a StackWalker version of CallStack could be
> > > >> implemented
> > > >> >> > for
> > > >> >> > >> Java 9, so it would be pointless to fully revert the change.
> > > >> >> > >>
> > > >> >> > >> --
> > > >> >> > >> Matt Sicker 
> > > >> >> > >>
> > > >> >> > >
> > > >> >> >
> > > >> >> >
> > > >> >> > 
> > > >> -
> > > >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >> >> >
> > > >> >> >
> > > >> >>
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Matt Sicker 
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Matt Sicker 
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Matt 

Re: [dbcp] update to pool 2.4.3.

[Gary Gregory]

I was able to build master commons-dbcp based on commons-pool2
master/2.5.0-SNAPSHOT. All tests pass in both builds :-)

Do you have time to push out a release commons-pool2 release? A branch for
2.4.4 or master for 2.5.0, either way would be OK with me.

Gary

On Fri, Nov 10, 2017 at 2:17 PM, Matt Sicker  wrote:

> Oh, I may have missed that since it didn't follow the naming scheme of all
> the other tags.
>
> On 10 November 2017 at 13:33, Gary Gregory  wrote:
>
> > I mean "Hi Matt" !
> >
> > On Fri, Nov 10, 2017 at 12:32 PM, Gary Gregory 
> > wrote:
> >
> > > Hi Amtt,
> > >
> > > The tags are:
> > >
> > > POOL_2.4.3
> > > POOL_2.4.3-RC1
> > >
> > > Gary
> > >
> > > On Fri, Nov 10, 2017 at 10:40 AM, Matt Sicker 
> wrote:
> > >
> > >> Added in https://issues.apache.org/jira/browse/POOL-335
> > >>
> > >> There's no git tag for 2.4.3, so I can't really even find a way to
> > >> backport
> > >> the option as it is.
> > >>
> > >> On 5 November 2017 at 22:01, Matt Sicker  wrote:
> > >>
> > >> > I probably can, yeah. Totally slipped my mind about this, though!
> > >> >
> > >> > On 5 November 2017 at 21:46, Gary Gregory 
> > >> wrote:
> > >> >
> > >> >> Hi Matt,
> > >> >>
> > >> >> Any chance you get take a look this week?
> > >> >>
> > >> >> Gary
> > >> >>
> > >> >> On Tue, Oct 31, 2017 at 10:58 AM, Mark Thomas 
> > >> wrote:
> > >> >>
> > >> >> > On 31/10/17 14:44, Gary Gregory wrote:
> > >> >> > > On Tue, Oct 31, 2017 at 8:33 AM, Matt Sicker  >
> > >> >> wrote:
> > >> >> > >
> > >> >> > >> On 31 October 2017 at 04:21, Mark Thomas 
> > >> wrote:
> > >> >> > >>>
> > >> >> > >>> If the methods are required then that makes 2.4.3 broken in
> my
> > >> >> view. In
> > >> >> > >>> which case we should wait for 2.4.4 before updating the
> version
> > >> DBCP
> > >> >> > >>> depends on. I don't think we should adapt the test. The test
> is
> > >> >> telling
> > >> >> > >>> us something is broken. We should fix the root cause not
> change
> > >> the
> > >> >> > test.
> > >> >> > >>>
> > >> >> > >>
> > >> >> > >> Regarding this, if the method names were expected in the
> output,
> > >> >> then a
> > >> >> > >> unit test should have existed to verify that. The existing
> test
> > >> was
> > >> >> only
> > >> >> > >> checking for class names, so I'm assuming that's why I made
> the
> > >> >> change a
> > >> >> > >> while back to optimize it for that use case. I think I asked
> on
> > >> the
> > >> >> > mailing
> > >> >> > >> lists first, but that was a while ago.
> > >> >> > >>
> > >> >> > >
> > >> >> > > It sounds like the missing unit test in [pool] was actually in
> > >> [dbcp]!
> > >> >> > :-p
> > >> >> > >
> > >> >> > > Matt or Mark, would you mind pitching in to fill out this
> missing
> > >> >> test?
> > >> >> >
> > >> >> > I'll help out when I can but I'm heads down working through the
> > >> DAEMON
> > >> >> > issues at the moment. It is probably going to be a few days
> before
> > >> I'm
> > >> >> > done there.
> > >> >> >
> > >> >> > Mark
> > >> >> >
> > >> >> >
> > >> >> > >
> > >> >> > > Thank you,
> > >> >> > > Gary
> > >> >> > >
> > >> >> > >
> > >> >> > >>
> > >> >> > >>> - fix pool
> > >> >> > >>> - release pool 2.4.4
> > >> >> > >>> - update DBCP to pool 2.4.4
> > >> >> > >>> - release DBCP
> > >> >> > >>>
> > >> >> > >>
> > >> >> > >> Sounds good to me. This can be done by just removing the
> > >> >> SecurityManager
> > >> >> > >> version since a StackWalker version of CallStack could be
> > >> implemented
> > >> >> > for
> > >> >> > >> Java 9, so it would be pointless to fully revert the change.
> > >> >> > >>
> > >> >> > >> --
> > >> >> > >> Matt Sicker 
> > >> >> > >>
> > >> >> > >
> > >> >> >
> > >> >> >
> > >> >> > 
> > >> -
> > >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> > >> >> >
> > >> >> >
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Matt Sicker 
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Matt Sicker 
> > >>
> > >
> > >
> >
>
>
>
> --
> Matt Sicker 
>

Re: Fwd: [jira] [Resolved] (CONFIGURATION-675) Add .gitignore file

[Oliver Heger]

Am 11.11.2017 um 21:22 schrieb Gary Gregory:
> I do not think we need a JIRA for this kind of housekeeping...

Agreed. However, in this case, the ticket has been created externally,
and I just followed the normal workflow to resolve it.

Oliver

> 
> Gary
> -- Forwarded message --
> From: Oliver Heger (JIRA) 
> Date: Sat, Nov 11, 2017 at 8:24 AM
> Subject: [jira] [Resolved] (CONFIGURATION-675) Add .gitignore file
> To: iss...@commons.apache.org
> 
> 
> 
>  [ https://issues.apache.org/jira/browse/CONFIGURATION-675?
> page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> 
> Oliver Heger resolved CONFIGURATION-675.
> 
>Resolution: Fixed
> Fix Version/s: 2.3
> 
> Copied the .gitignore file from Commons Lang. Fixed in SVN in revision
> 1814959.
> 
>> Add .gitignore file
>> ---
>>
>> Key: CONFIGURATION-675
>> URL: https://issues.apache.org/
> jira/browse/CONFIGURATION-675
>> Project: Commons Configuration
>>  Issue Type: Improvement
>>  Components: Build
>>Reporter: mingleizhang
>>Priority: Blocker
>> Fix For: 2.3
>>
>>
>> Add .gitignore to this project
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
> 

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

Fwd: [jira] [Resolved] (CONFIGURATION-675) Add .gitignore file

[Gary Gregory]

I do not think we need a JIRA for this kind of housekeeping...

Gary
-- Forwarded message --
From: Oliver Heger (JIRA) 
Date: Sat, Nov 11, 2017 at 8:24 AM
Subject: [jira] [Resolved] (CONFIGURATION-675) Add .gitignore file
To: iss...@commons.apache.org



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

Oliver Heger resolved CONFIGURATION-675.

   Resolution: Fixed
Fix Version/s: 2.3

Copied the .gitignore file from Commons Lang. Fixed in SVN in revision
1814959.

> Add .gitignore file
> ---
>
> Key: CONFIGURATION-675
> URL: https://issues.apache.org/
jira/browse/CONFIGURATION-675
> Project: Commons Configuration
>  Issue Type: Improvement
>  Components: Build
>Reporter: mingleizhang
>Priority: Blocker
> Fix For: 2.3
>
>
> Add .gitignore to this project



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Commons JCS 2.2.1 (roll 2)

[Thomas Vandahl]

On 06.11.17 21:11, Romain Manni-Bucau wrote:
> created 
> http://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2.1-RC2/
> (rev 1814438)

Thanks, Romain. However, the POM file in this RC tag contains now

--8<--

  

scm:svn:http://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2.1
  
  

scm:svn:https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2.1
  
  
http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2.1
  

--8<--

See my point? If you created the RC tag first and then copied, the
scm-entries would still point to the RC tag. In this case, it's the
other way round. It is difficult for me to see why this is believed to
make sense. I'd prefer to match tag name and file content.

Bye, Thomas

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