Hi, 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. >
Having affiliated sub projects in different source trees and different release cycles is perfectly ok with me. We just have to clearly communicate the difference between the core code tree and the affiliated ones (i.e. sub projects). It is the same with KDE these days. However, we need to have an eye on dependencies, i.e. the core source tree must not depend on the affiliate ones because they run on a different release schedule. Seems trivial now, but has proven difficult multiple times. > 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. > I fully agree. Greetings Torben > > ~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 > >> > > -- --------------------------- Prof. Torben Weis Universitaet Duisburg-Essen torben.w...@gmail.com
