Re: [COLLECTIONS] 4.5.0-M2 is next to capture latest bloom filter code
The only changes I am considering are to remove any stream usage within the code, no external changes. Additionally, there may be some new documentation coming but that can wait until after M2. Thanks for all your hard work on this. Claude On Wed, Jun 12, 2024 at 7:30 PM Gary D. Gregory wrote: > HI All, Claude W, Alex H: > > I would like to cut a 4.5.0-M2 RC later this week to capture latest bloom > filter code. > > Feel free to ask me to hold back if you plan further changes first. > > TY! > Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [COLLECTIONS] 4.5.0-M2 is next to capture latest bloom filter code
It would be better IMO to have the updated documentation for M2 but not critical, let me know if you think you can do it "soon" (say within a week) or if it's just on a longer term to-do list. TY, Gary On Thu, Jun 13, 2024, 3:39 AM Claude Warren wrote: > The only changes I am considering are to remove any stream usage within the > code, no external changes. Additionally, there may be some new > documentation coming but that can wait until after M2. > > Thanks for all your hard work on this. > Claude > > On Wed, Jun 12, 2024 at 7:30 PM Gary D. Gregory > wrote: > > > HI All, Claude W, Alex H: > > > > I would like to cut a 4.5.0-M2 RC later this week to capture latest bloom > > filter code. > > > > Feel free to ask me to hold back if you plan further changes first. > > > > TY! > > Gary > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > -- > LinkedIn: http://www.linkedin.com/in/claudewarren >
Re: [DRAFT] June Report to the Board
On 2024/06/12 22:25:29 sebb wrote: > On Wed, 12 Jun 2024 at 18:58, Gary D. Gregory wrote: > > > > On 2024/06/12 17:17:24 Phil Steitz wrote: > > > > +1 > > > I have had to filter out most of the messages and once I do that, there is > > > almost no actual discussion on-list. I am worried that when people do try > > > to start discussion, the messages are being missed. I personally see the > > > lack of ml discussion as a problem. Lots of code changes are happening > > > with no discussion, other than maybe random nits on PRs ending up in > > > github > > > threads that don't end up organized that well in list archives. This > > > problem is not unique to Commons. > > > > Hi Phil, > > > > We had a discussion a while back about creating a "bot" email list but: > > - no one actually proposed anything concrete and did any work > > That's not strictly true. > There were various suggestions (e.g. run dependabot less frequently, We run it once a week which feels to me like the sweet spot. We _used to_, like Log4j does, run it once a day. > or only on demand) The would defeats one of the purposes of the "bot" part of Dependabot. but they were shouted down, so no action was taken > as it would have been vetoed. > > > - we already have bot lists like "commit", "notifications", "issues", can't > > we reuse those? > > That is part of the problem: the commits list is overrun with > dependabot commits. I don't know what you are proposing here, a new list called "gitbot"? Gary > > > - I don't know if GitHub lets us configure target emails for "I created a > > PR" (or someone commented on a PR), vs. other types of messages. > > > Gary > > > > > > > > Phil > > > > > > > > > > > > > > > > Most if not all of our increasing contributions are coming in > > > > > through GitHub pull requests. This is working well for us: GitHub PRs > > > > with > > > > > continuous integration builds providing great infrastructure and > > > > validation of > > > > > PRs and the existing code base. The flip side is that the increase in > > > > GitHub > > > > > usage is matched by a decrease in Jira usage. > > > > > > > > > > Gary > > > > > > > > > > - > > > > > 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: [COLLECTIONS] 4.5.0-M2 is next to capture latest bloom filter code
Given the hectic nature of my life at the moment, I would say longer than a week. Would it make sense to do an M2 to verify the APIs and then lock down and comb through documentation with a fine tooth comb, looking for errors and missing explanations before an M3 that has no code, just documentation changes? Claude On Thu, Jun 13, 2024 at 12:47 PM Gary Gregory wrote: > It would be better IMO to have the updated documentation for M2 but not > critical, let me know if you think you can do it "soon" (say within a week) > or if it's just on a longer term to-do list. > > TY, > Gary > > On Thu, Jun 13, 2024, 3:39 AM Claude Warren wrote: > > > The only changes I am considering are to remove any stream usage within > the > > code, no external changes. Additionally, there may be some new > > documentation coming but that can wait until after M2. > > > > Thanks for all your hard work on this. > > Claude > > > > On Wed, Jun 12, 2024 at 7:30 PM Gary D. Gregory > > wrote: > > > > > HI All, Claude W, Alex H: > > > > > > I would like to cut a 4.5.0-M2 RC later this week to capture latest > bloom > > > filter code. > > > > > > Feel free to ask me to hold back if you plan further changes first. > > > > > > TY! > > > Gary > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > -- > > LinkedIn: http://www.linkedin.com/in/claudewarren > > > -- LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [LANG] Add Any Checks for Not Checks in StringUtils
On 2024/06/13 00:22:13 Department 8 wrote:
> I see the point you are making. Thanks for taking the time to review it.
And thank you for engaging with us on improving this component! :-)
Gary
>
> On Wed, Jun 12, 2024, 23:30 Gary Gregory wrote:
>
> > See also my comment in the PR.
> >
> > Gary
> >
> > On Wed, Jun 12, 2024, 1:22 PM Department 8
> > wrote:
> >
> > > Haha! It was in fact because of other methods that have simple negation
> > > that I thought maybe giving a PR would be Okay :)
> > >
> > > I think that many times, it is the Boolean Logic that may trivial for us,
> > > but for some who may be using them to have a utility methods like
> > > isNotBlank aka (!isBlank) maybe helpful and would de-clutter the client
> > > code to a good extent. So it is more of a clean fix for them.
> > >
> > > Another way may be to - do a for loop on all of them and once you find
> > > NotBlank to be true you return true, else iterate till end and return
> > false
> > > (the actual negated logic of isAllBlank) but that would mean for the
> > > clients of the API to write that helper function for themselves. So this
> > > can provide an easy wrap.
> > >
> > > On Wed, 12 Jun 2024 at 22:43, Alex Herbert
> > > wrote:
> > >
> > > > On Wed, 12 Jun 2024 at 18:03, Department 8
> > > > wrote:
> > > >
> > > > > Sorry Alex just now saw your email, before sending out the PR!
> > > > >
> > > > > I had done just for isAllEmpty and isAllBlank.
> > > > >
> > > > > Can you tell me more on what can be done, when you said the
> > following:
> > > > >
> > > > > If you are simply negating the result of another method then this use
> > > > case
> > > > > may be better served with addition of a suitable example to the
> > javadoc
> > > > of
> > > > > the method you are negating.
> > > > >
> > > > > Like do you want me to add examples of use-cases?
> > > > >
> > > >
> > > > I've seen the PR. The new methods are a simple boolean negation of
> > > existing
> > > > methods. So these are not adding functionality that cannot be achieved
> > > with
> > > > the current API.
> > > >
> > > > Note that a quick check in StringUtils for 'return !' finds these
> > > methods:
> > > >
> > > > public static boolean isNoneBlank(final CharSequence... css) {
> > > > return !isAnyBlank(css);
> > > > }
> > > >
> > > > public static boolean isNoneEmpty(final CharSequence... css) {
> > > > return !isAnyEmpty(css);
> > > > }
> > > >
> > > > There are two others for single CharSequence args as well: isNotBlank
> > and
> > > > isNotEmpty.
> > > >
> > > > So it is not without precedent to add more methods that are simple
> > > > negations. However we have to consider if this is code bloat, or if the
> > > > addition of simple negation methods is so useful that it warrants
> > > > inclusion. I would currently consider this as redundant given the lack
> > of
> > > > actual logic in the methods.
> > > >
> > > > Alex
> > > >
> > > >
> > > > >
> > > > > On Wed, 12 Jun 2024 at 22:29, Department 8 > >
> > > > > wrote:
> > > > >
> > > > > > I just realized the subject name is bad. But here are the two small
> > > > > > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> > > > > >
> > > > > > Please find the pull request as here:
> > > > > > https://github.com/apache/commons-lang/pull/1234
> > > > > >
> > > > > > On Wed, 12 Jun 2024 at 21:52, Department 8 <
> > manstein.fe...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Hey!
> > > > > >>
> > > > > >> Recently when using StringUtils in one of our projects I had felt
> > > the
> > > > > >> urgent need to have a utility method like => isAnyNotBlank.
> > > > > >>
> > > > > >> I was able to achieve this using the negation of isAllBlank, so I
> > am
> > > > > >> thinking of introducing the code with all tests.
> > > > > >>
> > > > > >> It is ready to be pushed to PR. Do let me know what you think and
> > > what
> > > > > >> are the next steps for the same?
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [COLLECTIONS] 4.5.0-M2 is next to capture latest bloom filter code
That all sounds good to me. I'll cut a release over the next few days. Gary On Thu, Jun 13, 2024, 9:48 AM Claude Warren wrote: > Given the hectic nature of my life at the moment, I would say longer than a > week. > Would it make sense to do an M2 to verify the APIs and then lock down and > comb through documentation with a fine tooth comb, looking for errors and > missing explanations before an M3 that has no code, just documentation > changes? > > Claude > > On Thu, Jun 13, 2024 at 12:47 PM Gary Gregory > wrote: > > > It would be better IMO to have the updated documentation for M2 but not > > critical, let me know if you think you can do it "soon" (say within a > week) > > or if it's just on a longer term to-do list. > > > > TY, > > Gary > > > > On Thu, Jun 13, 2024, 3:39 AM Claude Warren wrote: > > > > > The only changes I am considering are to remove any stream usage within > > the > > > code, no external changes. Additionally, there may be some new > > > documentation coming but that can wait until after M2. > > > > > > Thanks for all your hard work on this. > > > Claude > > > > > > On Wed, Jun 12, 2024 at 7:30 PM Gary D. Gregory > > > wrote: > > > > > > > HI All, Claude W, Alex H: > > > > > > > > I would like to cut a 4.5.0-M2 RC later this week to capture latest > > bloom > > > > filter code. > > > > > > > > Feel free to ask me to hold back if you plan further changes first. > > > > > > > > TY! > > > > Gary > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > -- > > > LinkedIn: http://www.linkedin.com/in/claudewarren > > > > > > > > -- > LinkedIn: http://www.linkedin.com/in/claudewarren >
Re: [LANG] Add Any Checks for Not Checks in StringUtils
No problem this was actually my first time engaging in any Open source
contribution, so it was a good way to know what should be done in quality
and quantity for any open source contribution, so thanks for helping me
learn as well.
On Thu, Jun 13, 2024, 19:13 Gary D. Gregory wrote:
> On 2024/06/13 00:22:13 Department 8 wrote:
> > I see the point you are making. Thanks for taking the time to review it.
>
> And thank you for engaging with us on improving this component! :-)
>
> Gary
>
> >
> > On Wed, Jun 12, 2024, 23:30 Gary Gregory wrote:
> >
> > > See also my comment in the PR.
> > >
> > > Gary
> > >
> > > On Wed, Jun 12, 2024, 1:22 PM Department 8
> > > wrote:
> > >
> > > > Haha! It was in fact because of other methods that have simple
> negation
> > > > that I thought maybe giving a PR would be Okay :)
> > > >
> > > > I think that many times, it is the Boolean Logic that may trivial
> for us,
> > > > but for some who may be using them to have a utility methods like
> > > > isNotBlank aka (!isBlank) maybe helpful and would de-clutter the
> client
> > > > code to a good extent. So it is more of a clean fix for them.
> > > >
> > > > Another way may be to - do a for loop on all of them and once you
> find
> > > > NotBlank to be true you return true, else iterate till end and return
> > > false
> > > > (the actual negated logic of isAllBlank) but that would mean for the
> > > > clients of the API to write that helper function for themselves. So
> this
> > > > can provide an easy wrap.
> > > >
> > > > On Wed, 12 Jun 2024 at 22:43, Alex Herbert >
> > > > wrote:
> > > >
> > > > > On Wed, 12 Jun 2024 at 18:03, Department 8 <
> manstein.fe...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Sorry Alex just now saw your email, before sending out the PR!
> > > > > >
> > > > > > I had done just for isAllEmpty and isAllBlank.
> > > > > >
> > > > > > Can you tell me more on what can be done, when you said the
> > > following:
> > > > > >
> > > > > > If you are simply negating the result of another method then
> this use
> > > > > case
> > > > > > may be better served with addition of a suitable example to the
> > > javadoc
> > > > > of
> > > > > > the method you are negating.
> > > > > >
> > > > > > Like do you want me to add examples of use-cases?
> > > > > >
> > > > >
> > > > > I've seen the PR. The new methods are a simple boolean negation of
> > > > existing
> > > > > methods. So these are not adding functionality that cannot be
> achieved
> > > > with
> > > > > the current API.
> > > > >
> > > > > Note that a quick check in StringUtils for 'return !' finds these
> > > > methods:
> > > > >
> > > > > public static boolean isNoneBlank(final CharSequence... css) {
> > > > > return !isAnyBlank(css);
> > > > > }
> > > > >
> > > > > public static boolean isNoneEmpty(final CharSequence... css) {
> > > > > return !isAnyEmpty(css);
> > > > > }
> > > > >
> > > > > There are two others for single CharSequence args as well:
> isNotBlank
> > > and
> > > > > isNotEmpty.
> > > > >
> > > > > So it is not without precedent to add more methods that are simple
> > > > > negations. However we have to consider if this is code bloat, or
> if the
> > > > > addition of simple negation methods is so useful that it warrants
> > > > > inclusion. I would currently consider this as redundant given the
> lack
> > > of
> > > > > actual logic in the methods.
> > > > >
> > > > > Alex
> > > > >
> > > > >
> > > > > >
> > > > > > On Wed, 12 Jun 2024 at 22:29, Department 8 <
> manstein.fe...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I just realized the subject name is bad. But here are the two
> small
> > > > > > > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> > > > > > >
> > > > > > > Please find the pull request as here:
> > > > > > > https://github.com/apache/commons-lang/pull/1234
> > > > > > >
> > > > > > > On Wed, 12 Jun 2024 at 21:52, Department 8 <
> > > manstein.fe...@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hey!
> > > > > > >>
> > > > > > >> Recently when using StringUtils in one of our projects I had
> felt
> > > > the
> > > > > > >> urgent need to have a utility method like => isAnyNotBlank.
> > > > > > >>
> > > > > > >> I was able to achieve this using the negation of isAllBlank,
> so I
> > > am
> > > > > > >> thinking of introducing the code with all tests.
> > > > > > >>
> > > > > > >> It is ready to be pushed to PR. Do let me know what you think
> and
> > > > what
> > > > > > >> are the next steps for the same?
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
