HI Nick, I think it would be very good to start with some discussions now and to be prepared as good as possible for the meeting.
Not sure if everyone has seen it... Florian provided a nice architecture diagram in the Wiki page: http://cwiki.apache.org/confluence/display/CMIS/OpenCMIS+Modules Stuff like this can help kicking off discussions, identifying common ideas and seeing differences in the design and implementation. Jens -----Original Message----- From: Nick Burch [mailto:[email protected]] Sent: Donnerstag, 11. März 2010 16:38 To: chemistry-dev Subject: RE: Meeting and code merge 4/12 - 4/16 On Thu, 11 Mar 2010, Florian Müller wrote: > I've created a Wiki page [1] to plan out the meeting. Please add your > name to the participants list if you plan to come. I should be able to attend. I'd be planning to act as a mentor not a coder, so helping ensure things are done according to the Apache Way, as well as trying to keep the rest of the community in the loop with discussions. With that in mind, it would be good if we could do a bit of planning before hand. (It's going to be a little tough for people not at the meeting to follow and comment, so we need to give them the best chance we can!) This would be in addition to working out the agenda. For most of the codebase, in discrete chunks, I guess we'll need to decide between the options of: * Keep the two versions in parallel * Go for the Chemistry version * Go for the OpenCMIS version * Merge the two into a new API One thing that would seem to be helpful is if we could identify a couple of small areas of both the API, and work up in advance what the latter 3 options would entail. So, for example * Document the Chemistry API, what its strengths are, what its weaknesses are, and what work there'd be for OpenCMIS users to switch to it * Document the OpenCMIS API, what its strengths are, what its weaknesses are, and what work there'd be for Chemistry users to switch to it * Try to write a combined API, and detail why it's better than the two original ones, and why it isn't Everyone can then chip in with if they feel the documentation is fair, and if they feel the combined API has been done correctly. This will give us a start on reviewing, and give everyone something to reference in later discussions. That gives us the option to discuss in person a given bit of the API, and for example: * In person discussions on FooBar API * Decision that the Chemistry API is better in the case of FooBar, and that a migration from code calling the OpenCMIS api to switch would be easy * Document the idea on the wiki * Report to the list that "FooBar API seems quite like the case in example #1, and as such we're planning to keep the Chemistry Version as-is" * Overnight someone reviews and spots an area where one bit the OpenCMIS API should be kept and merged in * Re-discuss in person, and then commit the change to the FooBar API * Discussions have been helpful, the community is kept in the loop, and community contributions have been very valuable My fear is that without a few worked examples for everyone to review and discuss in advance, it's going to be too hard to capture and share the output of 3 hours of meetings and whiteboard scribblings in a way that people not there can comment on. I think we need some shared points of reference to point to. Does that make sense to everyone? If so, does anyone have some ideas for a couple of (small!) areas of the code where there's duplication that we can work through the different options in advance? Nick
