incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jun Rao <>
Subject Re: concerns about high overhead in Apache incubator releases
Date Tue, 29 Nov 2011 04:46:18 GMT
Thanks everyone for the feedback. This is very constructive and helpful. We
will try to roll out a new RC accordingly.

We are grateful for all the help that we got from Apache members and are
proud to be part of Apache.


On Mon, Nov 28, 2011 at 1:05 PM, ant elder <> wrote:

> On Sun, Nov 27, 2011 at 7:13 PM, Jun Rao <> wrote:
> > Dear Apache members,
> >
> > Over the past 2 months, the Kafka Apache incubator project has been
> trying
> > to release its very first version in Apache. After 7 RCs, we are still
> not
> > done. Part of this is because most of us are new to the Apache release
> > process and are learning things along the way. However, I think Apache
> can
> > do a better job in the incubating process to make releases much less
> > painful. In the following, I will summarize some of problems that we
> > had experienced. This is not an accusation, nor is it personal. I just
> hope
> > that we can all learn from our experience so that Kafka and other
> incubator
> > projects can release more smoothly in the future.
> >
> > 1. There is no good example to follow.
> > As a new incubator project, the natural thing for us to do when it comes
> to
> > releasing our code is to follow what other Apache projects do. However,
> > more than once, the feedback that we got is that those are not good
> > examples to follow. It seems that those "bad" examples are not isolated
> > cases.
> >
> > 2. Different Apache members have different interpretations of the same
> rule.
> > It seems that there is no consensus on some of the basic rules even among
> > Apache members. For example, what constitutes a source distribution and
> > what should be put in the NOTICE file? Since all it takes is one negative
> > vote to block a release, this increases the turnover rate of RCs.
> >
> > 3. Not enough constructive and comprehensive suggestions.
> > Some of the issues that are present in Kafka RC7 exist in RC1. Those
> issues
> > could have been resolved much earlier had there been more constructive
> and
> > comprehensive feedbacks from early on. Instead, often, the feedback just
> > points out the violation of one or two issues that are enough to block a
> > release. People like Ant Edler have made some constructive suggestions
> and
> > we really appreciate that. We could use more suggestions like that.
> >
> > 4. Not enough flexibility in applying the rules.
> > Some of the rules don't make common sense. For example, if we publish a
> new
> > RC that simply fixes a few lines in NOTICE/LICENSE. We are still required
> > to go through a full 3-day vote in Kafka and another full 3-day vote in
> > Apache general. This, coupled with the high turnover rate of RCs, can
> delay
> > the release for a significant long time. Both Chris Douglas and Ant Edler
> > wanted to relax the rule slightly to help us speed things up. However,
> not
> > every Apache member tolerates such flexibility. Again, all it takes is
> just
> > one vote to kill a release.
> >
> > To summarize, our experience of releasing in Apache has not been very
> > pleasant so far. I am not sure if our experience is the exception or the
> > norm among incubator projects. In any case, I sincerely hope that at
> least
> > some of those concerns can be addressed in Apache to make the release
> > process more enjoyable, especially for new comers.
> >
> > Thanks,
> >
> > Jun
> >
> I'd like to apologize on behalf of the Incubator for this less than
> excellent experience with your first release. Releases can be hard and
> they are one of the top things poddlings need to learn how to do but
> we should have been a bit better at teaching this and not let this
> release become such a long drawn out and painful process.
> As others have also commented in this email thread releases can't be
> veto'ed so just because you have a -1 or negative comment doesn't mean
> you need to respin right away. It does mean though that others might
> be put off from voting +1 so if that happens get your mentors to sort
> out it if its an issue or not, and don't be shy about emailing them
> directly if they are not participating already.
> Your email also mentions "rules" in several places - there aren't that
> many rules so before assuming something really is a rule try to find
> where its document that it is, and if no one can find that doc then
> its not a rule. Also, rules are only defined on policy pages so just
> because some "guide" type page says something doesn't make it true.
> For example, the comment about needing to vote once on kafka-dev for
> 72 hours and then again on general@ for another 72 hours - nothing
> says that must happen, if you like start right off here on general@,
> or, keep it just on kafka-dev and persuade three Incubator PMC members
> to vote over there (though you should probably notify general@ thats
> happening just so we know). In fact, even the minimum of 72 hours
> isn't a rule - the voting page people have been pointing you to only
> says "Votes should generally be permitted to run for at least 72
> hours..." so there is flexibility there.
> However those comments aside you do still need to try to make your
> release artifacts reasonably correct. Once you've got this done in the
> first release it becomes less of a pain later because it likely wont
> change that much in subsequent releases. A problem with doing this for
> Kafka is that it has quite a lot of dependencies, 54 jars by a quick
> count, so its a big job tracking down what all the licensing
> conditions are. Additionally, what is there now in the LICENSE and
> NOTICE files doesn't have any comments on why its there or what it
> applies to so it makes it difficult to work out if it should be there
> or not. For example, the LICENSE file presently includes things like
> the MIT license but I don't know why, if you had a comment at the top
> of each license saying its there because xyz.jar uses it then it would
> be much clearer and easier to work out if its required or not.
> To move this along I think you should now go ask your three mentors to
> help you get the current release artifacts sorted out and all the
> LICENSE and NOTICE files updated correctly based on all the RC review
> comments, thats what the signed up to help with, email them directly
> to ask and if they don't answer quickly ask for someone else here to
> help. Ping general@ when its almost done so we can do a quick review
> and only then call a new vote.
>   ...ant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message