Re: The case for a Commons component

2021-05-05 Thread Ralph Goers

> On May 5, 2021, at 11:13 AM, Gilles Sadowski  wrote:
> 
> Le mer. 5 mai 2021 à 17:44, Ralph Goers  a écrit :
>> 
>> 
>> 
>>> On May 5, 2021, at 6:38 AM, Gilles Sadowski  wrote:
>>> 
>>> Le mar. 4 mai 2021 à 02:49, Ralph Goers  a 
>>> écrit :
 
 I apologize. I started another thread regarding the vote before seeing 
 this.
>>> 
>>> No problem.
>>> 
 Maybe that will get more attention?
>>> 
>>> It doesn't seem so. :-}
>>> 
>>> IMHO, valid answers have been given to the statements/questions
>>> from people who didn't vote +1.
>>> The very low turnout makes the arithmetics of the result fairly 
>>> subjective...
>>> 
>>> The optimistic view is that
>>> 1. most people don't care (that the repository is created),
>>> 2. there is no reason to doubt the infos provided by actual users of
>>> those codes,
>>> 3. there is an embryo of a community (perhaps not viable, but only
>>> the future can tell...),[1]
>>> 4. the same kind of welcoming gestures should apply for the proposed
>>> contributions, as for the attempt to resuscitate "Commons Graph"[2],
>>> even if some of the PMC might arguably prefer another option.
>> 
>> Regardless, following https://www.apache.org/foundation/voting.html 
>>  indicates that this vote is 
>> not going to pass.
> 
> How so?
> [It's not about a code change; and no "technical argument" can be invoked.]

It looks like you didn’t read the page. For clarity I am copying it here

"Votes on procedural issues follow the common format of majority rule unless 

otherwise stated. That is, if there are more favourable votes than unfavourable 
ones, 

the issue is considered to have passed -- regardless of the number of votes in 
each 

category. (If the number of votes seems too small to be representative of a 
community

 consensus, the issue is typically not pursued. However, see the description of 

lazy consensus  
for a modifying factor.)"


So a procedural vote requires a majority. But note that it also calls out that 
if the number of voters 
seems too small then the issue is usually not pursued.  Both of these describe 
this situation perfectly. 
The vote did not get a majority of binding votes (it was a tie) and the number 
of votes was very small.


> 
>> You can’t assert lazy consensus on an explicit vote.  If you had started 
>> this as a lazy consensus vote it
>> is likely it would have still gotten a -1 vote since both Sebb and Emmanuel 
>> have voice opposition.
> 


> A "veto" does not apply here.
> Hence my remark on the "arithmetics" since the total tally is slightly
> "pro" although the PMC tally is slightly "con”.

Where did I use the word “veto”? I never used the word “veto”.  There are 
essentially 3 ways to vote, 
Yes, No, and Abstain. In a procedural vote + or -1 represent an abstention. 
Anything less than 0 is 
a No and anything greater is a Yes. So saying there were -1 votes implies there 
are “No” votes and 
therefore there is no consensus.

Ralph




Re: The case for a Commons component

2021-05-05 Thread Emmanuel Bourg

Le 2021-05-05 20:31, Oliver Heger a écrit :


What about the sandbox? IIUC, every committer can start a new
component there. If then a community forms around this component, it
can move to proper (which would then require a vote).


With the various source hosting solutions available today we no longer 
need the sandbox, and I think we should discontinue this practice. The 
machine learning library could as well start its life on GitHub, it 
doesn't need Apache Commons.


Emmanuel Bourg

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



Re: The case for a Commons component

2021-05-05 Thread Gilles Sadowski
Le mer. 5 mai 2021 à 20:33, Oliver Heger
 a écrit :
>
>
>
> Am 05.05.21 um 20:26 schrieb Gilles Sadowski:
> > Le mer. 5 mai 2021 à 18:57, Gary Gregory  a écrit :
> >>
> >> IMO the lack of +1s shows the lack of appetite to manage another component
> >
> > That's certainly true.
> > And nobody is forced to do anything.
> >
> > When the other CM spin-offs started, there was only _one_ person
> > willing to do the work.
>
> What about the sandbox? IIUC, every committer can start a new component
> there. If then a community forms around this component, it can move to
> proper (which would then require a vote).
>
> Would this be an option to get started?

[Graph] is listed in the sandbox[1], yet when someone expressed a willingness
to contribute, we had a "git" repository created[2] (even though the
web site has
remained outdated[3], probably because the attempt was short-lived).

So indeed, I could have already created the repository a few weeks ago...

However in this instance, what would it mean to have codes that have lived
within a "proper" component for 6 years and more be moved to "sandbox"?

Regards,
Gilles

[1] http://commons.apache.org/sandbox/commons-graph/
[2] https://gitbox.apache.org/repos/asf?p=commons-graph.git
[3] http://commons.apache.org/sandbox/commons-graph/source-repository.html

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



Re: The case for a Commons component

2021-05-05 Thread Oliver Heger




Am 05.05.21 um 20:26 schrieb Gilles Sadowski:

Le mer. 5 mai 2021 à 18:57, Gary Gregory  a écrit :


IMO the lack of +1s shows the lack of appetite to manage another component


That's certainly true.
And nobody is forced to do anything.

When the other CM spin-offs started, there was only _one_ person
willing to do the work.


What about the sandbox? IIUC, every committer can start a new component 
there. If then a community forms around this component, it can move to 
proper (which would then require a vote).


Would this be an option to get started?

Oliver



Gilles


[...]


-
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: The case for a Commons component

2021-05-05 Thread Gilles Sadowski
Le mer. 5 mai 2021 à 18:57, Gary Gregory  a écrit :
>
> IMO the lack of +1s shows the lack of appetite to manage another component

That's certainly true.
And nobody is forced to do anything.

When the other CM spin-offs started, there was only _one_ person
willing to do the work.

Gilles

> [...]

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



Re: The case for a Commons component

2021-05-05 Thread Gilles Sadowski
Le mer. 5 mai 2021 à 17:44, Ralph Goers  a écrit :
>
>
>
> > On May 5, 2021, at 6:38 AM, Gilles Sadowski  wrote:
> >
> > Le mar. 4 mai 2021 à 02:49, Ralph Goers  a 
> > écrit :
> >>
> >> I apologize. I started another thread regarding the vote before seeing 
> >> this.
> >
> > No problem.
> >
> >> Maybe that will get more attention?
> >
> > It doesn't seem so. :-}
> >
> > IMHO, valid answers have been given to the statements/questions
> > from people who didn't vote +1.
> > The very low turnout makes the arithmetics of the result fairly 
> > subjective...
> >
> > The optimistic view is that
> >  1. most people don't care (that the repository is created),
> >  2. there is no reason to doubt the infos provided by actual users of
> > those codes,
> >  3. there is an embryo of a community (perhaps not viable, but only
> > the future can tell...),[1]
> >  4. the same kind of welcoming gestures should apply for the proposed
> > contributions, as for the attempt to resuscitate "Commons Graph"[2],
> > even if some of the PMC might arguably prefer another option.
>
> Regardless, following https://www.apache.org/foundation/voting.html 
>  indicates that this vote is 
> not going to pass.

How so?
[It's not about a code change; and no "technical argument" can be invoked.]

> You can’t assert lazy consensus on an explicit vote.  If you had started this 
> as a lazy consensus vote it
> is likely it would have still gotten a -1 vote since both Sebb and Emmanuel 
> have voice opposition.

A "veto" does not apply here.
Hence my remark on the "arithmetics" since the total tally is slightly
"pro" although the PMC tally is slightly "con".

Gilles

>
> Ralph
>

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



Re: Jacoco 0.8.7

2021-05-05 Thread Gary Gregory
Dependabot will pick up the new release within a day or so.

Gary

On Wed, May 5, 2021, 07:11 Melloware  wrote:

> Jacoco 0.8.7 was released:
>
> https://github.com/jacoco/jacoco/releases/tag/v0.8.7
>
> Any commons projects using Jacoco like BeanUtils2 should upgrade as it
> fixes JDK 15 and 16 issues.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: The case for a Commons component

2021-05-05 Thread Gary Gregory
IMO the lack of +1s shows the lack of appetite to manage another component
that not "common" to "most" Java apps, where I use quotes to understand
that YMMV.

Personally, my plate is full with the current slate of components in which
I participate.

Gary

On Wed, May 5, 2021, 09:38 Gilles Sadowski  wrote:

> Le mar. 4 mai 2021 à 02:49, Ralph Goers  a
> écrit :
> >
> > I apologize. I started another thread regarding the vote before seeing
> this.
>
> No problem.
>
> > Maybe that will get more attention?
>
> It doesn't seem so. :-}
>
> IMHO, valid answers have been given to the statements/questions
> from people who didn't vote +1.
> The very low turnout makes the arithmetics of the result fairly
> subjective...
>
> The optimistic view is that
>   1. most people don't care (that the repository is created),
>   2. there is no reason to doubt the infos provided by actual users of
> those codes,
>   3. there is an embryo of a community (perhaps not viable, but only
> the future can tell...),[1]
>   4. the same kind of welcoming gestures should apply for the proposed
> contributions, as for the attempt to resuscitate "Commons Graph"[2],
> even if some of the PMC might arguably prefer another option.
>
> Regards,
> Gilles
>
> [1] Three Java implementations of the SOFM turned up as the top results
> of a web search; none seem to include multi-threading.
> [2] https://gitbox.apache.org/repos/asf?p=commons-graph.git
>
>
> >
> > Ralph
> >
> > > On May 2, 2021, at 3:59 PM, Gilles Sadowski 
> wrote:
> > >
> > > Hi.
> > >
> > >> [... Discussion about GA data-structures...]
> > >
> > > I'd suggest that we finalize the [Vote] before getting into the
> > > details...
> > >
> > > Currently, there have been votes by:
> > >  Emmanuel Bourg (-1)
> > >  Sebastian Bazley (-0)
> > >  Ralph Goers (+0)
> > >  Paul King (+1)
> > >
> > > So currently, the discussion should be focused on settling to the
> > > issues put forward by the opponents to having this new component:
> > >  * Problem 1: Functionality should go somewhere else (Emmanuel, Sebb)
> > >  * Problem 2: Who will contribute? (Ralph)
> > >
> > > Partial answers have been given.
> > > We need more opinions (and votes).
> > >
> > > Regards,
> > > Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: The case for a Commons component

2021-05-05 Thread Ralph Goers


> On May 5, 2021, at 6:38 AM, Gilles Sadowski  wrote:
> 
> Le mar. 4 mai 2021 à 02:49, Ralph Goers  a écrit :
>> 
>> I apologize. I started another thread regarding the vote before seeing this.
> 
> No problem.
> 
>> Maybe that will get more attention?
> 
> It doesn't seem so. :-}
> 
> IMHO, valid answers have been given to the statements/questions
> from people who didn't vote +1.
> The very low turnout makes the arithmetics of the result fairly subjective...
> 
> The optimistic view is that
>  1. most people don't care (that the repository is created),
>  2. there is no reason to doubt the infos provided by actual users of
> those codes,
>  3. there is an embryo of a community (perhaps not viable, but only
> the future can tell...),[1]
>  4. the same kind of welcoming gestures should apply for the proposed
> contributions, as for the attempt to resuscitate "Commons Graph"[2],
> even if some of the PMC might arguably prefer another option.

Regardless, following https://www.apache.org/foundation/voting.html 
 indicates that this vote is not 
going to pass. 
You can’t assert lazy consensus on an explicit vote.  If you had started this 
as a lazy consensus vote it 
is likely it would have still gotten a -1 vote since both Sebb and Emmanuel 
have voice opposition.

Ralph



Re: Jacoco 0.8.7

2021-05-05 Thread Gilles Sadowski
Hi.

Le mer. 5 mai 2021 à 13:11, Melloware  a écrit :
>
> Jacoco 0.8.7 was released:

Thanks for the info.

>
> https://github.com/jacoco/jacoco/releases/tag/v0.8.7
>
> Any commons projects using Jacoco like BeanUtils2 should upgrade

It seems that this is usually done through "Commons Parent":
https://downloads.apache.org/commons/commons-parent/RELEASE-NOTES.txt

Gilles

> as it
> fixes JDK 15 and 16 issues.

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



Re: The case for a Commons component

2021-05-05 Thread Gilles Sadowski
Le mar. 4 mai 2021 à 02:49, Ralph Goers  a écrit :
>
> I apologize. I started another thread regarding the vote before seeing this.

No problem.

> Maybe that will get more attention?

It doesn't seem so. :-}

IMHO, valid answers have been given to the statements/questions
from people who didn't vote +1.
The very low turnout makes the arithmetics of the result fairly subjective...

The optimistic view is that
  1. most people don't care (that the repository is created),
  2. there is no reason to doubt the infos provided by actual users of
those codes,
  3. there is an embryo of a community (perhaps not viable, but only
the future can tell...),[1]
  4. the same kind of welcoming gestures should apply for the proposed
contributions, as for the attempt to resuscitate "Commons Graph"[2],
even if some of the PMC might arguably prefer another option.

Regards,
Gilles

[1] Three Java implementations of the SOFM turned up as the top results
of a web search; none seem to include multi-threading.
[2] https://gitbox.apache.org/repos/asf?p=commons-graph.git


>
> Ralph
>
> > On May 2, 2021, at 3:59 PM, Gilles Sadowski  wrote:
> >
> > Hi.
> >
> >> [... Discussion about GA data-structures...]
> >
> > I'd suggest that we finalize the [Vote] before getting into the
> > details...
> >
> > Currently, there have been votes by:
> >  Emmanuel Bourg (-1)
> >  Sebastian Bazley (-0)
> >  Ralph Goers (+0)
> >  Paul King (+1)
> >
> > So currently, the discussion should be focused on settling to the
> > issues put forward by the opponents to having this new component:
> >  * Problem 1: Functionality should go somewhere else (Emmanuel, Sebb)
> >  * Problem 2: Who will contribute? (Ralph)
> >
> > Partial answers have been given.
> > We need more opinions (and votes).
> >
> > Regards,
> > Gilles

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



Jacoco 0.8.7

2021-05-05 Thread Melloware

Jacoco 0.8.7 was released:

https://github.com/jacoco/jacoco/releases/tag/v0.8.7

Any commons projects using Jacoco like BeanUtils2 should upgrade as it 
fixes JDK 15 and 16 issues.




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