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 think if exists a better documentation about castor internals architecture, 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. 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. 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. 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 > > >
