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 <[email protected]> > >> 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 >> >> >> > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
