incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <>
Subject Re: concerns about high overhead in Apache incubator releases
Date Mon, 28 Nov 2011 21:05:52 GMT
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message