commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject [functor] API, etc., review WAS Re: [VOTE][RESULT] Release Apache Commons Functor 1.0 based on RC1
Date Sat, 21 Jan 2012 03:28:41 GMT
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


Mime
View raw message