On Wed, Aug 10, 2011 at 6:06 AM, Ceki Gülcü wrote:
> On 10/08/2011 8:02 AM, Henri Yandell wrote:
>
>
>
> Thank you for posting this summary of the Apache way. Yes, it is damn
> hard to track contributions, especially if one wishes to do it
> accurately and fairly. However, it is possible and even
>
> Sounds reasonable to me; though I would personally be fine with
> adding some small classes along the lines of what I outlined above
> to support events. They could even be package-scoped if we want to
> keep them out of the public API and replace later with more general
> constructs used else
The Apache Commons team is pleased to announce the release of Commons
Lang 3.0.1.
As the version suggests, this is a drop-in replacement for 3.0. A list
of the 9 changes and 6 bug fixes in this release are found in the
release notes:
https://commons.apache.org/lang/changes-report.html#a3.0.1
F
On 8/10/11 8:19 PM, Sébastien Brisard wrote:
> Hello,
> going back to the initial conversation. It seems to me that
> formalizing Iterative Algorithms in a general way is very interesting,
> but not a realistic target for 3.0 (or probably even 3.1). However, I
> would very much like to have a satis
Hello,
this is an idea I've had while thinking about Iterative Linear
Solvers, but I think it is much more general. I don't know whether
what I'm going to describe is a known pattern, or a very dirty trick I
should forget about. So any advice would be greatly appreciated.
For the sake of the argum
Hello,
going back to the initial conversation. It seems to me that
formalizing Iterative Algorithms in a general way is very interesting,
but not a realistic target for 3.0 (or probably even 3.1). However, I
would very much like to have a satisfactory working version of linear
iterative solvers. I'
On 8/10/11 3:51 PM, Greg Sterijevski wrote:
> Hello All,
>
> In the SVD class I notice:
>
> FastMath.max(m, n)
>
> all over the place. Since these values are known when the constructor is
> called and are final, would anyone object to making the result a private
> instance variable?
+1
(note chan
On 2011-08-11, Mark Struberg wrote:
> Of course they had the most commits over at the codehaus SVN. But they
> did not say that 70% of the code did originally come from Apache
> Avalon (only found that out after reading Stefan Bodewigs @author tags
> and digged deeper).
Really? I never contribut
Commits != work
I'm currently in the progress of rewriting plexus-utils and other stuff from
over at codehaus to be able to use an IP clean version of it for Maven again.
This is needed since some folks are throwing dirt and claiming that they did
most of the work, yada yada yada...
Of course
Hello All,
In the SVD class I notice:
FastMath.max(m, n)
all over the place. Since these values are known when the constructor is
called and are final, would anyone object to making the result a private
instance variable?
-Greg
On 10 August 2011 21:08, Thomas Vandahl wrote:
> Hi folks,
>
> I finally managed to move the site generation to Maven2. The new site
> derives the commons layout. Please check if something is missing.
All looks good.
Only missing item is a logo for the component.
---
Luc,
I think we misunderstood each other, in the snippet below, my intention was
to agree with him. Everything Gilles was agreeable and hard to argue
against.
-Greg
>
> Luc
>
>
> Not sure what you mean.
>>
>>
>> In my opinion, discussions should serve to solve real problems of a
>>> software
>
This is very much what I had in mind. The downside is that the committer is
saddled with a recurring task. -Greg
On Wed, Aug 10, 2011 at 1:39 PM, Ted Dunning wrote:
> I have been able to manage some long-lived branches in Zookeeper and Mahout
> using git.
>
> The key was to rebase the branch fre
I would recommend staying with the standard name. Why invent yet another
term for a well-known concept:
http://en.wikipedia.org/wiki/Memoization
On Wed, Aug 10, 2011 at 12:38 PM, Oliver Heger wrote:
> And I would recommend another name. At least for me as non-native speaker
> it is hard to ima
Hi Thomas,
just had a quick look (I'm from the EU mirror) and everything looks good to me!
Have a nice day, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Aug 10, 2011 at 10:08 PM, Thomas Vandahl wrote:
> Hi folks,
>
> I finally managed to move the s
On Wed, Aug 10, 2011 at 3:38 PM, Oliver Heger
wrote:
> Am 10.08.2011 01:23, schrieb Gary Gregory:
>>
>> On Tue, Aug 9, 2011 at 6:40 PM, Simone Tripodi
>> wrote:
>>>
>>> Good news! :)
>>
>> Well... I am having second thoughts now baed on Tim's reply:
>>
>> On Tue, Aug 9, 2011 at 6:13 PM, Tim Peier
Hi folks,
I finally managed to move the site generation to Maven2. The new site
derives the commons layout. Please check if something is missing.
Bye, Thomas.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For addi
Am 10.08.2011 01:23, schrieb Gary Gregory:
On Tue, Aug 9, 2011 at 6:40 PM, Simone Tripodi wrote:
Good news! :)
Well... I am having second thoughts now baed on Tim's reply:
On Tue, Aug 9, 2011 at 6:13 PM, Tim Peierls wrote:
Probably not a good idea to use Memoizer unchanged from the book, t
+1 for me as well,
sounds BSF perfectly fits Apache Commons community :)
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Aug 10, 2011 at 8:18 PM, Jörg Schaible wrote:
> sebb wrote:
>
>> BSF [1] needs to move out of Jakarta.
>>
>> It's not really big e
I have been able to manage some long-lived branches in Zookeeper and Mahout
using git.
The key was to rebase the branch frequently. That allowed me to spread the
complexity of the ultimate merge out into a lot of small decisions, each of
which was pretty simple and could be tracked back to a smal
Le 10/08/2011 16:30, Greg Sterijevski a écrit :
Gilles,
I think we do agree on most points:
For very-limited functionality, this could be an option. The big drawback
is that, if it takes time to implement, the merge with the "official"
branch
may not be trivial. [IIUC, Ted suggested that "git"
sebb wrote:
> BSF [1] needs to move out of Jakarta.
>
> It's not really big enough to warrant its own TLP.
>
> It looks like it would be a suitable addition to Commons.
>
> Any objections, or should I start a vote?
>
> [1] http://jakarta.apache.org/bsf/
+1
-
OK by me.
Gary
On Wed, Aug 10, 2011 at 10:51 AM, sebb wrote:
> BSF [1] needs to move out of Jakarta.
>
> It's not really big enough to warrant its own TLP.
>
> It looks like it would be a suitable addition to Commons.
>
> Any objections, or should I start a vote?
>
> [1] http://jakarta.apache.or
On 8/10/11 12:48 AM, Jörg Schaible wrote:
> Phil Steitz wrote:
>
>> On 8/9/11 4:05 PM, Phil Steitz wrote:
>>> Thanks for the nudge. I'll bite. Of course anyone is welcome to
>>> browse the open JIRA issues with 3.0 as fix version and add comments
>>> :)
>> I started slugging through JIRA. Made i
Hi.
> I think we do agree on most points:
>
> For very-limited functionality, this could be an option. The big drawback
> > is that, if it takes time to implement, the merge with the "official"
> > branch
> > may not be trivial. [IIUC, Ted suggested that "git" was superior to "svn"
> > in making
On 10/08/2011 3:59 PM, Gary Gregory wrote:
"Creating a branch of commons-digester using SLF4J/jul/log4jv2 will
not convince anyone."
I am sorry, but deciding for other people what they are going to think
is no way to go either.
Experimenting by branching is leading by example. This is a good
o
On 10/08/2011 3:47 PM, Christian Grobmeier wrote:
So, why do you want to measure my coding efficiency? Not even my Boss
(if I would have one) is allowed to do that! Commit points measure my
coding skills probably, not my human skills.
Commit points as described in my blog measure the number of
BSF [1] needs to move out of Jakarta.
It's not really big enough to warrant its own TLP.
It looks like it would be a suitable addition to Commons.
Any objections, or should I start a vote?
[1] http://jakarta.apache.org/bsf/
-
Gilles,
I think we do agree on most points:
For very-limited functionality, this could be an option. The big drawback
> is that, if it takes time to implement, the merge with the "official"
> branch
> may not be trivial. [IIUC, Ted suggested that "git" was superior to "svn"
> in making this less
On Wed, Aug 10, 2011 at 9:06 AM, Ceki Gülcü wrote:
> On 10/08/2011 8:02 AM, Henri Yandell wrote:
>>
>> On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu wrote:
>>
>>> * On the ASF model
>>>
>>> In a nutshell, while the ASF is a great organization in many ways, it
>>> is not a meritocracy mainly because
> Thank you for posting this summary of the Apache way. Yes, it is damn
> hard to track contributions, especially if one wishes to do it
> accurately and fairly. However, it is possible and even easy to keep
> *approximate* track of contributions, e.g. via "commit points" as
> described in my commi
On 10/08/2011 8:02 AM, Henri Yandell wrote:
On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu wrote:
* On the ASF model
In a nutshell, while the ASF is a great organization in many ways, it
is not a meritocracy mainly because merit is not measured at all and
at the project level no responsiblity is
Hello.
> I think you hit the nail on the head with the comment:
>
> "... but also the time to
> experiment. Only the latter will be able to tell if the design is good.
> And this must take time so that all the potential pitfalls can be ..."
>
> Maybe this is chumming the water with more flotsam
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
+1 as well. That's the path I advocated for Configuration 2.0, combined
with the log4j bridge from Paul Smith [1]
Maybe we should stop spending our energy on alternative logging
frameworks and try to improve the standard one in the JDK instead. I
have been told that Java was open source now, s
On 2011-08-10, Henri Yandell wrote:
> On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu wrote:
>> * On the ASF model
>> In a nutshell, while the ASF is a great organization in many ways, it
>> is not a meritocracy mainly because merit is not measured at all and
>> at the project level no responsiblit
Phil Steitz wrote:
> On 8/9/11 4:05 PM, Phil Steitz wrote:
>> Thanks for the nudge. I'll bite. Of course anyone is welcome to
>> browse the open JIRA issues with 3.0 as fix version and add comments
>> :)
>
> I started slugging through JIRA. Made it all the way through the
> unclassified list a
On 8/9/11 4:05 PM, Phil Steitz wrote:
> Thanks for the nudge. I'll bite. Of course anyone is welcome to
> browse the open JIRA issues with 3.0 as fix version and add comments
> :)
I started slugging through JIRA. Made it all the way through the
unclassified list and will finish the first pass t
38 matches
Mail list logo
