SGTM, thanks Torben. On 14 December 2010 05:10, Torben Weis <torben.w...@gmail.com> wrote:
> 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 >
