commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [functor] API, etc., review WAS Re: [VOTE][RESULT] Release Apache Commons Functor 1.0 based on RC1
Date Sat, 21 Jan 2012 10:10:51 GMT
Hi Matt!!! :)

great follow up, thanks for taking care of it!

If someone already knows how the functor design has to be modified to
improve it, I can do the log-work and have it released ASAP.

Many thanks in advance, all the best!!!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Sat, Jan 21, 2012 at 4:28 AM, Matt Benson <gudnabrsam@gmail.com> wrote:
> All who took interest in this discussion three months ago (and still
> have any cycles to spare):  Please add your thoughts to the discussion
> at http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc.
>
> Thanks!
> Matt
>
> On Sun, Oct 23, 2011 at 10:42 AM, Simone Tripodi
> <simonetripodi@apache.org> wrote:
>> Hi Adrian,
>> Of course, we still need a lot of work before next RC, your
>> contribution would be more then welcomed!
>> Hope to hear from you soon, have a nice day!
>> All the best!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Sun, Oct 23, 2011 at 5:26 PM, Adrian Cumiskey
>> <adrian.cumiskey@gmail.com> wrote:
>>> When I take a look at JIRA, Functor currently has only two open issues, one
>>> minor and one trivial.  It would be good to capture all the outstanding work
>>> items that people feel are preventing a new RC.  I would also be happy to
>>> contribute to improving Functor.
>>>
>>> Cheers, Adrian.
>>>
>>> On 23 October 2011 06:46, Simone Tripodi <simonetripodi@apache.org> wrote:
>>>
>>>> Hi all guys,
>>>> Since 72 hours passed I'm declaring this vote as closed and NOT passed
>>>> with only 2 positive votes from PMCs:
>>>>
>>>>  * Matt Benson
>>>>  * Simone Tripodi (implicit)
>>>>
>>>> no other votes were cast.
>>>>
>>>> We will continue working towards a new RC to submit.
>>>>
>>>> Thanks to all for your support and patience!
>>>> Have a nice weekend, all the best!
>>>> Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Fri, Oct 21, 2011 at 6:36 PM, sebb <sebbaz@gmail.com> wrote:
>>>> > On 21 October 2011 16:04, Matt Benson <gudnabrsam@gmail.com> wrote:
>>>> >> On Fri, Oct 21, 2011 at 5:27 AM, sebb <sebbaz@gmail.com> wrote:
>>>> >>> On 21 October 2011 11:03, Emmanuel Bourg <ebourg@apache.org>
wrote:
>>>> >>>> Le 21/10/2011 11:10, Simone Tripodi a écrit :
>>>> >>>>
>>>> >>>>> So, as you proposed, would be reasonable to drop the
1.0 and decide
>>>> >>>>> upon for a 0.1 as current release?
>>>> >>>>
>>>> >>>> Yes, or a 1.0-beta with clear indications that this is a
preview
>>>> intended to
>>>> >>>> gather user feedback.
>>>> >>>
>>>> >>> I don't think it's ready for beta status yet.
>>>> >>>
>>>> >>> But - is there any pressing need to make a release?
>>>> >>
>>>> >> The most immediate thing is that [proxy] 2 needs a unary predicate.
>>>> >> It becomes ridiculous for every component we have to define such
a
>>>> >> basic interface in a different way.  So [proxy] 2 can never be
>>>> >> released without a [functor] release, etc.
>>>> >>
>>>> >>>
>>>> >>> For developer testing, a snapshot release is probably sufficient,
and
>>>> >>> can be updated very quickly - no need for a vote.
>>>> >>
>>>> >> This is indeed sufficient for the immediate future, but again, becomes
>>>> >> *insufficient* soon enough.  I don't personally see what purpose
is
>>>> >> served by a 0.x release, but I have to say it's frustrating to work
on
>>>> >> a component and only when a release is proposed does everyone who
>>>> >> couldn't have cared less before come out of the woodwork to suddenly
>>>> >> find design issues (issues such as undocumented @SuppressWarnings
come
>>>> >> down to personal opinion and I would personally argue they shouldn't
>>>> >> be release blockers, particularly as more often than not the
>>>> >> justification is obvious).
>>>> >
>>>> > That entirely depends on circumstances; I've seen lots of cases where
>>>> > they are just used to silence warnings, with no attempt to solve the
>>>> > cause of the warning.
>>>> > In some (perhaps rare) cases, fixing the warning may point to a
>>>> > fundamental design issue, and/or need to change the API.
>>>> >
>>>> >> For those of you who have suddenly decided
>>>> >> you care about this component:  if we discuss and resolve the
>>>> >> fundamental design concerns (i.e. no promises beyond reaching
>>>> >> consensus), can you stay engaged long enough for us to get this
>>>> >> wrapped up?
>>>> >
>>>> > I'm happy to contribute if I can; I had not realised that an RC was
>>>> > imminent otherwise I might well have dived in earlier.
>>>> >
>>>> > There are too many components to follow every single one all the time;
>>>> > besides, things are often in a state of flux between releases -
>>>> > there's no point dotting i's and crossing t's if the entire paragraph
>>>> > is about to be rewritten. Been there, done that in other projects.
>>>> >
>>>> >> Matt
>>>> >>
>>>> >>>
>>>> >>>>
>>>> >>>> Emmanuel Bourg
>>>> >>>>
>>>> >>>> ---------------------------------------------------------------------
>>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> >>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>> ---------------------------------------------------------------------
>>>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> >>>
>>>> >>>
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> >> For additional commands, e-mail: dev-help@commons.apache.org
>>>> >>
>>>> >>
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> > For additional commands, e-mail: dev-help@commons.apache.org
>>>> >
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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


Mime
View raw message