Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka >> mail # dev >> [VOTE] Apache Kafka Release 0.8.0 - Candidate 2

Copy link to this message
Re: [VOTE] Apache Kafka Release 0.8.0 - Candidate 5
Not to get too side tracked, but I think lazy consensus is supposed to
mean "silence gives assent"

After the release, we should clean up the language of the bylaws to
match the language here http://www.apache.org/foundation/glossary.html

On 12/3/13 1:41 AM, Jun Rao wrote:
> The release voting is based on lazy majority (
> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws#Bylaws-Voting). So
> a -1 doesn't kill the release. The question is whether those issues are
> really show stoppers.
> Thanks,
> Jun
> On Mon, Dec 2, 2013 at 10:19 AM, David Arthur <[EMAIL PROTECTED]> wrote:
>> Inline:
>> On 12/2/13 11:59 AM, Joe Stein wrote:
>>> General future thought comment first: lets be careful please to raising
>>> issues as show stoppers that have been there previously (especially if
>>> greater than one version previous release back also has the problem) and
>>> can get fixed in a subsequent release and is only now more pressing
>>> because
>>> we know about them... seeing something should not necessarily always
>>> create
>>> priority (sometimes sure, of course but not always that is not the best
>>> way
>>> to manage changes).  The VOTE thread should be to artifacts and what we
>>> are
>>> releasing as proper and correct per Apache guidelines... and to make sure
>>> that the person doing the release doesn't do something incorrect ... like
>>> using the wrong version of JDK to build =8^/.  If we are not happy with
>>> release as ready to ship then lets not call a VOTE and save the prolonged
>>> weeks that drag out with so many release candidates.  The community
>>> suffers
>>> from this.
>> +1 If we can get most of this release preparation stuff automated, then we
>> can iterate on it in a release branch before tagging and voting.
>>   ok, now on to RC5 ...lets extend the vote until 12pm PT tomorrow ...
>>> hopefully a few more hours for other folks to comment and discuss the
>>> issues you raised with my $0.02852425 included below and follow-ups as
>>> they
>>> become necessary... I am also out of pocket in a few hours until tomorrow
>>> morning so if it passed I would not be able to publish and announce or if
>>> failed look towards RC6 anyways =8^)
>>> /*******************************************
>>>    Joe Stein
>>>    Founder, Principal Consultant
>>>    Big Data Open Source Security LLC
>>>    http://www.stealth.ly
>>>    Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop>
>>> ********************************************/
>>> On Mon, Dec 2, 2013 at 11:00 AM, David Arthur <[EMAIL PROTECTED]> wrote:
>>>   Seems like most people are verifying the src, so I'll pick on the
>>>> binaries
>>>> and Maven stuff ;)
>>>> A few problems I see:
>>>> There are some vestigial Git files in the src download: an empty .git and
>>>> .gitignore
>>>>   Ok, I can do a better job with 0.8.1 but I am not sure this is very
>>> different than beta1 and not necessarily a show stopper for 0.8.0
>>> requiring
>>> another release candidate, is it?  I think updating the release docs and
>>> rmdir .git after the rm -fr and rm .gitignore moving forward makes sense.
>> Agreed, not a show stopper.
>>>   In the source download, I see the SBT license in LICENSE which seems
>>>> correct (since we distribute an SBT binary), but in the binary download I
>>>> see the same license. Don't we need the Scala license (
>>>> http://www.scala-lang.org/license.html) in the binary distribution?
>>>>   I fixed this already not only in the binary release
>>> https://issues.apache.org/jira/browse/KAFKA-1131 but also in the JAR
>>> files
>>> that are published to Maven
>>> https://issues.apache.org/jira/browse/KAFKA-1133are you checking from
>>> http://people.apache.org/~joestein/kafka-0.8.0-candidate5/ because I just
>>> downloaded again and it looks alright to me.  If not then definitely this
>>> RC should be shot down because it does not do what we are saying it is