Hi, one comment on the "graduation" aspect: basically it is not necessary to release tons of artifacts to graduate. My approach would be to continue with releasing the 0.4 package, there is not harm done with that, even when the code base completely changes. The purpose is to "learn releasing".
This project will graduate if it has shown it understand the Apache way, knows how to release, knows how the foundation itself works and how to include new people. Of course, licensing, trademarks etc must all be clear too. What I have seen the past 2 weeks or so is clearly this projects runs in the apache way so far. I believe you need to learn a bit more on the tools/services the ASF provide and the project needs to grow in its community. Besides that, I see you on a good path to graduation, if you would keep it that way and have more committers / code contributions. My point is: please don't let the potential graduation let dictate your technical decisions. You are able to graduate with a java server, but also when you move on to ruby. With 10 releases or with 1. Cheers Christian PS: I would clearly prefer Java for many reasons: lot more developers is one of them. On Wed, Jun 12, 2013 at 11:28 AM, Michael MacFadden <michael.macfad...@gmail.com> wrote: > Wavers. > > It is a very positive sign that the Wave project has seen increase activity > in recent weeks. However, recent conversations point to the fact that we > are at a decision point with Apache Wave. > > History > ------- > > Google donated quite a bit of code to Apache for the Wave project. It is > somewhat functional and is what the community is using to drive towards a > release. However, the current community has little expedience with the code > base. We didn't designed it and in many cases we don't understand it. > > As many have pointed out the code base is 1) Not easy to develop, 2) Hard to > learn, 3) and not modularized between the client and server. These issues > are hampering WiaB's adoption. > > Several people have suggested rewriting the codebase to separate the server > and client and to greatly simplify the architecture. > > > > I think as a community we need to decide what we want to do. I have put > forth three options which I would like the community to comment on. > > > 1) Keep the current code base and just push ahead. > > Pros: > ----- > - We have a functional codebase that we evolve over time. > - Potentially graduate sooner. > > Cons: > ----- > - Hard to get new developers excited about working with the code base. > - Poetnetially slows the evolution of a scalable architecture that delivers > what the community is asking for. > > > 2) Ditch the current code base and start new. > > Pros: > ----- > - We can design something that meets the community needs. > - We can simply the design from the beginning. > > Cons: > ----- > - We are very close to a release, this approach would set back future > releases. > > > 3) Keep the current code base AND start a new one. > > Pros: > ----- > - Can keep driving through the apache process. > - We still have a working product. > - We can start the redesign now. > > Cons: > ----- > - We barely have enough developers to maintain the current codebase. > - If interest in the new codebase takes off, existing codebase would > atrophy. > > > Comments please. Thanks. > > ~Michael > > -- http://www.grobmeier.de https://www.timeandbill.de
