Hi Werner, I think you got the point, for example a good document I see on Castor was the "Castor JDO Road Map" maybe a document like that but updated with today information/reality.
another vision, is maybe, like a BLOG or Wiki page by commiter, explaining how he/she becomes a castor aware developer, for example, like a diary of knowledge: e.g: "Today debugging castor, I managed to discover that have only one instance of ClassMolder per JVM not matter if you instantiate many different JDO instances but using same map." or explaining the strategies: "To discover how LockEngine works, first write a small test case, then place a debug stop on class LockEngine, at method save and you can see the magic." appears to be easy samples, but to put new developers in the path, have a great value. ps: the sentences above maybe not true, I just type to give a sample, I really dont know castor internals, just some guess and a blur overview. best regards Clóvis 2011/5/3 Werner Guttmann <werner.guttm...@gmx.net> > Hi Clovis, > > On 25.04.2011 16:01, Clovis Wichoski wrote: > > Hi Werner, > > > > I'm a user of castor since intalio manages the source, I know that i can > > help in some places, and many points, but for me the great problem is > time > > to understand the castor code, before have a nice overview to touch any > > place. > I agree that there's no nice overview which one could digest before > looking at issues, etc. But there wasn't one when I joined Castor as a > committer back in 2003. As such, it took me a lot of time to familiarize > with major concepts. > > > I think if exists a better documentation about castor internals > > architecture, ... > > What sort of 'documentation' would you expect ? > > > more developers can come, as the codebase can be more > > understandable, today if anyone try to learn castor codebase, we always > > become lost and must ask someone to see if what we understand is really > what > > castor does. > That even happens to me, to be honest. Sometimes the code does not > relate its intention. That's especially true when thereÄs commented out > code and/or comments that are very hard to digest. > > > Then, for my opinion, I think that a great contribution for the project > is, > > if someone can write about how castor works internally or just the > history > > how that developer becomes castor code aware. > To be honest: debugging, most of the time. Especially when I run into > (un)marshalling issues these days that are not trivial, without a > debugger it would be very hard, if not impossible. > > > I know if we debug, inspect each line of code, we can discover that, but > I > > think that a resume, can attract more developers and speed up some > > solutions. > Once again: what should the resume try to communicate ? I'd really like > to understand your proposal fully. > > Cheers > Werner > > > > best regards > > > > Clóvis > > > > 2011/4/20 Werner Guttmann <wgut...@codehaus.org> > > > >> Hi everybody, > >> > >> I am actually thinking about going for much shorter development cycles > >> when it comes to making Castor releases available. My intention - as > >> already stated in the announcement email for Castor 1.3.2 - is to > >> provide Castor 1.3.3 within 6 weeks (+/- 2 weeks) from the 1.3.2 release > >> date. > >> > >> Whilst I would love to keep this rhythm up and going for a long time, my > >> (our) resources are limited by nature. Still, here's my offer: I'll try > >> to keep working towards 6 to 8 weeks cycles as long as there's more and > >> improved input form the user community. > >> > >> How to interpret this ? Well, Castor has been an open source project now > >> for 10+ years. And I'd like to see it that way for another 10 years. But > >> I have already invested a lot of time into this project (having been a > >> committer for the last 8 years), and it honestly feels quite 'lonely' > >> out there from time to time. > >> > >> Having said that, I have seen some increased feedback on Jira issues in > >> the weeks before the 1.3.2 release, and I believe that such feedback > >> (whether in form of testing or patch provision or documentation patches > >> or new HOW-TOs) does pay back, indeed. At least to me it did in the > >> sense that it (once again) provided enough motivation to keep myself > >> going and work towards the 1.3.2 release two weeks ago. A process that > >> has been painful now an then, to be honest. > >> > >> Here's what I'd like to discuss in general terms and propose to/ask of > >> the community in terms of making Castor more iterative and improve its > >> quality/feature base: > >> > >> * The more communication we (committers) get, the more it feels like an > >> open source project with actual involvement from the community. Most of > >> the Jira issues we get to see are bug reports (for a valid reason, that > >> is). But most of the time, that's it. Being an open source project, > >> there's the sources. It actually is possible to assess the source code > >> and identify a problem area. Not everyone is capable/willing to provide > >> a patch out of nothing, but a patch does not have to actually include > >> working code and resolve a problem completely. We are very happy to take > >> patches that provide comments (that actually match the flow of a test > >> case provided, that identify code areas that you think are wrong, ...), > >> pseudo code, etc. > >> > >> * Communication is essential, indeed. There's Jira to report issues and > >> have meaningful conversations (at least we try) about their resolutions. > >> But there's more to an open source project. There's mailing lists, like > >> this one, where the community can ask questions related to the product > >> offerings. There's the dev list, which to my surprise seem to be highly > >> unused. Why is this ? And more generally speaking: what else has been > >> missed over the last years ? > >> > >> * How many people actually visit Castor's Jira instance on a regular > >> base ? How many are actually 'reading' (aka following) the activity > >> stream on the 'Summary' page '? How many are subscribed to the RSS feed > >> representing this 'activity stream' ? > >> > >> * And most importantly, what are folks actually missing most from Castor > >> ? Is there a genuine feeling that the product e.g. is not mature enough, > >> lacks (certain) features, etc. ? > >> > >> I most definitely do acknowledge that Castor is a complex project, > >> especially in terms of its code base (with major parts having been > >> written around 2000), which could use some heavy refactoring. But in the > >> end this needs to be a community effort, and that's what I'd like to see > >> happen. > >> > >> Thanks for your time reading this, and thanks (once again) to everybody > >> that provided well-though feedback and input during the last few weeks. > >> And please do not hesitate to ask questions as a result of this email. > >> > >> Kind Regards > >> Werner Guttmann > >> > >> --------------------------------------------------------------------- > >> To unsubscribe from this list, please visit: > >> > >> http://xircles.codehaus.org/manage_email > >> > >> > >> > > >
