Toben, I agree and would echo your sentiments.
I think that waveprotocol.org can remain the central place where the wave protocol is managed and wave in general is discussed. Waveprotocol.org should have all WIAB stuff eventually moved over to Apache, such that it is not linked to any one particular implementation. This should be the place where the entire wave community can collaborate on the platform as a whole. The only things that should be discussed on the wave-dev mailing list at Apache are things that specifically relate to wave implementation under the Apache project. One small comment. We wanted to call the larger project "Apache Wave" and not "Apache Wave in a Box" because it is quite likely that the Wave Project will have several releasable components beyond just the WIAB server. We may release client APIs, the OT Engine, Example Gadgets (keep in mind I don't know if any of these will happen, just showing examples). Your point about the KDE project is well understood. However, the difference here is that if other things like the ones I mentioned above exist in the Apache Wave project, they would be in different code trees, have different versions and different release cycles. Lots of apache projects do this at Apache. If you look at the maven project there is the Maven core build system that Apache puts out, but the project also hosts the DOXIA, SureFire, SCM, etc plugins as well as some other shared components. However, these additional things are treated as sub-projects and do not impact the releasability of Maven itself. If, and I stress if, the wave projects decides to maintain additional components, it would need to be done in this manner. ~Michael On Dec 13, 2010, at 9:42 AM, Torben Weis wrote: > Disclaimer: The following is just my personal opinion. > > As Chris pointed out, the confusion was to be expected. > > However, the alternative would not be much better currently. We would have > two mailing lists, one for Apache Wave (WiaB) > and one for wave in general. New developers will find this quite confusing. > Right now we have one place to go > to exchange opinions and ideas about wave: The Apache Wave mailing list > (wave-dev). > > The result is that the mailing list has a broader scope than the code base. > This means that things which are considered cool > on the list (i.e. other wave servers, etc.) are not considered for inclusion > in the Apache Wave code base. Which in turn can lead to > situations where developers are disappointed because their code will not > become part of Apache Wave. > > On the long run we must therefore split this mailing list. Right now the > message volume is comparably small and splitting > the community right now might hurt more than it helps. At the very moment > where WiaB developers ask why there is so much wave-vs, lightwave, pygowave, > XYZwave discussion on the list, we have found the right moment to split. > > A note about what to include in the Apache Wave code base and what not to > include. In my long ago KDE times we included every piece of code that used > KDE stuff into the KDE repository. In the beginning this was cool because > the size of the project grows very fast which signals momentum and activity. > Eventually, releases become more and more difficult because the entire code > base must converge against a stable build at the same time. Factoring out > large chunks of code later is a hard task. > > We must find means of collaborating with commercial and open source wave > efforts outside of Apache Wave. Open Source code which is not labeled > "Apache Wave" must not be seen as second class wave code. This is difficult > because developers feel more proud when they manage to include their stuff > in this famous Apache project. The difficulty is to say "no" or "not yet" > without discouraging new developers. > > When should we include large chunks of new code in the code base? > Example: Should C++/C#/Go/Python client-libraries be part of Apache Wave? > In my opinion this should depend on several criteria > a) It does not duplicate efforts in Apache Wave > b) It is directly related to Apache Wave and is a nice supplement to the > current code base > c) The to-be-submitted-code is already actively maintained and the > developers have shown that they are willing and able to maintain it further > d) The Apache Wave developers feel that they can maintain the new code even > if some key developer may drop out later > > So the answer regarding the client libraries is: It depends. > It depends on the community around this new code (i.e. criteria c) and d) ) > > Again, this is just my personal opinion. It is at best a suggestion for > management policies. > > Greetings > Torben > > 2010/12/13 Chris Harvey <ckhar...@gmail.com> > >> Seems to me we are (already) seeing "WIAB" verses "Wave" confusion >> starting. >> >> This is what I feared when we were discussing whether the specs should be >> part of Apache. As Torben pointed out, "Apache Wave" is really "Apache >> WIAB". >> >> The specs should stay as waveprotocol.org. Those interested (in >> particular) >> in wave server development would be part of a community that develops ideas >> around the specs. >> >> "Apache WIAB" should then follow the specs (if WIAB is indeed to be seen as >> a "Reference Implementation"). >> >> There should also be a recognition that the so-called specs are effectively >> nothing of the sort. They are a good, yet disconnected, out-of-date, at >> times confusing, set of white papers that need considerably more work >> before >> other server developers can get really stuck-in. >> >> = 2c >> >> -- >> Chris >> iotawave.org >> Singapore >>
