Re: Github fork issue with dependabot

[John Patrick]

I think it's a bug with dependabot at github, so have raised it as
such with them.

>From what I can tell the .github/dependabot.yml is the configuration
part but it also has an approval part to enable and disable under the
projects settings. Under my fork's settings, dependabot is disabled,
so it looks like this enable/disable doesn't actually do anything for
forks, and it's purely triggered by the presence of the configuration
file.

I've tried with some of the apps that integrate with github, which I
use for dependency management and automatic merging/rebasing. They
only activate on the fork once I explicitly approve them.

John


On Sat, 15 Aug 2020 at 04:21, Gary Gregory  wrote:
>
> Typo:  I think the way it works is that when you forked the Commons Lang
> repo, you *copied* the whole repo of course including its .github folder
> which means you therefore asked for the Dependabot to run since its
> configuration file is there.
>
> On Fri, Aug 14, 2020 at 11:19 PM Gary Gregory 
> wrote:
>
> > I think the way it works is that when you forked the Commons Lang repo,
> > you the whole repo of course including its .github folder which means you
> > therefore asked for the Dependabot to run since its configuration file is
> > there.
> >
> > Obviously if you do not want Dependabot to run, then just disable it
> > (remove the file)
> >
> > Gary
> >
> >
> > On Fri, Aug 14, 2020 at 7:56 PM John Patrick 
> > wrote:
> >
> >> Cheers for that Giles,
> >> I read those emails as PR's raised at say
> >> https://github.com/apache/commons-lang and dependabot, which I
> >> understand.
> >> I'm talking about my fork for commons-lang at
> >> https://github.com/nhojpatrick/commons-lang.
> >>
> >> Dependabot appears to have been authorised against my fork without my
> >> approval?
> >>
> >> If i visit
> >> https://github.com/nhojpatrick/commons-lang/settings/security_analysis
> >> dependabot is showing as disabled, but it appears to be
> >> active.
> >>
> >> Hope that help explain I'm talking about my fork
> >> (https://github.com/nhojpatrick/commons-lang) and my the forked
> >> (https://github.com/apache/commons-lang) project.
> >>
> >> As I say, I totally understanding about getting emails regarding
> >> dependabot as it's been authorised on the
> >> https://github.com/apache/commons-lang project.
> >>
> >> John
> >>
> >>
> >> On Fri, 14 Aug 2020 at 23:54, Gilles Sadowski 
> >> wrote:
> >> >
> >> > Hi.
> >> >
> >> > Le sam. 15 août 2020 à 00:02, John Patrick  a
> >> écrit :
> >> > >
> >> > > I've just noticed a load of pull requests that have been auto created
> >> > > by dependabot, for changes to be merged into my forked version of
> >> > > master.
> >> > >
> >> > > For commons-lang I've 20 PR's, commons-logging 10 PR's, I've not
> >> > > checked all the other commons forks I've got.
> >> > >
> >> > > They are getting automatically closed once I sync the commons fork
> >> > > into my forked repo.
> >> > >
> >> > > Has anyone else seen this issue?
> >> >
> >> > Oh, yes:
> >> > https://markmail.org/message/2vutc4p3b3eqv73f
> >> > https://markmail.org/message/6apxz6vrc75uq6ge
> >> >
> >> > Gilles
> >> >
> >> > >
> >> > > It seems to be a change that happened about 20 days ago, as that is
> >> > > when the first PR was raised.
> >> > >
> >> > > These changes also seem to be triggering cicd github actions, see
> >> > >
> >> https://github.com/nhojpatrick/commons-lang/runs/965399930?check_suite_focus=true
> >> .
> >> > >
> >> > > John
> >> >
> >> > -
> >> > 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: [ALL] Drop Travis in favor of Apache CI and GitHub Actions

[Xeno Amess]

Hi.
Do github actions have allow_failure？

Gary Gregory  于 2020年8月16日周日 上午5:35写道：

> If we want ARM builds for a component, then by all means let's us Travis
> until GitHub catches up.
>
> Gary
>
> On Sat, Aug 15, 2020, 16:51 Geoffrey Blake 
> wrote:
>
> > Not familiar with Apache CI, but github actions do not support Arm
> builds.
> > Arm should be recognized as a first class build target these days.
> Travis
> > allows Arm builds so not sure about the reasoning for moving off.
> >
> > -Geoff
> >
> > On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker  wrote:
> >
> > > Agreed on the GitHub Actions. Neutral about how snapshot sites are
> > >
> > > published since there are multiple methods of doing the same thing,
> > >
> > > though if that's also simple to set up via the action to commit the
> > >
> > > output to the gh-pages branch, I'd say go for it!
> > >
> > >
> > >
> > > On Sat, 15 Aug 2020 at 13:07, Gary Gregory 
> > wrote:
> > >
> > > >
> > >
> > > > Hi All,
> > >
> > > >
> > >
> > > > In order to ease maintenance, I propose that we drop Travis CI in
> favor
> > > of
> > >
> > > > Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like
> > plenty
> > >
> > > > to me. The exception would be a component with an existing complex
> > Travis
> > >
> > > > build that was not or cannot be reproduced in GitHub Actions.
> > >
> > > >
> > >
> > > > Looking ahead, I think we should consider publishing SNAPSHOT sites
> to
> > >
> > > > GitHub.io.
> > >
> > > >
> > >
> > > > Gary
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > >
> > > Matt Sicker 
> > >
> > >
> > >
> > > -
> > >
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> > >
> > >
> >
>

Github action versioning

[Mark Thomas]

Hi,

I am seeing an awful lot of list traffic generated for patch updates to
github actions e.g. updating from v1.4.0 to v1.4.1

Having read [1], my understanding is that we can specify v1 and that
will always point to the latest 1.x.x release.

Would it not be better to specify v1 for these actions as that way:
- we use the latest version automatically (until 2.x.x is released)
- we avoid all the noise on the mailing list

Mark



[1] https://docs.github.com/en/actions/creating-actions/about-actions

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

Re: [all] cicd philosophy (was: Re: Introducing Maven Wrapper)

[Xeno Amess]

I personally only use mvnw as a tool to force maven versions, or on
situations where we must use some machines without maven installed.
It is quite like gradlew in usage, but notice that maven have far less
major versions and far better backward compatibility than gradle, so in
most repos we do not actually need mvnw.
For commons repos, I tend to suggest only add it when needed.
And I havn't see any repos really need it(I played with only several
commons repos).
Or do you really got a problem, like, some of our ancient repos can only be
built on a special maven version? If so then I do agree add mvnw. otherwise
not.

Gary Gregory  于 2020年8月16日周日 上午2:20写道：

> Hi All,
>
> I would really prefer we do not do this.
>
> Note that there is no blocking issue to fix here. When you build in a CI,
> you know what OS you get and Maven is pre-configured, no mystery.
>
> My view here is that it would be the CI's job to toggle the Maven version
> just like a CI does for Java, the OS, and everything else a CI build uses.
>
> What I can see us doing is going to GitHub and asking for a
> actions/setup-maven just like there is a actions/setup-java. If we do
> anything we should create our own actions/setup-maven.
>
> I personally do not want to see or maintain copies of these files in 20+
> repositories; it seems like a giant maintenance headache to me. I don't
> want to consider why this component does it this way and this other one
> that way. I've been aiming for GitHub CI builds to be as consistent as
> possible FWIW.
>
> Gary
>
> On Sat, Aug 15, 2020 at 1:22 PM Rob Tompkins  wrote:
>
> > Hello all,
> >
> > I first want to thank John for bringing these points to light as I think
> > we can have quite a healthy discussion about the CI/CD philosophy
> employed
> > by the project (Apache Commons) generally. Furthermore, I hope to set
> > precedent with intent and direction with the following comments. Note,
> > these are merely ideas yet to be set in stone. I would propose that we
> > draft the ideas using this thread and potentially have a PMC
> > level/committer/user level [POLL] (to be handled on the dev@ list) on
> > direction following debate and drafting. I quite enjoy suggestions and
> > ideas from all areas and take quite seriously the suggestions of any user
> > of the project. :-)
> >
> > Having worked with ./mvnw extensively during $work over the last 5 years,
> > I’m quite hesitant to use it in CI. Note, we intentionally have NO
> > continuous deployment as we GPG sign all of our artifacts locally, and we
> > intentionally do not publish snapshots as we don’t want people actively
> > consuming our inflight development work. We use beta releases instead for
> > this purpose. Furthermore, all of our CI processes have explicit
> > declarations for a various array of different java versions (open to
> > varying across maven versions here). But do note that they are indeed all
> > quite hard coded in our github actions files, towards which we are
> > migrating.
> >
> > All that said, I do indeed see quite a good argument for including ./mvnw
> > in the project and that is to expedite developer productivity by helping
> to
> > install the latest version of Apache Maven, and I want to be clear here
> > that we only want to install the latest version of Apache Maven as we
> very
> > much do not want to be prescriptive with our java versioning. We, in
> fact,
> > work quite hard to maintain backwards compatibility to the oldest freely
> > available supported (long-term-support) version of java.
> >
> > I also wonder, but am unsure of the potential here with either GitHub’s
> > actions or GitHubs dependabot, if we can automate upversioning maven to
> > it’s latest version in said .properties files.
> >
> > Thoughts?
> >
> > Cheers,
> > -Rob
> >
> > > On Aug 15, 2020, at 9:45 AM, John Patrick 
> > wrote:
> > >
> > > I've raised some pull requests to add the Takari maven wrapper.
> > >
> > > The Takari maven wrapper is EOL and will be replaced with the Maven
> > > Wrapper when Maven v3.7.0 is released.
> > >
> > > I've added the Takari version as maven v3.7.0 is not yet out. I've
> > > been using the Takari maven wrapper for about 4 years now and it has
> > > reduced a lot of maintenance and setup tasks.
> > >
> > > - Maven Wrapper is Maven-As-Code
> > > - CI/CD, your docker images or Jenkins slaves no longer need maven pre
> > > installed, so less maintenance tasks
> > > - Developers don't need to pre install maven
> > > - Projects control what version of maven to use, maybe a legacy
> > > project needs v3.3.1 and a newer project needs v3.6.3. A developer
> > > doesn't need to keep changing their PATH, they just use ./mvnw.
> > > - Want to check a new version of maven, just change the properties,
> > > then it can undergo the standard pull request build checks to make
> > > sure the project works with that version.
> > >
> > > The first PR I raised was for commons-code and can be found here
> > > https://github.com/apache/

Re: Github action versioning

[Xeno Amess]

I REALLY suggest we move all dependabot mails to another mailing list.
please create one.

Mark Thomas  于 2020年8月16日周日 下午5:55写道：

> Hi,
>
> I am seeing an awful lot of list traffic generated for patch updates to
> github actions e.g. updating from v1.4.0 to v1.4.1
>
> Having read [1], my understanding is that we can specify v1 and that
> will always point to the latest 1.x.x release.
>
> Would it not be better to specify v1 for these actions as that way:
> - we use the latest version automatically (until 2.x.x is released)
> - we avoid all the noise on the mailing list
>
> Mark
>
>
>
> [1] https://docs.github.com/en/actions/creating-actions/about-actions
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [LOGGING][DAEMON] Update Java 6 to 7

[Mark Thomas]

On 15/08/2020 19:00, Gary Gregory wrote:
> On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas  wrote:
> 
>> On 10/08/2020 17:26, Gary Gregory wrote:
>>> As recently done for [EMAIL], I propose we update [LOGGING] and [DAEMON]
>>> from Java 6 to 7 to streamline building on CIs.
>>
>> -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated
>> requirement to run on Java 6.
>>
> 
> Yikes ;-) how long is rein in antiquity planned to last? ;-)

Tomcat 7 EOL is 31 March 2021.

Like most major Tomcat versions, it has been supported for ~10 years
since the first release.

The scary thing is that the users mailing list still sees questions
about Tomcat 6 and earlier.

> We might need a branch for Tomcat so the project can move ahead in a more
> modern setting IMO.

Unless there is a feature that NEEDS Java 7, branching is just going to
create unnecessary overhead. My experience of DAEMON over that last few
years is the most (all?) of the work has been on the native code side.
Therefore, I don't see the harm in keeping the Java side on 1.6 for now.

If the issue is the inability to build with newer Java versions, I have
no issue updating the declared minimum version as long as the Java code
remains compilable with/for Java 6.

Mark

> 
> Gary
> 
>>
>> Are there any features / bugs in Jira that require this increase?
>>
>> Mark
>>
>> -
>> 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: [LOGGING][DAEMON] Update Java 6 to 7

[Xeno Amess]

I suddenly arise a good idea...
How about
1. we release a java 7 version of this repo.
2. we wait for user argue about this.
3. if no users argue about this, we just go forward to 7.  Otherwise, we
re-consider about this.


Mark Thomas  于 2020年8月16日周日 下午6:08写道：

> On 15/08/2020 19:00, Gary Gregory wrote:
> > On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas  wrote:
> >
> >> On 10/08/2020 17:26, Gary Gregory wrote:
> >>> As recently done for [EMAIL], I propose we update [LOGGING] and
> [DAEMON]
> >>> from Java 6 to 7 to streamline building on CIs.
> >>
> >> -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated
> >> requirement to run on Java 6.
> >>
> >
> > Yikes ;-) how long is rein in antiquity planned to last? ;-)
>
> Tomcat 7 EOL is 31 March 2021.
>
> Like most major Tomcat versions, it has been supported for ~10 years
> since the first release.
>
> The scary thing is that the users mailing list still sees questions
> about Tomcat 6 and earlier.
>
> > We might need a branch for Tomcat so the project can move ahead in a more
> > modern setting IMO.
>
> Unless there is a feature that NEEDS Java 7, branching is just going to
> create unnecessary overhead. My experience of DAEMON over that last few
> years is the most (all?) of the work has been on the native code side.
> Therefore, I don't see the harm in keeping the Java side on 1.6 for now.
>
> If the issue is the inability to build with newer Java versions, I have
> no issue updating the declared minimum version as long as the Java code
> remains compilable with/for Java 6.
>
> Mark
>
> >
> > Gary
> >
> >>
> >> Are there any features / bugs in Jira that require this increase?
> >>
> >> Mark
> >>
> >> -
> >> 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: [ALL] Drop Travis in favor of Apache CI and GitHub Actions

[Rob Tompkins]

I like the use both solution. I personally like the CI system to be closer to 
the code. Thus, I lean towards GitHub actions. 

-Rob

> On Aug 15, 2020, at 2:07 PM, Gary Gregory  wrote:
> 
> Hi All,
> 
> In order to ease maintenance, I propose that we drop Travis CI in favor of
> Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like plenty
> to me. The exception would be a component with an existing complex Travis
> build that was not or cannot be reproduced in GitHub Actions.
> 
> Looking ahead, I think we should consider publishing SNAPSHOT sites to
> GitHub.io.
> 
> Gary

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

Re: Github action versioning

[Rob Tompkins]

> On Aug 16, 2020, at 5:59 AM, Xeno Amess  wrote:
> 
> I REALLY suggest we move all dependabot mails to another mailing list.
> please create one.

Your point has pulled me from a -1 to a -0, where I want the emails as bots 
should be treated as people in some sense. That said, I’m curious as to what 
others think...

Thoughts?

-Rob

> 
> Mark Thomas  于 2020年8月16日周日 下午5:55写道：
> 
>> Hi,
>> 
>> I am seeing an awful lot of list traffic generated for patch updates to
>> github actions e.g. updating from v1.4.0 to v1.4.1
>> 
>> Having read [1], my understanding is that we can specify v1 and that
>> will always point to the latest 1.x.x release.
>> 
>> Would it not be better to specify v1 for these actions as that way:
>> - we use the latest version automatically (until 2.x.x is released)
>> - we avoid all the noise on the mailing list
>> 
>> Mark
>> 
>> 
>> 
>> [1] https://docs.github.com/en/actions/creating-actions/about-actions
>> 
>> -
>> 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: Github action versioning

[Xeno Amess]

@Rob Tompkins 
Hi.
Please consider:
1. Most people who subscribe commons-dev have no right to do any operations
to dependabot prs.
We can not help merge them, nor decline them & close them. Means reading
such mails are a waste of time.
2. Most people who subscribe commons-dev actually do not really want to
read such e-mails.
3. Dependabot mails usually have low value. Only maintainers should have
some interest in watching them. And usually it will not break
anything.(Just, usually, in most cases).
4. Dependabot mails are flooding. They are too many.
5. Dependabot mails cause argues about them (this happened several times
this two weeks).

Well my idea is we create a new mailing list named "commons-dev-auto" or
"commons-dev-bot", who contains all the auto-email.

> I want the emails as bots should be treated as people in some sense.

But the reality is the bot is not people.
Besides, if there be such a people who make that much pr, will you promise
review every of those prs, and do not complain about him be flooding?

Rob Tompkins  于2020年8月16日周日 下午8:02写道：

>
>
> > On Aug 16, 2020, at 5:59 AM, Xeno Amess  wrote:
> >
> > I REALLY suggest we move all dependabot mails to another mailing list.
> > please create one.
>
> Your point has pulled me from a -1 to a -0, where I want the emails as
> bots should be treated as people in some sense. That said, I’m curious as
> to what others think...
>
> Thoughts?
>
> -Rob
>
> >
> > Mark Thomas  于 2020年8月16日周日 下午5:55写道：
> >
> >> Hi,
> >>
> >> I am seeing an awful lot of list traffic generated for patch updates to
> >> github actions e.g. updating from v1.4.0 to v1.4.1
> >>
> >> Having read [1], my understanding is that we can specify v1 and that
> >> will always point to the latest 1.x.x release.
> >>
> >> Would it not be better to specify v1 for these actions as that way:
> >> - we use the latest version automatically (until 2.x.x is released)
> >> - we avoid all the noise on the mailing list
> >>
> >> Mark
> >>
> >>
> >>
> >> [1] https://docs.github.com/en/actions/creating-actions/about-actions
> >>
> >> -
> >> 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: Github action versioning

[Rob Tompkins]

Sure. That’s why you’ve pulled me from a “no” to a non-blocking dissenting 
opinion. I will go with community consensus at this point despite my opinion 
(-0) (-; 

-Rob

> On Aug 16, 2020, at 8:25 AM, Xeno Amess  wrote:
> 
> 
> @Rob Tompkins 
> Hi.
> Please consider:
> 1. Most people who subscribe commons-dev have no right to do any operations 
> to dependabot prs.
> We can not help merge them, nor decline them & close them. Means reading such 
> mails are a waste of time.
> 2. Most people who subscribe commons-dev actually do not really want to read 
> such e-mails.
> 3. Dependabot mails usually have low value. Only maintainers should have some 
> interest in watching them. And usually it will not break anything.(Just, 
> usually, in most cases).
> 4. Dependabot mails are flooding. They are too many.
> 5. Dependabot mails cause argues about them (this happened several times this 
> two weeks).
> 
> Well my idea is we create a new mailing list named "commons-dev-auto" or  
> "commons-dev-bot", who contains all the auto-email.
> 
> > I want the emails as bots should be treated as people in some sense.
> 
> But the reality is the bot is not people.
> Besides, if there be such a people who make that much pr, will you promise 
> review every of those prs, and do not complain about him be flooding?
> 
> Rob Tompkins  于2020年8月16日周日 下午8:02写道：
>> 
>> 
>> > On Aug 16, 2020, at 5:59 AM, Xeno Amess  wrote:
>> > 
>> > I REALLY suggest we move all dependabot mails to another mailing list.
>> > please create one.
>> 
>> Your point has pulled me from a -1 to a -0, where I want the emails as bots 
>> should be treated as people in some sense. That said, I’m curious as to what 
>> others think...
>> 
>> Thoughts?
>> 
>> -Rob
>> 
>> > 
>> > Mark Thomas  于 2020年8月16日周日 下午5:55写道：
>> > 
>> >> Hi,
>> >> 
>> >> I am seeing an awful lot of list traffic generated for patch updates to
>> >> github actions e.g. updating from v1.4.0 to v1.4.1
>> >> 
>> >> Having read [1], my understanding is that we can specify v1 and that
>> >> will always point to the latest 1.x.x release.
>> >> 
>> >> Would it not be better to specify v1 for these actions as that way:
>> >> - we use the latest version automatically (until 2.x.x is released)
>> >> - we avoid all the noise on the mailing list
>> >> 
>> >> Mark
>> >> 
>> >> 
>> >> 
>> >> [1] https://docs.github.com/en/actions/creating-actions/about-actions
>> >> 
>> >> -
>> >> 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: Github action versioning

[Rob Tompkins]

> On Aug 16, 2020, at 8:29 AM, Rob Tompkins  wrote:
> 
> 
> Sure. That’s why you’ve pulled me from a “no” to a non-blocking dissenting 
> opinion. I will go with community consensus at this point despite my opinion 
> (-0) (-; 
> 
> -Rob
> 
>>> On Aug 16, 2020, at 8:25 AM, Xeno Amess  wrote:
>>> 
>> 
>> @Rob Tompkins 
>> Hi.
>> Please consider:
>> 1. Most people who subscribe commons-dev have no right to do any operations 
>> to dependabot prs.
>> We can not help merge them, nor decline them & close them. Means reading 
>> such mails are a waste of time.
>> 2. Most people who subscribe commons-dev actually do not really want to read 
>> such e-mails.
>> 3. Dependabot mails usually have low value. Only maintainers should have 
>> some interest in watching them. And usually it will not break 
>> anything.(Just, usually, in most cases).
>> 4. Dependabot mails are flooding. They are too many.
>> 5. Dependabot mails cause argues about them (this happened several times 
>> this two weeks).
>> 
>> Well my idea is we create a new mailing list named "commons-dev-auto" or  
>> "commons-dev-bot", who contains all the auto-email.
>> 
>> > I want the emails as bots should be treated as people in some sense.
>> 
>> But the reality is the bot is not people.

Based on my readings about the theory of consciousness (See Annaka Harris’ book 
“Consciousness”), my feelings on the matter directly oppose yours here (agree 
to disagree). In fact I think that computers may actually have some self 
awareness. This may seem a tad loony and likely quite controversial. This is 
why I’m going to keep myself as non-blocking but dissenting as to keep my 
beliefs to myself and not impose upon the will of the community. :-)

-Rob

>> Besides, if there be such a people who make that much pr, will you promise 
>> review every of those prs, and do not complain about him be flooding?
>> 
>> Rob Tompkins  于2020年8月16日周日 下午8:02写道：
>>> 
>>> 
>>> > On Aug 16, 2020, at 5:59 AM, Xeno Amess  wrote:
>>> > 
>>> > I REALLY suggest we move all dependabot mails to another mailing list.
>>> > please create one.
>>> 
>>> Your point has pulled me from a -1 to a -0, where I want the emails as bots 
>>> should be treated as people in some sense. That said, I’m curious as to 
>>> what others think...
>>> 
>>> Thoughts?
>>> 
>>> -Rob
>>> 
>>> > 
>>> > Mark Thomas  于 2020年8月16日周日 下午5:55写道：
>>> > 
>>> >> Hi,
>>> >> 
>>> >> I am seeing an awful lot of list traffic generated for patch updates to
>>> >> github actions e.g. updating from v1.4.0 to v1.4.1
>>> >> 
>>> >> Having read [1], my understanding is that we can specify v1 and that
>>> >> will always point to the latest 1.x.x release.
>>> >> 
>>> >> Would it not be better to specify v1 for these actions as that way:
>>> >> - we use the latest version automatically (until 2.x.x is released)
>>> >> - we avoid all the noise on the mailing list
>>> >> 
>>> >> Mark
>>> >> 
>>> >> 
>>> >> 
>>> >> [1] https://docs.github.com/en/actions/creating-actions/about-actions
>>> >> 
>>> >> -
>>> >> 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: Github action versioning

[Gary Gregory]

I would not do that for Maven plugins in a POM, so I would not do that
either for GitHub actions.

Mailing list volume is a different topic.

Gary

On Sun, Aug 16, 2020, 05:55 Mark Thomas  wrote:

> Hi,
>
> I am seeing an awful lot of list traffic generated for patch updates to
> github actions e.g. updating from v1.4.0 to v1.4.1
>
> Having read [1], my understanding is that we can specify v1 and that
> will always point to the latest 1.x.x release.
>
> Would it not be better to specify v1 for these actions as that way:
> - we use the latest version automatically (until 2.x.x is released)
> - we avoid all the noise on the mailing list
>
> Mark
>
>
>
> [1] https://docs.github.com/en/actions/creating-actions/about-actions
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [LOGGING][DAEMON] Update Java 6 to 7

[Rob Tompkins]

> On Aug 16, 2020, at 6:13 AM, Xeno Amess  wrote:
> 
> I suddenly arise a good idea...
> How about
> 1. we release a java 7 version of this repo.
> 2. we wait for user argue about this.
> 3. if no users argue about this, we just go forward to 7.  Otherwise, we
> re-consider about this.

That would warrant a major version up-version and maintaining two major 
versions in parallel. As Mark is the main developer here, and understandably is 
quite busy, we’ll have to see what he says. 

-Rob

> 
> 
> Mark Thomas  于 2020年8月16日周日 下午6:08写道：
> 
>>> On 15/08/2020 19:00, Gary Gregory wrote:
 On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas  wrote:
>>> 
 On 10/08/2020 17:26, Gary Gregory wrote:
> As recently done for [EMAIL], I propose we update [LOGGING] and
>> [DAEMON]
> from Java 6 to 7 to streamline building on CIs.
 
 -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated
 requirement to run on Java 6.
 
>>> 
>>> Yikes ;-) how long is rein in antiquity planned to last? ;-)
>> 
>> Tomcat 7 EOL is 31 March 2021.
>> 
>> Like most major Tomcat versions, it has been supported for ~10 years
>> since the first release.
>> 
>> The scary thing is that the users mailing list still sees questions
>> about Tomcat 6 and earlier.
>> 
>>> We might need a branch for Tomcat so the project can move ahead in a more
>>> modern setting IMO.
>> 
>> Unless there is a feature that NEEDS Java 7, branching is just going to
>> create unnecessary overhead. My experience of DAEMON over that last few
>> years is the most (all?) of the work has been on the native code side.
>> Therefore, I don't see the harm in keeping the Java side on 1.6 for now.
>> 
>> If the issue is the inability to build with newer Java versions, I have
>> no issue updating the declared minimum version as long as the Java code
>> remains compilable with/for Java 6.
>> 
>> Mark
>> 
>>> 
>>> Gary
>>> 
 
 Are there any features / bugs in Jira that require this increase?
 
 Mark
 
 -
 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: Github action versioning

[Mark Thomas]

On 16/08/2020 13:58, Gary Gregory wrote:
> I would not do that for Maven plugins in a POM, so I would not do that
> either for GitHub actions.

Fair enough. It looked to me as if these updates were being approved
largely automatically hence the suggestion to skip that and just let the
upgrades happen. The option is there for components that want to use it.

> Mailing list volume is a different topic.

Indeed.

Mark

> 
> Gary
> 
> On Sun, Aug 16, 2020, 05:55 Mark Thomas  wrote:
> 
>> Hi,
>>
>> I am seeing an awful lot of list traffic generated for patch updates to
>> github actions e.g. updating from v1.4.0 to v1.4.1
>>
>> Having read [1], my understanding is that we can specify v1 and that
>> will always point to the latest 1.x.x release.
>>
>> Would it not be better to specify v1 for these actions as that way:
>> - we use the latest version automatically (until 2.x.x is released)
>> - we avoid all the noise on the mailing list
>>
>> Mark
>>
>>
>>
>> [1] https://docs.github.com/en/actions/creating-actions/about-actions
>>
>> -
>> 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: [LOGGING][DAEMON] Update Java 6 to 7

[Rob Tompkins]

> On Aug 16, 2020, at 6:08 AM, Mark Thomas  wrote:
> 
> On 15/08/2020 19:00, Gary Gregory wrote:
>> On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas > > wrote:
>> 
>>> On 10/08/2020 17:26, Gary Gregory wrote:
 As recently done for [EMAIL], I propose we update [LOGGING] and [DAEMON]
 from Java 6 to 7 to streamline building on CIs.
>>> 
>>> -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated
>>> requirement to run on Java 6.
>>> 
>> 
>> Yikes ;-) how long is rein in antiquity planned to last? ;-)
> 
> Tomcat 7 EOL is 31 March 2021.
> 
> Like most major Tomcat versions, it has been supported for ~10 years
> since the first release.
> 
> The scary thing is that the users mailing list still sees questions
> about Tomcat 6 and earlier.

:-| that’s bonkers….but I recall Christopher Shultz saying as much.

-Rob

> 
>> We might need a branch for Tomcat so the project can move ahead in a more
>> modern setting IMO.
> 
> Unless there is a feature that NEEDS Java 7, branching is just going to
> create unnecessary overhead. My experience of DAEMON over that last few
> years is the most (all?) of the work has been on the native code side.
> Therefore, I don't see the harm in keeping the Java side on 1.6 for now.
> 
> If the issue is the inability to build with newer Java versions, I have
> no issue updating the declared minimum version as long as the Java code
> remains compilable with/for Java 6.
> 
> Mark
> 
>> 
>> Gary
>> 
>>> 
>>> Are there any features / bugs in Jira that require this increase?
>>> 
>>> Mark
>>> 
>>> -
>>> 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: Github action versioning

[John Patrick]

I wonder if openjdk has considered all the auto generated traffic that
might be triggered from github. As for JDK 16 they are moving from
Mercurial to Git, and moving from internal hosting to Github. I guess
we will know shortly as ramp down for JDK 16 will start something in
december.

Having seen renovate (similar to dependabot) enabled for cucumber in
july, and the spike of ~50 pr initially, which each having an email
about code coverage, then another when approved and merged, then each
time rebased, another email and another code coverage email, until the
final merge email. It was a downpour of emails.

I expect commons will see similar spikes after a release of a project,
as so many projects on the same mailing lists, and when a release
train starts it cascades automatically, but it's better than someone
having to manually perform those tasks.

The question I guess is how do those with commit/approve privileges
want to receive notifications about PR's, comments and merges. With
dependabot adding automation, is it time to split out those github
event triggered emails to maybe commons-github or commons-lang-github.
If the people with the power believe they are being overloads with an
increase of traffic, it would give them the opportunity to only
receive notifications for projects they want to maintain. Splitting
dependabot from user triggered events, if you're wanting to avoid or
mute dependabot emails, you might as well simply disable dependabot.

Using gmail, it does allow simple filtering and displaying those
threads, I wouldn't want to receive github event emails using an email
client that doesn't automatically group email threads.

That reminds me, should I be top commenting or bottom commenting or
inline commenting for commons emails, as gmail defaults to top.

John

On Sun, 16 Aug 2020 at 14:10, Mark Thomas  wrote:
>
> On 16/08/2020 13:58, Gary Gregory wrote:
> > I would not do that for Maven plugins in a POM, so I would not do that
> > either for GitHub actions.
>
> Fair enough. It looked to me as if these updates were being approved
> largely automatically hence the suggestion to skip that and just let the
> upgrades happen. The option is there for components that want to use it.
>
> > Mailing list volume is a different topic.
>
> Indeed.
>
> Mark
>
> >
> > Gary
> >
> > On Sun, Aug 16, 2020, 05:55 Mark Thomas  wrote:
> >
> >> Hi,
> >>
> >> I am seeing an awful lot of list traffic generated for patch updates to
> >> github actions e.g. updating from v1.4.0 to v1.4.1
> >>
> >> Having read [1], my understanding is that we can specify v1 and that
> >> will always point to the latest 1.x.x release.
> >>
> >> Would it not be better to specify v1 for these actions as that way:
> >> - we use the latest version automatically (until 2.x.x is released)
> >> - we avoid all the noise on the mailing list
> >>
> >> Mark
> >>
> >>
> >>
> >> [1] https://docs.github.com/en/actions/creating-actions/about-actions
> >>
> >> -
> >> 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: Github action versioning

[Gary Gregory]

Hi all,

As Apache Commons is a single Apache Project, we have one dev and one user
ML. I think we should keep it that way, it helps Commons be Commons IMO. We
also have one git commit ML. We could have an additional ML for robots
which would only be used by services like github so any PR and Dependabot
emails would go to the robots ML. The commit ML is a kind of robot so there
some conceptual duplication IMO but we can all deal with it I am sure ;-)

Thoughts?

Gary

On Sun, Aug 16, 2020, 09:48 John Patrick  wrote:

> I wonder if openjdk has considered all the auto generated traffic that
> might be triggered from github. As for JDK 16 they are moving from
> Mercurial to Git, and moving from internal hosting to Github. I guess
> we will know shortly as ramp down for JDK 16 will start something in
> december.
>
> Having seen renovate (similar to dependabot) enabled for cucumber in
> july, and the spike of ~50 pr initially, which each having an email
> about code coverage, then another when approved and merged, then each
> time rebased, another email and another code coverage email, until the
> final merge email. It was a downpour of emails.
>
> I expect commons will see similar spikes after a release of a project,
> as so many projects on the same mailing lists, and when a release
> train starts it cascades automatically, but it's better than someone
> having to manually perform those tasks.
>
> The question I guess is how do those with commit/approve privileges
> want to receive notifications about PR's, comments and merges. With
> dependabot adding automation, is it time to split out those github
> event triggered emails to maybe commons-github or commons-lang-github.
> If the people with the power believe they are being overloads with an
> increase of traffic, it would give them the opportunity to only
> receive notifications for projects they want to maintain. Splitting
> dependabot from user triggered events, if you're wanting to avoid or
> mute dependabot emails, you might as well simply disable dependabot.
>
> Using gmail, it does allow simple filtering and displaying those
> threads, I wouldn't want to receive github event emails using an email
> client that doesn't automatically group email threads.
>
> That reminds me, should I be top commenting or bottom commenting or
> inline commenting for commons emails, as gmail defaults to top.
>
> John
>
> On Sun, 16 Aug 2020 at 14:10, Mark Thomas  wrote:
> >
> > On 16/08/2020 13:58, Gary Gregory wrote:
> > > I would not do that for Maven plugins in a POM, so I would not do that
> > > either for GitHub actions.
> >
> > Fair enough. It looked to me as if these updates were being approved
> > largely automatically hence the suggestion to skip that and just let the
> > upgrades happen. The option is there for components that want to use it.
> >
> > > Mailing list volume is a different topic.
> >
> > Indeed.
> >
> > Mark
> >
> > >
> > > Gary
> > >
> > > On Sun, Aug 16, 2020, 05:55 Mark Thomas  wrote:
> > >
> > >> Hi,
> > >>
> > >> I am seeing an awful lot of list traffic generated for patch updates
> to
> > >> github actions e.g. updating from v1.4.0 to v1.4.1
> > >>
> > >> Having read [1], my understanding is that we can specify v1 and that
> > >> will always point to the latest 1.x.x release.
> > >>
> > >> Would it not be better to specify v1 for these actions as that way:
> > >> - we use the latest version automatically (until 2.x.x is released)
> > >> - we avoid all the noise on the mailing list
> > >>
> > >> Mark
> > >>
> > >>
> > >>
> > >> [1] https://docs.github.com/en/actions/creating-actions/about-actions
> > >>
> > >> -
> > >> 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: [LOGGING][DAEMON] Update Java 6 to 7

[sebb]

On Sun, 16 Aug 2020 at 11:13, Xeno Amess  wrote:
>
> I suddenly arise a good idea...
> How about
> 1. we release a java 7 version of this repo.
> 2. we wait for user argue about this.

That has already happened ...

As noted earlier in this thread, Tomcat needs a version that compiles on Java 6

> 3. if no users argue about this, we just go forward to 7.  Otherwise, we
> re-consider about this.


>
> Mark Thomas  于 2020年8月16日周日 下午6:08写道：
>
> > On 15/08/2020 19:00, Gary Gregory wrote:
> > > On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas  wrote:
> > >
> > >> On 10/08/2020 17:26, Gary Gregory wrote:
> > >>> As recently done for [EMAIL], I propose we update [LOGGING] and
> > [DAEMON]
> > >>> from Java 6 to 7 to streamline building on CIs.
> > >>
> > >> -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated
> > >> requirement to run on Java 6.
> > >>
> > >
> > > Yikes ;-) how long is rein in antiquity planned to last? ;-)
> >
> > Tomcat 7 EOL is 31 March 2021.
> >
> > Like most major Tomcat versions, it has been supported for ~10 years
> > since the first release.
> >
> > The scary thing is that the users mailing list still sees questions
> > about Tomcat 6 and earlier.
> >
> > > We might need a branch for Tomcat so the project can move ahead in a more
> > > modern setting IMO.
> >
> > Unless there is a feature that NEEDS Java 7, branching is just going to
> > create unnecessary overhead. My experience of DAEMON over that last few
> > years is the most (all?) of the work has been on the native code side.
> > Therefore, I don't see the harm in keeping the Java side on 1.6 for now.
> >
> > If the issue is the inability to build with newer Java versions, I have
> > no issue updating the declared minimum version as long as the Java code
> > remains compilable with/for Java 6.
> >
> > Mark
> >
> > >
> > > Gary
> > >
> > >>
> > >> Are there any features / bugs in Jira that require this increase?
> > >>
> > >> Mark
> > >>
> > >> -
> > >> 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: [LOGGING][DAEMON] Update Java 6 to 7

[sebb]

I've pushed change to the pom which allows compilation on Java14.

Will that suffice?

On Sun, 16 Aug 2020 at 15:29, sebb  wrote:
>
> On Sun, 16 Aug 2020 at 11:13, Xeno Amess  wrote:
> >
> > I suddenly arise a good idea...
> > How about
> > 1. we release a java 7 version of this repo.
> > 2. we wait for user argue about this.
>
> That has already happened ...
>
> As noted earlier in this thread, Tomcat needs a version that compiles on Java 
> 6
>
> > 3. if no users argue about this, we just go forward to 7.  Otherwise, we
> > re-consider about this.
>
>
> >
> > Mark Thomas  于 2020年8月16日周日 下午6:08写道：
> >
> > > On 15/08/2020 19:00, Gary Gregory wrote:
> > > > On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas  wrote:
> > > >
> > > >> On 10/08/2020 17:26, Gary Gregory wrote:
> > > >>> As recently done for [EMAIL], I propose we update [LOGGING] and
> > > [DAEMON]
> > > >>> from Java 6 to 7 to streamline building on CIs.
> > > >>
> > > >> -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated
> > > >> requirement to run on Java 6.
> > > >>
> > > >
> > > > Yikes ;-) how long is rein in antiquity planned to last? ;-)
> > >
> > > Tomcat 7 EOL is 31 March 2021.
> > >
> > > Like most major Tomcat versions, it has been supported for ~10 years
> > > since the first release.
> > >
> > > The scary thing is that the users mailing list still sees questions
> > > about Tomcat 6 and earlier.
> > >
> > > > We might need a branch for Tomcat so the project can move ahead in a 
> > > > more
> > > > modern setting IMO.
> > >
> > > Unless there is a feature that NEEDS Java 7, branching is just going to
> > > create unnecessary overhead. My experience of DAEMON over that last few
> > > years is the most (all?) of the work has been on the native code side.
> > > Therefore, I don't see the harm in keeping the Java side on 1.6 for now.
> > >
> > > If the issue is the inability to build with newer Java versions, I have
> > > no issue updating the declared minimum version as long as the Java code
> > > remains compilable with/for Java 6.
> > >
> > > Mark
> > >
> > > >
> > > > Gary
> > > >
> > > >>
> > > >> Are there any features / bugs in Jira that require this increase?
> > > >>
> > > >> Mark
> > > >>
> > > >> -
> > > >> 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: [LOGGING][DAEMON] Update Java 6 to 7

[Mark Thomas]

On 16/08/2020 15:45, sebb wrote:
> I've pushed change to the pom which allows compilation on Java14.
> 
> Will that suffice?

That certainly works for me. Thanks for doing this.

Mark


> 
> On Sun, 16 Aug 2020 at 15:29, sebb  wrote:
>>
>> On Sun, 16 Aug 2020 at 11:13, Xeno Amess  wrote:
>>>
>>> I suddenly arise a good idea...
>>> How about
>>> 1. we release a java 7 version of this repo.
>>> 2. we wait for user argue about this.
>>
>> That has already happened ...
>>
>> As noted earlier in this thread, Tomcat needs a version that compiles on 
>> Java 6
>>
>>> 3. if no users argue about this, we just go forward to 7.  Otherwise, we
>>> re-consider about this.
>>
>>
>>>
>>> Mark Thomas  于 2020年8月16日周日 下午6:08写道：
>>>
 On 15/08/2020 19:00, Gary Gregory wrote:
> On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas  wrote:
>
>> On 10/08/2020 17:26, Gary Gregory wrote:
>>> As recently done for [EMAIL], I propose we update [LOGGING] and
 [DAEMON]
>>> from Java 6 to 7 to streamline building on CIs.
>>
>> -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated
>> requirement to run on Java 6.
>>
>
> Yikes ;-) how long is rein in antiquity planned to last? ;-)

 Tomcat 7 EOL is 31 March 2021.

 Like most major Tomcat versions, it has been supported for ~10 years
 since the first release.

 The scary thing is that the users mailing list still sees questions
 about Tomcat 6 and earlier.

> We might need a branch for Tomcat so the project can move ahead in a more
> modern setting IMO.

 Unless there is a feature that NEEDS Java 7, branching is just going to
 create unnecessary overhead. My experience of DAEMON over that last few
 years is the most (all?) of the work has been on the native code side.
 Therefore, I don't see the harm in keeping the Java side on 1.6 for now.

 If the issue is the inability to build with newer Java versions, I have
 no issue updating the declared minimum version as long as the Java code
 remains compilable with/for Java 6.

 Mark

>
> Gary
>
>>
>> Are there any features / bugs in Jira that require this increase?
>>
>> Mark
>>
>> -
>> 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
> 


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

Re: [LOGGING][DAEMON] Update Java 6 to 7

[sebb]

I've also updated LOGGING to build on Java12+

The animal-sniffer signature should catch incompatible changes.

AFAICT there is therefore no need to change the minimum version merely
to make CI easier.

On Sun, 16 Aug 2020 at 16:05, Mark Thomas  wrote:
>
> On 16/08/2020 15:45, sebb wrote:
> > I've pushed change to the pom which allows compilation on Java14.
> >
> > Will that suffice?
>
> That certainly works for me. Thanks for doing this.
>
> Mark
>
>
> >
> > On Sun, 16 Aug 2020 at 15:29, sebb  wrote:
> >>
> >> On Sun, 16 Aug 2020 at 11:13, Xeno Amess  wrote:
> >>>
> >>> I suddenly arise a good idea...
> >>> How about
> >>> 1. we release a java 7 version of this repo.
> >>> 2. we wait for user argue about this.
> >>
> >> That has already happened ...
> >>
> >> As noted earlier in this thread, Tomcat needs a version that compiles on 
> >> Java 6
> >>
> >>> 3. if no users argue about this, we just go forward to 7.  Otherwise, we
> >>> re-consider about this.
> >>
> >>
> >>>
> >>> Mark Thomas  于 2020年8月16日周日 下午6:08写道：
> >>>
>  On 15/08/2020 19:00, Gary Gregory wrote:
> > On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas  wrote:
> >
> >> On 10/08/2020 17:26, Gary Gregory wrote:
> >>> As recently done for [EMAIL], I propose we update [LOGGING] and
>  [DAEMON]
> >>> from Java 6 to 7 to streamline building on CIs.
> >>
> >> -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated
> >> requirement to run on Java 6.
> >>
> >
> > Yikes ;-) how long is rein in antiquity planned to last? ;-)
> 
>  Tomcat 7 EOL is 31 March 2021.
> 
>  Like most major Tomcat versions, it has been supported for ~10 years
>  since the first release.
> 
>  The scary thing is that the users mailing list still sees questions
>  about Tomcat 6 and earlier.
> 
> > We might need a branch for Tomcat so the project can move ahead in a 
> > more
> > modern setting IMO.
> 
>  Unless there is a feature that NEEDS Java 7, branching is just going to
>  create unnecessary overhead. My experience of DAEMON over that last few
>  years is the most (all?) of the work has been on the native code side.
>  Therefore, I don't see the harm in keeping the Java side on 1.6 for now.
> 
>  If the issue is the inability to build with newer Java versions, I have
>  no issue updating the declared minimum version as long as the Java code
>  remains compilable with/for Java 6.
> 
>  Mark
> 
> >
> > Gary
> >
> >>
> >> Are there any features / bugs in Jira that require this increase?
> >>
> >> Mark
> >>
> >> -
> >> 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
> >
>
>
> -
> 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: [LOGGING][DAEMON] Update Java 6 to 7

[Xeno Amess]

> I've pushed change to the pom which allows compilation on Java14.

Well it might be silly to ask but, is there a mechanism for us to make sure
that openjdk 6 output jar of this repo can be run totally correct on newer
JVM s?


sebb  于2020年8月16日周日 下午11:37写道：

> I've also updated LOGGING to build on Java12+
>
> The animal-sniffer signature should catch incompatible changes.
>
> AFAICT there is therefore no need to change the minimum version merely
> to make CI easier.
>
> On Sun, 16 Aug 2020 at 16:05, Mark Thomas  wrote:
> >
> > On 16/08/2020 15:45, sebb wrote:
> > > I've pushed change to the pom which allows compilation on Java14.
> > >
> > > Will that suffice?
> >
> > That certainly works for me. Thanks for doing this.
> >
> > Mark
> >
> >
> > >
> > > On Sun, 16 Aug 2020 at 15:29, sebb  wrote:
> > >>
> > >> On Sun, 16 Aug 2020 at 11:13, Xeno Amess  wrote:
> > >>>
> > >>> I suddenly arise a good idea...
> > >>> How about
> > >>> 1. we release a java 7 version of this repo.
> > >>> 2. we wait for user argue about this.
> > >>
> > >> That has already happened ...
> > >>
> > >> As noted earlier in this thread, Tomcat needs a version that compiles
> on Java 6
> > >>
> > >>> 3. if no users argue about this, we just go forward to 7.
> Otherwise, we
> > >>> re-consider about this.
> > >>
> > >>
> > >>>
> > >>> Mark Thomas  于 2020年8月16日周日 下午6:08写道：
> > >>>
> >  On 15/08/2020 19:00, Gary Gregory wrote:
> > > On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas 
> wrote:
> > >
> > >> On 10/08/2020 17:26, Gary Gregory wrote:
> > >>> As recently done for [EMAIL], I propose we update [LOGGING] and
> >  [DAEMON]
> > >>> from Java 6 to 7 to streamline building on CIs.
> > >>
> > >> -1 for DAEMON. Tomcat 7 depends on it and has a specification
> mandated
> > >> requirement to run on Java 6.
> > >>
> > >
> > > Yikes ;-) how long is rein in antiquity planned to last? ;-)
> > 
> >  Tomcat 7 EOL is 31 March 2021.
> > 
> >  Like most major Tomcat versions, it has been supported for ~10 years
> >  since the first release.
> > 
> >  The scary thing is that the users mailing list still sees questions
> >  about Tomcat 6 and earlier.
> > 
> > > We might need a branch for Tomcat so the project can move ahead in
> a more
> > > modern setting IMO.
> > 
> >  Unless there is a feature that NEEDS Java 7, branching is just
> going to
> >  create unnecessary overhead. My experience of DAEMON over that last
> few
> >  years is the most (all?) of the work has been on the native code
> side.
> >  Therefore, I don't see the harm in keeping the Java side on 1.6 for
> now.
> > 
> >  If the issue is the inability to build with newer Java versions, I
> have
> >  no issue updating the declared minimum version as long as the Java
> code
> >  remains compilable with/for Java 6.
> > 
> >  Mark
> > 
> > >
> > > Gary
> > >
> > >>
> > >> Are there any features / bugs in Jira that require this increase?
> > >>
> > >> Mark
> > >>
> > >>
> -
> > >> 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
> > >
> >
> >
> > -
> > 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: [ALL] Drop Travis in favor of Apache CI and GitHub Actions

[Matt Sicker]

Travis isn't donated; the ASF pays for a subscription of some sort.
It's likely discounted, but it's still ASF infra in that sense.

On Sat, 15 Aug 2020 at 16:09, Gilles Sadowski  wrote:
>
> 2020-08-15 22:51 UTC+02:00, Geoffrey Blake :
> > Not familiar with Apache CI, but github actions do not support Arm builds.
> > Arm should be recognized as a first class build target these days.  Travis
> > allows Arm builds so not sure about the reasoning for moving off.
>
> Also, is Travis computing time a donation to the ASF?
> If so, we could continue using it for providing "convenience"
> builds for various architectures and thus spare some load on
> the Jenkins cluster, using the latter only for ensuring an
> independent build in a stable environment, and the generation
> of snapshots.
>
> Regards,
> Gilles
>
> >
> > -Geoff
> >
> > On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker  wrote:
> >
> >> Agreed on the GitHub Actions. Neutral about how snapshot sites are
> >>
> >> published since there are multiple methods of doing the same thing,
> >>
> >> though if that's also simple to set up via the action to commit the
> >>
> >> output to the gh-pages branch, I'd say go for it!
> >>
> >>
> >>
> >> On Sat, 15 Aug 2020 at 13:07, Gary Gregory 
> >> wrote:
> >>
> >> >
> >>
> >> > Hi All,
> >>
> >> >
> >>
> >> > In order to ease maintenance, I propose that we drop Travis CI in favor
> >> of
> >>
> >> > Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like
> >> > plenty
> >>
> >> > to me. The exception would be a component with an existing complex
> >> > Travis
> >>
> >> > build that was not or cannot be reproduced in GitHub Actions.
> >>
> >> >
> >>
> >> > Looking ahead, I think we should consider publishing SNAPSHOT sites to
> >>
> >> > GitHub.io.
> >>
> >> >
> >>
> >> > Gary
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> Matt Sicker 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>


-- 
Matt Sicker 

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

Re: [LOGGING][DAEMON] Update Java 6 to 7

[Jochen Wiedmann]

On Sun, Aug 16, 2020 at 12:13 PM Xeno Amess  wrote:

> 2. we wait for user argue about this.

Mark Thomas just did, no need to wait. :-)



-- 

Look, that's why there's rules, understand? So that you think before
you break 'em.

-- (Terry Pratchett, Thief of Time)

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

Re: [ALL] Drop Travis in favor of Apache CI and GitHub Actions

[Rob Tompkins]

> On Aug 16, 2020, at 1:51 PM, Matt Sicker  wrote:
> 
> Travis isn't donated; the ASF pays for a subscription of some sort.
> It's likely discounted, but it's still ASF infra in that sense.

Wow...great point. I had no idea

-Rob

> 
>> On Sat, 15 Aug 2020 at 16:09, Gilles Sadowski  wrote:
>> 
>> 2020-08-15 22:51 UTC+02:00, Geoffrey Blake :
>>> Not familiar with Apache CI, but github actions do not support Arm builds.
>>> Arm should be recognized as a first class build target these days.  Travis
>>> allows Arm builds so not sure about the reasoning for moving off.
>> 
>> Also, is Travis computing time a donation to the ASF?
>> If so, we could continue using it for providing "convenience"
>> builds for various architectures and thus spare some load on
>> the Jenkins cluster, using the latter only for ensuring an
>> independent build in a stable environment, and the generation
>> of snapshots.
>> 
>> Regards,
>> Gilles
>> 
>>> 
>>> -Geoff
>>> 
 On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker  wrote:
>>> 
 Agreed on the GitHub Actions. Neutral about how snapshot sites are
 
 published since there are multiple methods of doing the same thing,
 
 though if that's also simple to set up via the action to commit the
 
 output to the gh-pages branch, I'd say go for it!
 
 
 
 On Sat, 15 Aug 2020 at 13:07, Gary Gregory 
 wrote:
 
> 
 
> Hi All,
 
> 
 
> In order to ease maintenance, I propose that we drop Travis CI in favor
 of
 
> Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like
> plenty
 
> to me. The exception would be a component with an existing complex
> Travis
 
> build that was not or cannot be reproduced in GitHub Actions.
 
> 
 
> Looking ahead, I think we should consider publishing SNAPSHOT sites to
 
> GitHub.io.
 
> 
 
> Gary
 
 
 
 
 
 
 
 --
 
 Matt Sicker 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> 
> -- 
> Matt Sicker 
> 
> -
> 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: [ALL] Drop Travis in favor of Apache CI and GitHub Actions

[Gilles Sadowski]

2020-08-16 19:50 UTC+02:00, Matt Sicker :
> Travis isn't donated; the ASF pays for a subscription of some sort.
> It's likely discounted, but it's still ASF infra in that sense.

Then the question becomes: What's ASF's best interest?
Because, as a user of the "service" (here: automatic builds),
we don't really care whether it is provided by "Vendor A" or
"Vendor B".
If the Travis service is redundant, is there any willingness to
cut the cost by using an equivalent GitHub service?
Will if reduce spending if we stop using Travis?

Gilles

> On Sat, 15 Aug 2020 at 16:09, Gilles Sadowski  wrote:
>>
>> 2020-08-15 22:51 UTC+02:00, Geoffrey Blake :
>> > Not familiar with Apache CI, but github actions do not support Arm
>> > builds.
>> > Arm should be recognized as a first class build target these days.
>> > Travis
>> > allows Arm builds so not sure about the reasoning for moving off.
>>
>> Also, is Travis computing time a donation to the ASF?
>> If so, we could continue using it for providing "convenience"
>> builds for various architectures and thus spare some load on
>> the Jenkins cluster, using the latter only for ensuring an
>> independent build in a stable environment, and the generation
>> of snapshots.
>>
>> Regards,
>> Gilles
>>
>> >
>> > -Geoff
>> >
>> > On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker  wrote:
>> >
>> >> Agreed on the GitHub Actions. Neutral about how snapshot sites are
>> >>
>> >> published since there are multiple methods of doing the same thing,
>> >>
>> >> though if that's also simple to set up via the action to commit the
>> >>
>> >> output to the gh-pages branch, I'd say go for it!
>> >>
>> >>
>> >>
>> >> On Sat, 15 Aug 2020 at 13:07, Gary Gregory 
>> >> wrote:
>> >>
>> >> >
>> >>
>> >> > Hi All,
>> >>
>> >> >
>> >>
>> >> > In order to ease maintenance, I propose that we drop Travis CI in
>> >> > favor
>> >> of
>> >>
>> >> > Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like
>> >> > plenty
>> >>
>> >> > to me. The exception would be a component with an existing complex
>> >> > Travis
>> >>
>> >> > build that was not or cannot be reproduced in GitHub Actions.
>> >>
>> >> >
>> >>
>> >> > Looking ahead, I think we should consider publishing SNAPSHOT sites
>> >> > to
>> >>
>> >> > GitHub.io.
>> >>
>> >> >
>> >>
>> >> > Gary
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Matt Sicker 

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

Question about "StringUtils.indexOfAny" functionality/test

[Eric Peters]

Hi ~

I'm in the process of porting apache commons lang to scala, so it can
transpile to javascript/scala native. (
https://github.com/er1c/scala-apache-commons-lang3 FWIW)

One test I'm currently investigating is this line:

https://github.com/apache/commons-lang/blob/master/src/test/java/org/apache/commons/lang3/StringUtilsEqualsIndexOfTest.java#L401

What exactly is the difference between CharSequence... and CharSequence
signatures on the usage of indexOfAny.  I'm trying to figure out why the
expected index is "0" instead of "2"

Thanks!

-Eric

[VOTE] Release Apache Commons JCS 3.0 based on RC1

[Thomas Vandahl]

This has been a major overhaul of JCS with many adjustments for JDK 8+,
better concurrency and logging. Finally, I would like to
release Apache Commons JCS 3.0.

Apache Commons JCS 3.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/jcs/3.0-RC1 (svn
revision 40998)

The Git tag commons-jcs3-3.0-rc1 commit for this RC is
2c281fc779770f15f8d7cf4421a47eddbb422a1d which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=2c281fc779770f15f8d7cf4421a47eddbb422a1d

You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-jcs.git
--branch commons-jcs3-3.0-rc1 commons-jcs3-3.0-rc1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1522/org/apache/commons/commons-jcs3/3.0/

These are the distribution artifacts and their hashes:

commons-jcs3-dist-3.0-src.zip=
7948c2ec95c034c86a794d7cf749b507ca697bd5c1041a1666405a0ffa99878ff93aba40f8fb257fc923b107b20c50fe4c941a631d06549751e5350b886590ef
commons-jcs3-dist-3.0-src.tar.gz=
f5aaec51851beff43605cc6392b8b428b347c4aa9014760f944281fb7e92db413f5a688276ad204522131597c691e797a68317f0625b05abc605a3407c4aa151
commons-jcs3-dist-3.0-bin.zip=
18da4ec7dc823f14b5cf8e9410d182fdb5c8fff1c6b2e66e5aecced882452e3498159acfb4c31d7b90203201ea8266aaf6d9f20bd637a73e03d3d3202ecc045c
commons-jcs3-dist-3.0-bin.tar.gz=
b09f11d7875ed3bb0fe704eba90436fd63b73427aca8960e408e8823a998a7f19f8aa4ec43dd50c0b29da228e9e3b8d5388dd4d8bfeb6f39eb84866792467160

These are the Maven artifacts and their hashes:

commons-jcs3-core-3.0-javadoc.jar=
9cde0fca72a48c8f02abe1ec488fb90d1089afdfed5de004a87d0dff07a9e472fc23a3712d935097468ddcb5daead2dd865a5f45d18e119ae271c780f6e6aa0e
commons-jcs3-core-3.0-sources.jar=
113d3a862f276aa4010aa31870c284fe1418859e8fc596ff26bb818e4cd70b7d592307a89012e4ea8170f6b5b2580abc620647128bdbaa864564a4c5b108f81d
commons-jcs3-core-3.0-test-sources.jar=
104536381ca3c82049ce2bd02fdb34d226ca0bb5741783af3a833412809ea3d3929d46a8bfd0db4e72b93938a28c1ed33c473c2f42c5ed6c918709bc946f2588
commons-jcs3-core-3.0-tests.jar=
5d6f4dabb316d7a6d186ae680fc561f1651ace5a2d4f08d1ef00d3331b32c216ea20863c9947e4092ce6b0e819d39e4e994678f4d4775a334d83d7c498439530
commons-jcs3-core-3.0.jar=
60aa6f6ef00dc5c0050da196bc7f3b2560bd002ec0f67b85f78a42571dbd400651456c26643c7f0123698405c07f8104bcd9fd67dea5788f5c348c48826833b2
commons-jcs3-jcache-extras-3.0-javadoc.jar=
2ed5254bfb88720cd7c8cdb49ba9749ab215d4671018d177dd8f3fd52dcd42c4f1dfeb0c7e0a81aac5a25e2a42a6d0e983f29134515d9681ea9c2e083d92595a
commons-jcs3-jcache-extras-3.0-sources.jar=
e0f8562ea8322efc03cf946ede568ccae7f32586dfd7cf8e6e06b27de6e787b5830342355da3354b7035194f6f54931a939fd6c7d76fc2753620bd09557f3501
commons-jcs3-jcache-extras-3.0-test-sources.jar=
080080deee43954d3bb55287c65df8b3507f14acc16759c62ffb56b852bd46633ae3d82c738627a9713e0718827a4657c2321f1f6814e345207c291a44e04ae8
commons-jcs3-jcache-extras-3.0-tests.jar=
9c3ea32d8f0b809eadf679559a1800f6d0d77ade0dec7755a5ed7b4872d735671c994a4cd2184e5da418a22bb19f97c0c8d51941f6a57ee93b1d3945bf32ce1b
commons-jcs3-jcache-extras-3.0.jar=
0fab536bd0fa49421332bd92c7c42d8329977a1b9d51354b7116103c75518030bf45b304304bcfa3a87d1e2e0c8ea8deb298a172d47e8e2f9ea06889bb8d3ad5
commons-jcs3-jcache-openjpa-3.0-javadoc.jar=
2471748e891c266964a755b05bfd525e6ad240a91ff7b2c88e80d5c40caba31ed14fee955a4e858b16915664902c76b337828b4e69e2e2e95267da4ca2dc53de
commons-jcs3-jcache-openjpa-3.0-sources.jar=
e1e62570e4d4dffb85fedefc1362c52872e95d78d20d4dcc83214ab32231f36e134ab3af53aef30f57f205e50c425004c3a749b830bbd589a5e9a58669c62d1c
commons-jcs3-jcache-openjpa-3.0-test-sources.jar=
716137ca51679ed09e3efeed6ae0619b0492a1f0579bf1d20eb20a3f5fa236c99c44b32f6fb21f512b55952d314f7fe579d6eb961e2ffd51f24ed7d4564cfb20
commons-jcs3-jcache-openjpa-3.0-tests.jar=
c7feaf654396380d1513be32a0873ad4408442a077de7f8b2341f067d672d1db7615dd902441ccb634406fa989fdf19384b0018637d4cea5fb7efd0455633cb3
commons-jcs3-jcache-openjpa-3.0.jar=
b279161f879f994a0d9e36861f2847b96d0b7f2658c9786ad219970019b233af6e585dd11f71b2981e8abfebda35dd63256e25a290b77cf6e5bbcdb603ba0dcb
commons-jcs3-jcache-3.0-cdi.jar=
0c5e8750a7ac7f1936429985fd0fb425f2ac33eb0ad851287a9ced00bbe5f6a5bff18cfb68854e8062b9e216b9083eb5527b399dd40fa9df1a3d06b97e3515e6
commons-jcs3-jcache-3.0-javadoc.jar=
a4877b8f0d91fbb382f1313415fd6191cb4379d7b5b6b151024fdff887a8c3a1bc08e17578a31a6311ac5457c5436ddb30e8d277c43338a6705cabedce9cee7b
commons-jcs3-jcache-3.0-nocdi.jar=
973eba23cd7df050b00c44819a2c2cb5bcc5b81ff1ac7c9a3d731e0e396315585087484f793afd742c82f7a845d98c5929e55ccd3dcfbea017f6a681cd654704
commons-jcs3-jcache-3.0-sources.jar=
79751991acdd11abe36fb9ecfc99c0cd9cbfd0b8c0b09dd7543a9dc07dbf3e15b8f8bc100795e7fb01199fb8eec7abfea539c257b9f46847fd4ffc3938e55d05
commons-jcs3-jcache-3.0-test-sources.jar=
982521c03bf2641cdcad9fe0bfb561b3c096f71f9bd4f772e8cfc7c360bb9e74a43b4bcd695c0ffb484959e9946006b3aa47000475f8b509cac61fafd4bbe9c9
commons-jcs3-jcache-3.0-tests.jar=
fd36177e9f6dae4afe8

Re: [VOTE] Release Apache Commons JCS 3.0 based on RC1

[Thomas Vandahl]

On 17.08.20 08:29, Thomas Vandahl wrote:
>   [X] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...

Bye, Thomas

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