I agree about the importance of getting a general set of integration tests to use against clients. I filed a JIRA for this, let's discuss approaches to building this there. People mentioned different libraries or ideas, can folks help flesh out their ideas on the JIRA so we can get to a concrete design: https://issues.apache.org/jira/browse/KAFKA-217
The goal of adding clients to the main code base is the following. In my past experience it is very hard to get a solid set of clients if there isn't an "official" client. What happens is that you get 3-4 partially working clients, and no one wants to improve them since it is fairly easy to just re-implement. I think having some criteria for the clients will mean that in practice they get integrated a little later than they do now which will give things more time to mature. -Jay On Tue, Nov 29, 2011 at 10:27 AM, David Ormsbee <d...@datadoghq.com> wrote: > Hi folks, > > I think the single most important thing the project can do to > encourage driver development is to make the solid set of integration > tests that others in this thread have been talking about. Without > those tests, I could easily see myself mis-implementing compression in > such a way that I break compatibility with other producers/consumers, > or missing odd corner cases because of my lack of understanding of > Kafka. > > We could have a scorecard for different levels of support. For instance: > > * Support all basic operations > * Support compressed messages (zlib, snappy) > * Support versions: 0.6, 0.7 (for backwards incompatibile header changes) > * Support ZooKeeper-based consumer/producer > * ... > > I don't believe the Kafka project needs to make decisions about > folding drivers into the official repo at this time. If there's a > solid set of tests to measure compliance that can run against simple > driver command-line interfaces, we can just point potential users to > the various drivers, their scorecards, and their user list. As Kafka > gets closer to a 1.0 release and third party drivers have proven their > ability to keep up with the latest and greatest in wire format > changes, the project can make a much more informed decision on whether > to incorporate or officially bless a particular set of drivers. > > Take care. > > Dave > > > On Tue, Nov 29, 2011 at 1:10 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > > Yes, the owner should ideally be a committer. > > > > We haven't set out official criteria for being a committer, but in my > mind > > the criteria is a non-trivial contribution of code and an interest in > > ongoing contributions going forward. I think a client would meet that > > criteria. > > > > I think ideally we would actually get two people for each client since > > otherwise we end up needing to review code in languages no one really > > knows, which is not ideal. > > > > -Jay > > > > On Tue, Nov 29, 2011 at 7:36 AM, Jeffrey Damick <jeffreydam...@gmail.com > >wrote: > > > >> Would the owner have commit rights (even if just to that client code > part > >> of the tree) ? > >> > >> > >> > >> On Tue, Nov 29, 2011 at 2:51 AM, Jay Kreps <jay.kr...@gmail.com> wrote: > >> > >> > - An owner for this client who would be willing to maintain this > code > >> > going forward. This probably isn't a hugely time consuming job, but > it > >> is > >> > good to have a contact person who can be point for questions or > fixes. > >> > > >> > > >
