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. Jun On Mon, Nov 28, 2011 at 1:05 PM, ant elder <ant.el...@gmail.com> wrote: > On Sun, Nov 27, 2011 at 7:13 PM, Jun Rao <jun...@gmail.com> 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: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
