Re: [all] Rethinking dev@

[Jochen Wiedmann]

On Fri, Jun 24, 2016 at 9:13 PM, Benedikt Ritter  wrote:

> we should stick to having one mailing list. If a component becomes so
> specialized that the PMC fails to follow what is going on (like what
> happend with CM), it is time to move that component out of commons. Having
> separat mailing lists will only make things worse, IMHO.

The events regarding [math] were happening on the common mailing list,
right before our eyes. Nevertheless. we didn't notice.

Jochen


-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [all] Rethinking dev@

[Gary Gregory]

On Jun 24, 2016 12:13 PM, "Benedikt Ritter"  wrote:
>
> Hello,
>
> we should stick to having one mailing list. If a component becomes so
> specialized that the PMC fails to follow what is going on (like what
> happend with CM), it is time to move that component out of commons. Having
> separat mailing lists will only make things worse, IMHO.

+1

Gary

>
> Benedikt
>
> Jochen Wiedmann  schrieb am Fr., 24. Juni 2016
> um 16:58 Uhr:
>
> > On Fri, Jun 24, 2016 at 3:58 PM, Ralph Goers 
> > wrote:
> >
> > > Well, it sort of works for the incubator. They are constantly having
> > discussions about how to do it better. And yes, it could work for us if
all
> > the subprojects have to follow the incubator rules, such as filling
> > quarterly reports with the Commons PMC to be included in the board
report,
> > insuring that each sub-project has a strong enough community to keep
moving
> > forward (which implies shepherds/mentors to monitor those communities),
> > etc.  Do you really want to go that far?
> >
> > Not necessarily. My intention is to demonstrate, that some kind of
> > compromise *is possible*, and might even be beneficial for us all.
> >
> >
> > Jochen
> >
> > --
> > The next time you hear: "Don't reinvent the wheel!"
> >
> >
> >
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

Re: [all] Rethinking dev@

[Benedikt Ritter]

Hello,

we should stick to having one mailing list. If a component becomes so
specialized that the PMC fails to follow what is going on (like what
happend with CM), it is time to move that component out of commons. Having
separat mailing lists will only make things worse, IMHO.

Benedikt

Jochen Wiedmann  schrieb am Fr., 24. Juni 2016
um 16:58 Uhr:

> On Fri, Jun 24, 2016 at 3:58 PM, Ralph Goers 
> wrote:
>
> > Well, it sort of works for the incubator. They are constantly having
> discussions about how to do it better. And yes, it could work for us if all
> the subprojects have to follow the incubator rules, such as filling
> quarterly reports with the Commons PMC to be included in the board report,
> insuring that each sub-project has a strong enough community to keep moving
> forward (which implies shepherds/mentors to monitor those communities),
> etc.  Do you really want to go that far?
>
> Not necessarily. My intention is to demonstrate, that some kind of
> compromise *is possible*, and might even be beneficial for us all.
>
>
> Jochen
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Is JIRA down?

[Raviteja Lokineni]

I am getting a HTTP 500 when trying to access issues.apache.org

-- 
*Raviteja Lokineni* | Business Intelligence Developer
TD Ameritrade

E: raviteja.lokin...@gmail.com

[image: View Raviteja Lokineni's profile on LinkedIn]

Re: [all] Rethinking dev@

[Jochen Wiedmann]

On Fri, Jun 24, 2016 at 3:58 PM, Ralph Goers  wrote:

> Well, it sort of works for the incubator. They are constantly having 
> discussions about how to do it better. And yes, it could work for us if all 
> the subprojects have to follow the incubator rules, such as filling quarterly 
> reports with the Commons PMC to be included in the board report, insuring 
> that each sub-project has a strong enough community to keep moving forward 
> (which implies shepherds/mentors to monitor those communities), etc.  Do you 
> really want to go that far?

Not necessarily. My intention is to demonstrate, that some kind of
compromise *is possible*, and might even be beneficial for us all.


Jochen

-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: svn commit: r1750073 - in /commons/proper/bcel/trunk: RELEASE-NOTES.txt src/changes/changes.xml

[Jörg Schaible]

sebb wrote:

> I'm not sure why the svnmailer does not default to UTF-8, but it
> clearly doesn't.

??? It seems it does:

 %< ===
Content-Type: text/plain; charset=UTF-8
 %< ===

and when I look at

 %< ===
>>> >  to return an object. Thanks to Jérôme Leroux.
>>> > -o BCEL-184: The verifier now checks if methods with a void return
>>> > type
>>> attempt
>>> > -to return an object. Thanks to Jérôme Leroux.
>>> >  o BCEL-207: MethodGen.removeLocalVariable now properly unreference
>>> >  the
>>> removed
 %< ===

all characters are displayed fine, escpially Jérôme's name.

Cheers,
Jörg


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

Re: [all] Rethinking dev@

[Gary Gregory]

On Jun 24, 2016 7:41 AM, "Gary Gregory"  wrote:
>
>
> On Jun 24, 2016 4:19 AM, "sebb"  wrote:
> >
> > On 24 June 2016 at 12:02, Jochen Wiedmann 
wrote:
> > > On Fri, Jun 24, 2016 at 12:22 PM, Emmanuel Bourg 
wrote:
> > >
> > >> I'm -1, because indeed "It didn't work for Jakarta". You can't really
> > >> compare Commons to the Incubator, because the ultimate goal of an
> > >> incubated project is to become a TLP with its own community, so a
> > >> dedicated mailing list makes sense. Splitting the Commons mailing
list
> > >> will just split the community and harm the cross pollination between
> > >> projects.
> > >
> > > Commons has bred TLP's in the past, and should not hesitate to do so
> > > in the future.
> >
> > +1 to spawning TLPs as needed (e.g. HttpClient)
> >
> > However -1 to establishing component@ lists.
> >
> > > Jochen
>
> I'm with Jochen.

I mean I agree with:

> > +1 to spawning TLPs as needed (e.g. HttpClient)
> >
> > However -1 to establishing component@ lists.

Gary

> Gary
>
> > >
> > >
> > > --
> > > The next time you hear: "Don't reinvent the wheel!"
> > >
> > >
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> > >
> > > -
> > > 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] Rethinking dev@

[Gary Gregory]

On Jun 24, 2016 4:19 AM, "sebb"  wrote:
>
> On 24 June 2016 at 12:02, Jochen Wiedmann 
wrote:
> > On Fri, Jun 24, 2016 at 12:22 PM, Emmanuel Bourg 
wrote:
> >
> >> I'm -1, because indeed "It didn't work for Jakarta". You can't really
> >> compare Commons to the Incubator, because the ultimate goal of an
> >> incubated project is to become a TLP with its own community, so a
> >> dedicated mailing list makes sense. Splitting the Commons mailing list
> >> will just split the community and harm the cross pollination between
> >> projects.
> >
> > Commons has bred TLP's in the past, and should not hesitate to do so
> > in the future.
>
> +1 to spawning TLPs as needed (e.g. HttpClient)
>
> However -1 to establishing component@ lists.
>
> > Jochen

I'm with Jochen.

Gary
> >
> >
> > --
> > The next time you hear: "Don't reinvent the wheel!"
> >
> >
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >
> > -
> > 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] Rethinking dev@

[Ralph Goers]

> On Jun 24, 2016, at 2:35 AM, Jochen Wiedmann  
> wrote:
> 
> Hi,
> 
> given the last weeks, I'd like us to rethink how we work together.
> Right now, there is basically only a single place for discussions, and
> decisions, which is dev@commons. Okay, we are a common ASF project (no
> pun intended), and we need a place to meet, but aren't we
> overempasizing things a bit?
> 
> Honestly, I don't care about how many, and what branches [math]
> maintains, and how the source tree is organized. I'd clearly like the
> [math] developers to organize those things for themselves. And, I'd
> like them to decide on their own, what, and how many deliverables they
> create. (Doesn't matter, how many people are "them".)
> 
> In other words: I wonder (once again), that we should be able to grant
> components a bigger degree of autonomy. For example: Why shouldn't
> [math], or [crypto], have an additional mailing list. Can you imagine,
> how much noise this would have  removed from dev@ over the last weeks?
> 
> Okay, I can see that our old odel is working for [io], [fileupload],
> or [compress]. But I am not convinced, that this shoe is fitting for
> all.
> 
> And, don't bother telling me about "It didn't work for Jakarta",
> because it does work: The Incubator has general@ as a meeting place,
> and a place for decisions, but the components can still work on their
> own. We really need a distinction between topics that are for anyone
> and others, that are not. Just using "[all]", or something else in the
> subject doesn't scale.
> 

Well, it sort of works for the incubator. They are constantly having 
discussions about how to do it better. And yes, it could work for us if all the 
subprojects have to follow the incubator rules, such as filling quarterly 
reports with the Commons PMC to be included in the board report, insuring that 
each sub-project has a strong enough community to keep moving forward (which 
implies shepherds/mentors to monitor those communities), etc.  Do you really 
want to go that far?

Ralph



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

Re: [compress] Update to Java 7?

[Stian Soiland-Reyes]

I don't think we should need that strong arguments to go to Java 7.
Remember being "stuck in the past" with older syntax also puts off
potential new contributors and eventually causes code rot. E.g.
Commons Compress is very InputStream-centric, and so a
try-with-resources could be quite good to simplify the code - arguably
mainly the tests.

Being able to upgrade ZipFile to support SeekableByteChannel and
java.nio.file.Path sounds like a good motivation to me.


We should still be more careful about upgrading to Java 8, but I think
Java 7 should be the expected minimum.

On 24 June 2016 at 14:14, Stefan Bodewig  wrote:
> On 2016-06-24, Gary Gregory wrote:
>
>> Hi,
>
>> I was looking at some compress code that I wanted to update to
>> switch-on-string but realized the code is still on Java 6.
>
> "still" means 1.12 has been the first release to require Java 6 - 1.11
> was at Java 5 :-)
>
>> OK to bump to Java 7?
>
> If it is useful for us, yes.
>
> try-with-resources is nice but wouldn't convince me. SeekableByteChannel
> to make ZipFile and SevenZFile usable for non-Files would.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

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

Re: svn commit: r1750073 - in /commons/proper/bcel/trunk: RELEASE-NOTES.txt src/changes/changes.xml

[sebb]

I'm not sure why the svnmailer does not default to UTF-8, but it
clearly doesn't.

On 24 June 2016 at 13:10, Benedikt Ritter  wrote:
> Nice, thank you!
>
> sebb AT ASF  schrieb am Fr., 24. Juni 2016 um 12:46 Uhr:
>
>> Looks like the fix for the encoding was successful.
>>
>> [I was looking for somewhere to apply a dummy change to test the UTF8
>> fix when I found the duplicate ...]
>>
>> On 24 June 2016 at 11:42,   wrote:
>> > Author: sebb
>> > Date: Fri Jun 24 10:42:46 2016
>> > New Revision: 1750073
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1750073&view=rev
>> > Log:
>> > Drop duplicate entry for BCEL-184
>> >
>> > Modified:
>> > commons/proper/bcel/trunk/RELEASE-NOTES.txt
>> > commons/proper/bcel/trunk/src/changes/changes.xml
>> >
>> > Modified: commons/proper/bcel/trunk/RELEASE-NOTES.txt
>> > URL:
>> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/RELEASE-NOTES.txt?rev=1750073&r1=1750072&r2=1750073&view=diff
>> >
>> ==
>> > --- commons/proper/bcel/trunk/RELEASE-NOTES.txt [utf-8] (original)
>> > +++ commons/proper/bcel/trunk/RELEASE-NOTES.txt [utf-8] Fri Jun 24
>> 10:42:46 2016
>> > @@ -97,8 +97,6 @@ o BCEL-187: Verification error when an i
>> >  o BCEL-218: Remove ObjectType cache. Thanks to chas.
>> >  o BCEL-184: The verifier now checks if methods with a void return type
>> attempt
>> >  to return an object. Thanks to Jérôme Leroux.
>> > -o BCEL-184: The verifier now checks if methods with a void return type
>> attempt
>> > -to return an object. Thanks to Jérôme Leroux.
>> >  o BCEL-207: MethodGen.removeLocalVariable now properly unreference the
>> removed
>> >  variable from the targetters of the instruction handlers
>> delimiting
>> >  the scope of the variable. Thanks to Mark Roberts.
>> >
>> > Modified: commons/proper/bcel/trunk/src/changes/changes.xml
>> > URL:
>> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/changes/changes.xml?rev=1750073&r1=1750072&r2=1750073&view=diff
>> >
>> ==
>> > --- commons/proper/bcel/trunk/src/changes/changes.xml [utf-8] (original)
>> > +++ commons/proper/bcel/trunk/src/changes/changes.xml [utf-8] Fri Jun 24
>> 10:42:46 2016
>> > @@ -167,10 +167,6 @@ For full information about API changes p
>> >  The verifier now checks if methods with a void return type
>> attempt
>> >  to return an object.
>> >
>> > -  
>> > -The verifier now checks if methods with a void return type
>> attempt
>> > -to return an object.
>> > -  
>> >
>> >  MethodGen.removeLocalVariable now properly unreference the
>> removed
>> >  variable from the targetters of the instruction handlers
>> delimiting
>> >
>> >
>>
>> -
>> 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: [compress] Update to Java 7?

[sebb]

On 24 June 2016 at 14:14, Stefan Bodewig  wrote:
> On 2016-06-24, Gary Gregory wrote:
>
>> Hi,
>
>> I was looking at some compress code that I wanted to update to
>> switch-on-string but realized the code is still on Java 6.
>
> "still" means 1.12 has been the first release to require Java 6 - 1.11
> was at Java 5 :-)
>
>> OK to bump to Java 7?
>
> If it is useful for us, yes.
>
> try-with-resources is nice but wouldn't convince me. SeekableByteChannel
> to make ZipFile and SevenZFile usable for non-Files would.

+1

> Stefan
>
> -
> 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: [compress] Update to Java 7?

[Stefan Bodewig]

On 2016-06-24, Gary Gregory wrote:

> Hi,

> I was looking at some compress code that I wanted to update to
> switch-on-string but realized the code is still on Java 6.

"still" means 1.12 has been the first release to require Java 6 - 1.11
was at Java 5 :-)

> OK to bump to Java 7?

If it is useful for us, yes.

try-with-resources is nice but wouldn't convince me. SeekableByteChannel
to make ZipFile and SevenZFile usable for non-Files would.

Stefan

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

Re: [compress] Update to Java 7?

[Emmanuel Bourg]

Le 24/06/2016 à 05:31, Gary Gregory a écrit :

> OK to bump to Java 7?

I'd rather bump to Java 7 if you intend to leverage the Java 7 APIs, and
no just benefiting from the minor syntax changes.

Emmanuel Bourg


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

Re: [compress] Update to Java 7?

[Stian Soiland-Reyes]

+1!

On 24 June 2016 at 04:31, Gary Gregory  wrote:
> Hi,
>
> I was looking at some compress code that I wanted to update to
> switch-on-string but realized the code is still on Java 6.
>
> OK to bump to Java 7?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

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

Re: svn commit: r1750073 - in /commons/proper/bcel/trunk: RELEASE-NOTES.txt src/changes/changes.xml

[Benedikt Ritter]

Nice, thank you!

sebb AT ASF  schrieb am Fr., 24. Juni 2016 um 12:46 Uhr:

> Looks like the fix for the encoding was successful.
>
> [I was looking for somewhere to apply a dummy change to test the UTF8
> fix when I found the duplicate ...]
>
> On 24 June 2016 at 11:42,   wrote:
> > Author: sebb
> > Date: Fri Jun 24 10:42:46 2016
> > New Revision: 1750073
> >
> > URL: http://svn.apache.org/viewvc?rev=1750073&view=rev
> > Log:
> > Drop duplicate entry for BCEL-184
> >
> > Modified:
> > commons/proper/bcel/trunk/RELEASE-NOTES.txt
> > commons/proper/bcel/trunk/src/changes/changes.xml
> >
> > Modified: commons/proper/bcel/trunk/RELEASE-NOTES.txt
> > URL:
> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/RELEASE-NOTES.txt?rev=1750073&r1=1750072&r2=1750073&view=diff
> >
> ==
> > --- commons/proper/bcel/trunk/RELEASE-NOTES.txt [utf-8] (original)
> > +++ commons/proper/bcel/trunk/RELEASE-NOTES.txt [utf-8] Fri Jun 24
> 10:42:46 2016
> > @@ -97,8 +97,6 @@ o BCEL-187: Verification error when an i
> >  o BCEL-218: Remove ObjectType cache. Thanks to chas.
> >  o BCEL-184: The verifier now checks if methods with a void return type
> attempt
> >  to return an object. Thanks to Jérôme Leroux.
> > -o BCEL-184: The verifier now checks if methods with a void return type
> attempt
> > -to return an object. Thanks to Jérôme Leroux.
> >  o BCEL-207: MethodGen.removeLocalVariable now properly unreference the
> removed
> >  variable from the targetters of the instruction handlers
> delimiting
> >  the scope of the variable. Thanks to Mark Roberts.
> >
> > Modified: commons/proper/bcel/trunk/src/changes/changes.xml
> > URL:
> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/changes/changes.xml?rev=1750073&r1=1750072&r2=1750073&view=diff
> >
> ==
> > --- commons/proper/bcel/trunk/src/changes/changes.xml [utf-8] (original)
> > +++ commons/proper/bcel/trunk/src/changes/changes.xml [utf-8] Fri Jun 24
> 10:42:46 2016
> > @@ -167,10 +167,6 @@ For full information about API changes p
> >  The verifier now checks if methods with a void return type
> attempt
> >  to return an object.
> >
> > -  
> > -The verifier now checks if methods with a void return type
> attempt
> > -to return an object.
> > -  
> >
> >  MethodGen.removeLocalVariable now properly unreference the
> removed
> >  variable from the targetters of the instruction handlers
> delimiting
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [all] Rethinking dev@

[sebb]

On 24 June 2016 at 12:02, Jochen Wiedmann  wrote:
> On Fri, Jun 24, 2016 at 12:22 PM, Emmanuel Bourg  wrote:
>
>> I'm -1, because indeed "It didn't work for Jakarta". You can't really
>> compare Commons to the Incubator, because the ultimate goal of an
>> incubated project is to become a TLP with its own community, so a
>> dedicated mailing list makes sense. Splitting the Commons mailing list
>> will just split the community and harm the cross pollination between
>> projects.
>
> Commons has bred TLP's in the past, and should not hesitate to do so
> in the future.

+1 to spawning TLPs as needed (e.g. HttpClient)

However -1 to establishing component@ lists.

> Jochen
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> 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] Rethinking dev@

[Jochen Wiedmann]

On Fri, Jun 24, 2016 at 12:22 PM, Emmanuel Bourg  wrote:

> I'm -1, because indeed "It didn't work for Jakarta". You can't really
> compare Commons to the Incubator, because the ultimate goal of an
> incubated project is to become a TLP with its own community, so a
> dedicated mailing list makes sense. Splitting the Commons mailing list
> will just split the community and harm the cross pollination between
> projects.

Commons has bred TLP's in the past, and should not hesitate to do so
in the future.

Jochen


-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [all] Rethinking dev@

[Jochen Wiedmann]

On Fri, Jun 24, 2016 at 12:11 PM, Bertrand Delacretaz
 wrote:

> Another issue is voting on releases which must be an act of the PMC as
> a whole, so if you split I would recommend that release votes still
> happen on this list.

There could be a rule, that release votes must happe on dev@, not
component@. This is, what the Incubator does.

Jochen

-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: svn commit: r1750073 - in /commons/proper/bcel/trunk: RELEASE-NOTES.txt src/changes/changes.xml

[sebb AT ASF]

Looks like the fix for the encoding was successful.

[I was looking for somewhere to apply a dummy change to test the UTF8
fix when I found the duplicate ...]

On 24 June 2016 at 11:42,   wrote:
> Author: sebb
> Date: Fri Jun 24 10:42:46 2016
> New Revision: 1750073
>
> URL: http://svn.apache.org/viewvc?rev=1750073&view=rev
> Log:
> Drop duplicate entry for BCEL-184
>
> Modified:
> commons/proper/bcel/trunk/RELEASE-NOTES.txt
> commons/proper/bcel/trunk/src/changes/changes.xml
>
> Modified: commons/proper/bcel/trunk/RELEASE-NOTES.txt
> URL: 
> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/RELEASE-NOTES.txt?rev=1750073&r1=1750072&r2=1750073&view=diff
> ==
> --- commons/proper/bcel/trunk/RELEASE-NOTES.txt [utf-8] (original)
> +++ commons/proper/bcel/trunk/RELEASE-NOTES.txt [utf-8] Fri Jun 24 10:42:46 
> 2016
> @@ -97,8 +97,6 @@ o BCEL-187: Verification error when an i
>  o BCEL-218: Remove ObjectType cache. Thanks to chas.
>  o BCEL-184: The verifier now checks if methods with a void return type 
> attempt
>  to return an object. Thanks to Jérôme Leroux.
> -o BCEL-184: The verifier now checks if methods with a void return type 
> attempt
> -to return an object. Thanks to Jérôme Leroux.
>  o BCEL-207: MethodGen.removeLocalVariable now properly unreference the 
> removed
>  variable from the targetters of the instruction handlers 
> delimiting
>  the scope of the variable. Thanks to Mark Roberts.
>
> Modified: commons/proper/bcel/trunk/src/changes/changes.xml
> URL: 
> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/changes/changes.xml?rev=1750073&r1=1750072&r2=1750073&view=diff
> ==
> --- commons/proper/bcel/trunk/src/changes/changes.xml [utf-8] (original)
> +++ commons/proper/bcel/trunk/src/changes/changes.xml [utf-8] Fri Jun 24 
> 10:42:46 2016
> @@ -167,10 +167,6 @@ For full information about API changes p
>  The verifier now checks if methods with a void return type attempt
>  to return an object.
>
> -  
> -The verifier now checks if methods with a void return type attempt
> -to return an object.
> -  
>
>  MethodGen.removeLocalVariable now properly unreference the removed
>  variable from the targetters of the instruction handlers delimiting
>
>

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

Re: svn commit: r1750027 - in /commons/proper/bcel/trunk: RELEASE-NOTES.txt pom.xml src/changes/changes.xml src/changes/release-notes.vm src/conf/clirr-ignored-diffs.xml

[sebb]

On 24 June 2016 at 07:57, Benedikt Ritter  wrote:
>  schrieb am Do., 23. Juni 2016 um 23:56 Uhr:
>
>> Author: sebb
>> Date: Thu Jun 23 21:56:18 2016
>> New Revision: 1750027
>>
>> URL: http://svn.apache.org/viewvc?rev=1750027&view=rev
>> Log:
>> Fix up changes.xml so it regenerates RELEASE-NOTES OK
>>
>> Modified:
>> commons/proper/bcel/trunk/RELEASE-NOTES.txt
>> commons/proper/bcel/trunk/pom.xml
>> commons/proper/bcel/trunk/src/changes/changes.xml
>> commons/proper/bcel/trunk/src/changes/release-notes.vm
>> commons/proper/bcel/trunk/src/conf/clirr-ignored-diffs.xml
>>
>> Modified: commons/proper/bcel/trunk/RELEASE-NOTES.txt
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/RELEASE-NOTES.txt?rev=1750027&r1=1750026&r2=1750027&view=diff
>>
>> ==
>> --- commons/proper/bcel/trunk/RELEASE-NOTES.txt (original)
>> +++ commons/proper/bcel/trunk/RELEASE-NOTES.txt Thu Jun 23 21:56:18 2016
>> @@ -5,7 +5,7 @@
>>
>>  INTRODUCTION:
>>
>> -The Apache Commons team is pleased to announce the release of
>> +The Apache Commons BCEL team is pleased to announce the release of
>>  Apache Commons BCEL 6.0!
>>
>>  The Byte Code Engineering Library (BCEL) is intended to give users a
>> convenient
>> @@ -24,31 +24,31 @@ COMPATIBILITY with 5.2
>>
>>  Binary compatible - not strictly compatible
>>  - The constant interface org.apache.bcel.Constants has been deprecated.
>> Classes
>> -  which implemented this interface in 5.2 now use the constants defined
>> in the
>> -  org.apache.bcel.Const class.
>> + which implemented this interface in 5.2 now use the constants defined in
>> the
>> + org.apache.bcel.Const class.
>>  - The constant interface org.apache.bcel.generic.InstructionConstants has
>> been
>> -  deprecated. Classes which implemented this interface in 5.2 now use the
>> -  constants defined in the org.apache.bcel.generic.InstructionConsts
>> class.
>> + deprecated. Classes which implemented this interface in 5.2 now use the
>> + constants defined in the org.apache.bcel.generic.InstructionConsts class.
>>  - Return type of method 'public java.lang.Object getElementAt(int)' in
>> -  org.apache.bcel.verifier.VerifierFactoryListModel has been changed to
>> -  java.lang.String.
>> + org.apache.bcel.verifier.VerifierFactoryListModel has been changed to
>> + java.lang.String.
>>  - The BCEL classes do no longer implement java.io.Serializable.
>>
>>  Source compatible - Yes, sort of;
>>   - The org.apache.bcel.classfile.Visitor interface has been enhanced with
>> -   additional methods. If you implemented it directly instead of extending
>> -   the EmptyVisitor class you'll have to implement the new methods.
>> + additional methods. If you implemented it directly instead of extending
>> + the EmptyVisitor class you'll have to implement the new methods.
>>
>>  Semantic compatible - Yes, except:
>>   - BCEL 6.0 handles new attributes such as code annotations that could
>> only
>> -   be processed by implementing a custom AttributeReader in the previous
>> -   versions. Code relying on this behavior will have to be adjusted since
>> -   the AttributeReader will no longer be called in these cases.
>> + be processed by implementing a custom AttributeReader in the previous
>> + versions. Code relying on this behavior will have to be adjusted since
>> + the AttributeReader will no longer be called in these cases.
>>
>>  For full information about API changes please see the extended Clirr
>> report:
>>
>> -http://commons.apache.org/bcel/bcel5-bcel6-clirr-report.html
>>
>> +http://commons.apache.org/bcel/clirr-report.html
>>
>>  NEW FEATURES:
>>  =
>> @@ -67,7 +67,7 @@ o BCEL-221: BCELifier is not working for
>>  o BCEL-195: Addition of hashCode() to generic/Instruction.java breaks
>> Targeters.
>>  Never make distinct BranchInstructions compare equal.
>>  o BCEL-261: Select constructor allows partially constructed instance to
>> escape.
>> -Re-ordered code to delay the escape..
>> +Re-ordered code to delay the escape.
>>  o BCEL-259: Minor doc error in BranchInstruction.java.
>>  o BCEL-260: ClassDumper example duplicates field attribute types.
>>  o BCEL-258: No tests to check the output of dump methods.
>> @@ -100,14 +100,11 @@ o BCEL-207: MethodGen.removeLocalVariabl
>>  variable from the targetters of the instruction handlers
>> delimiting
>>  the scope of the variable. Thanks to Mark Roberts.
>>  o BCEL-197: Utility.signatureToString() no longer throws a
>> ClassFormatException
>> -on TypeVariables found in generic signatures. Thanks to
>> -Mark Roberts.
>> -o BCEL-194: Removed the 'index' variable from the LocalVariableGen's hash
>> code.
>> -Thanks to Mark Roberts.
>> +on TypeVariables found in generic signatures. Thanks to Mark
>> Roberts.
>> +o BCEL-194: Removed the 'index' variable from the LocalVar

Re: [all] Rethinking dev@

[Emmanuel Bourg]

I'm -1, because indeed "It didn't work for Jakarta". You can't really
compare Commons to the Incubator, because the ultimate goal of an
incubated project is to become a TLP with its own community, so a
dedicated mailing list makes sense. Splitting the Commons mailing list
will just split the community and harm the cross pollination between
projects.

I expect the surge of activity around commons-crypto to calm down after
the first releases, so a dedicated mailing list doesn't make sense as it
will ultimately have a low traffic.

The case of commons-math is different. If we agree to promote it to TLP
once the community has recovered, then creating a dedicated list now is
sensible. This would be equivalent to incubating the Math TLP within
Commons as I suggested.

Emmanuel Bourg


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

Re: [CRYPTO]1.0.0 Release Plan

[sebb]

On 24 June 2016 at 10:08, Sun, Dapeng  wrote:
> Hi all,
>
> Thank all for helping review CRYPTO from different angles.
>
> According the number of jira remaining issues, I prefer to start the thread 
> for rolling a RC at June 29th(Next Wednesday). Please feel free to let me 
> know if you have any concern about it.

Yes, I do have some concerns.

I think the public API needs to be better documented.
There are still a lot of public classes that AFAICT don't really
belong in the API.
For example
JceCipher
OpensslCipher
JavaCryptoRandom
OpensslCryptoRandom
OsCryptoRandom
These need to be made private/package protected or moved into an
internal package, or at the very least clearly documented as internal.

Also the way that classes are instantiated is very awkward, as
properties are not as easy to use as plain variables - String/boolean
etc - and properties don't offer any type validation.
Since properties are used in the constructors, it's not enough for 3rd
parties to just implement the CryptoRandom interface - they also have
to provide a constructor which takes a Properties instance.

Indeed I wonder why there is a CryptoRandom interface - would it not
be better for JavaCryptoRandom to extend java.util.Random? The other
implementations of CryptoRandom do.
Or maybe none of them should extend j.u.Random?

> Regards
> Dapeng
>
> -Original Message-
> From: Sun, Dapeng [mailto:dapeng@intel.com]
> Sent: Monday, June 06, 2016 5:14 PM
> To: Commons Developers List
> Subject: [CRYPTO]1.0.0 Release Plan
>
> Hello,
>
> Apache Commons CRYPTO was established at May 9, 2016[1], There are presently 
> numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the 
> legal issue[3].
>
> With the first release, we can begin to promote CRYPTO to other Apache 
> components, like Apache Hadoop, Apache Spark, so that they can benefit the 
> higher performance improvement from Apache Commons Crypto.
>
> We plan the following three opening features to next release(I think it 
> should be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark 
> tool[6]. Please let me know if there is anything need to be done before the 
> release.
>
>
> Regards
> Dapeng
>
>
> [1] 
> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E
> [2] 
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
> [3] 
> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E
> [4] https://github.com/apache/commons-crypto/pull/44
> [5] https://github.com/apache/commons-crypto/pull/47
> [6] https://github.com/apache/commons-crypto/pull/1
>
>
> -
> 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] Rethinking dev@

[Bertrand Delacretaz]

On Fri, Jun 24, 2016 at 12:11 PM, Stian Soiland-Reyes  wrote:
> ...there's the danger
> of developing the "Crypto PMC", "Math PMC" etc - effectively making an
> Apache within Apache

RED LIGHT ALARMS ALL OVER MY BOARD MEMBER BRAIN NOW

Just sayin' ;-)

-Bertrand

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

Re: [all] Rethinking dev@

[Stian Soiland-Reyes]

Agreed, I think multiple lists would be great for everyone else who is
not on the Commons PMC; in fact that was a major reason why Commons
RDF went to the Incubator first, to have its own mailing lists in the
constructive phase.

However it could be very fragmenting for the PMC as there's the danger
of developing the "Crypto PMC", "Math PMC" etc - effectively making an
Apache within Apache. We should not forget the Jakarta learning
either. Perhaps if all PMC members agree to stay on all of the
sub-lists, and all release votes are done on dev@commons, then it
could work well.





On 24 June 2016 at 11:00, Benson Margulies  wrote:
> The 'problem of Jakarta' was a problem of supervision. The board could
> not trust that anyone was minding the entire store. Multiple mailing
> lists could be seen as an indication that commons is large and diverse
> enough to risk suffering from the same problem. Some would think that
> this desire to give it its own mailing list is a strong indication
> that it should be its own TLP. That being said, launching a mailing
> list just for the purpose of hashing out the future of Math might be a
> compromise.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

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

Re: [all] Rethinking dev@

[Bertrand Delacretaz]

On Fri, Jun 24, 2016 at 11:35 AM, Jochen Wiedmann  >

> ...Why shouldn't [math], or [crypto], have an additional mailing list...

The general rule of mailing lists is that they should be split by
audience, not by topic.

If the math audience for example is really distinct from the rest then
why not - but note that people can achieve the same thing by filtering
on the [math] subject line tag if used consistently.

Another issue is voting on releases which must be an act of the PMC as
a whole, so if you split I would recommend that release votes still
happen on this list.

-Bertrand

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

Re: [all] Rethinking dev@

[Benson Margulies]

The 'problem of Jakarta' was a problem of supervision. The board could
not trust that anyone was minding the entire store. Multiple mailing
lists could be seen as an indication that commons is large and diverse
enough to risk suffering from the same problem. Some would think that
this desire to give it its own mailing list is a strong indication
that it should be its own TLP. That being said, launching a mailing
list just for the purpose of hashing out the future of Math might be a
compromise.

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

Aw: [all] Rethinking dev@

[Andrey Loskutov]

+1000.
I joined the commons list only because I wanted to listen to BCEL project.

Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov


> Gesendet: Freitag, 24. Juni 2016 um 11:35 Uhr
> Von: "Jochen Wiedmann" 
> An: "Apache Commons Developers List" 
> Betreff: [all] Rethinking dev@
>
> Hi,
> 
> given the last weeks, I'd like us to rethink how we work together.
> Right now, there is basically only a single place for discussions, and
> decisions, which is dev@commons. Okay, we are a common ASF project (no
> pun intended), and we need a place to meet, but aren't we
> overempasizing things a bit?
> 
> Honestly, I don't care about how many, and what branches [math]
> maintains, and how the source tree is organized. I'd clearly like the
> [math] developers to organize those things for themselves. And, I'd
> like them to decide on their own, what, and how many deliverables they
> create. (Doesn't matter, how many people are "them".)
> 
> In other words: I wonder (once again), that we should be able to grant
> components a bigger degree of autonomy. For example: Why shouldn't
> [math], or [crypto], have an additional mailing list. Can you imagine,
> how much noise this would have  removed from dev@ over the last weeks?
> 
> Okay, I can see that our old odel is working for [io], [fileupload],
> or [compress]. But I am not convinced, that this shoe is fitting for
> all.
> 
> And, don't bother telling me about "It didn't work for Jakarta",
> because it does work: The Incubator has general@ as a meeting place,
> and a place for decisions, but the components can still work on their
> own. We really need a distinction between topics that are for anyone
> and others, that are not. Just using "[all]", or something else in the
> subject doesn't scale.
> 
> Jochen
> 
> -- 
> The next time you hear: "Don't reinvent the wheel!"
> 
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> 
> -
> 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

[all] Rethinking dev@

[Jochen Wiedmann]

Hi,

given the last weeks, I'd like us to rethink how we work together.
Right now, there is basically only a single place for discussions, and
decisions, which is dev@commons. Okay, we are a common ASF project (no
pun intended), and we need a place to meet, but aren't we
overempasizing things a bit?

Honestly, I don't care about how many, and what branches [math]
maintains, and how the source tree is organized. I'd clearly like the
[math] developers to organize those things for themselves. And, I'd
like them to decide on their own, what, and how many deliverables they
create. (Doesn't matter, how many people are "them".)

In other words: I wonder (once again), that we should be able to grant
components a bigger degree of autonomy. For example: Why shouldn't
[math], or [crypto], have an additional mailing list. Can you imagine,
how much noise this would have  removed from dev@ over the last weeks?

Okay, I can see that our old odel is working for [io], [fileupload],
or [compress]. But I am not convinced, that this shoe is fitting for
all.

And, don't bother telling me about "It didn't work for Jakarta",
because it does work: The Incubator has general@ as a meeting place,
and a place for decisions, but the components can still work on their
own. We really need a distinction between topics that are for anyone
and others, that are not. Just using "[all]", or something else in the
subject doesn't scale.

Jochen

-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Hi all,

Thank all for helping review CRYPTO from different angles.

According the number of jira remaining issues, I prefer to start the thread for 
rolling a RC at June 29th(Next Wednesday). Please feel free to let me know if 
you have any concern about it.

Regards
Dapeng

-Original Message-
From: Sun, Dapeng [mailto:dapeng@intel.com] 
Sent: Monday, June 06, 2016 5:14 PM
To: Commons Developers List
Subject: [CRYPTO]1.0.0 Release Plan

Hello,

Apache Commons CRYPTO was established at May 9, 2016[1], There are presently 
numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the legal 
issue[3].

With the first release, we can begin to promote CRYPTO to other Apache 
components, like Apache Hadoop, Apache Spark, so that they can benefit the 
higher performance improvement from Apache Commons Crypto.

We plan the following three opening features to next release(I think it should 
be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark tool[6]. 
Please let me know if there is anything need to be done before the release.


Regards
Dapeng


[1] 
http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E
[2] 
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
[3] 
http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E
[4] https://github.com/apache/commons-crypto/pull/44
[5] https://github.com/apache/commons-crypto/pull/47
[6] https://github.com/apache/commons-crypto/pull/1


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