commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [VOTE][RESULT] Release Apache Commons Functor 1.0 based on RC1
Date Sun, 23 Oct 2011 15:42:38 GMT
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


Mime
View raw message