[castor-dev] Re: [castor-user] Re: [castor-dev] Thinking about Castor 1.3.3
Clovis Wichoski <[email protected]> Tue, 3 May 2011 12:09:41 -0300
| Newsgroups | gmane.comp.java.castor.devel |
|---|---|
| Message-ID | <[email protected]> |
--20cf300258bc942cd504a260872b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 plac= e 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=F3vis 2011/5/3 Werner Guttmann <[email protected]> > 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 ca= n > > 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=C4s 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, bu= t > 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=F3vis > > > > 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 relea= se > >> 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 tr= y > >> to keep working towards 6 to 8 weeks cycles as long as there's more an= d > >> improved input form the user community. > >> > >> How to interpret this ? Well, Castor has been an open source project n= ow > >> for 10+ years. And I'd like to see it that way for another 10 years. B= ut > >> 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 i= n > >> the weeks before the 1.3.2 release, and I believe that such feedback > >> (whether in form of testing or patch provision or documentation patche= s > >> 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 a= n > >> open source project with actual involvement from the community. Most o= f > >> the Jira issues we get to see are bug reports (for a valid reason, tha= t > >> 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 provid= e > >> 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 ta= ke > >> 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 an= d > >> have meaningful conversations (at least we try) about their resolution= s. > >> But there's more to an open source project. There's mailing lists, lik= e > >> 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 highl= y > >> 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 fee= d > >> representing this 'activity stream' ? > >> > >> * And most importantly, what are folks actually missing most from Cast= or > >> ? Is there a genuine feeling that the product e.g. is not mature enoug= h, > >> 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 t= he > >> end this needs to be a community effort, and that's what I'd like to s= ee > >> happen. > >> > >> Thanks for your time reading this, and thanks (once again) to everybod= y > >> 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 > >> > >> > >> > > > --20cf300258bc942cd504a260872b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Werner,<br><br>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.<br><br>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:<br> <br>e.g:<br><br>"Today debugging castor, I managed to discover that ha= ve only one instance of ClassMolder per JVM not matter if you instantiate m= any different JDO instances but using same map."<br><br>or explaining = the strategies:<br> <br>"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."<br><br>appears to be easy samples, but to put new develop= ers in the path, have a great value.<br> <br>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.<br= ><br>best regards<br><br>Cl=F3vis<br><br><div class=3D"gmail_quote">2011/5/= 3 Werner Guttmann <span dir=3D"ltr"><<a href=3D"mailto:werner.guttmann@g= mx.net">[email protected]</a>></span><br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Clovis,<br> <div class=3D"im"><br> On 25.04.2011 16:01, Clovis Wichoski wrote:<br> > Hi Werner,<br> ><br> > I'm a user of castor since intalio manages the source, I know that= i can<br> > help in some places, and many points, but for me the great problem is = time<br> > to understand the castor code, before have a nice overview to touch an= y<br> > place.<br> </div>I agree that there's no nice overview which one could digest befo= re<br> looking at issues, etc. But there wasn't one when I joined Castor as a<= br> committer back in 2003. As such, it took me a lot of time to familiarize<br= > with major concepts.<br> <div class=3D"im"><br> > I think if exists a better documentation about castor internals<br> </div>> architecture, ...<br> <br> What sort of 'documentation' would you expect ?<br> <div class=3D"im"><br> > more developers can come, as the codebase can be more<br> > understandable, today if anyone try to learn castor codebase, we alway= s<br> > become lost and must ask someone to see if what we understand is reall= y what<br> > castor does.<br> </div>That even happens to me, to be honest. Sometimes the code does not<br= > relate its intention. That's especially true when there=C4s commented o= ut<br> code and/or comments that are very hard to digest.<br> <div class=3D"im"><br> > Then, for my opinion, I think that a great contribution for the projec= t is,<br> > if someone can write about how castor works internally or just the his= tory<br> > how that developer becomes castor code aware.<br> </div>To be honest: debugging, most of the time. Especially when I run into= <br> (un)marshalling issues these days that are not trivial, without a<br> debugger it would be very hard, if not impossible.<br> <div class=3D"im"><br> > I know if we debug, inspect each line of code, we can discover that, b= ut I<br> > think that a resume, can attract more developers and speed up some<br> > solutions.<br> </div>Once again: what should the resume try to communicate ? I'd reall= y like<br> to understand your proposal fully.<br> <br> Cheers<br> <font color=3D"#888888">Werner<br> </font><div><div></div><div class=3D"h5">><br> > best regards<br> ><br> > Cl=F3vis<br> ><br> > 2011/4/20 Werner Guttmann <<a href=3D"mailto:[email protected]">= [email protected]</a>><br> ><br> >> Hi everybody,<br> >><br> >> I am actually thinking about going for much shorter development cy= cles<br> >> when it comes to making Castor releases available. My intention - = as<br> >> already stated in the announcement email for Castor 1.3.2 - is to<= br> >> provide Castor 1.3.3 within 6 weeks (+/- 2 weeks) from the 1.3.2 r= elease<br> >> date.<br> >><br> >> Whilst I would love to keep this rhythm up and going for a long ti= me, my<br> >> (our) resources are limited by nature. Still, here's my offer:= I'll try<br> >> to keep working towards 6 to 8 weeks cycles as long as there's= more and<br> >> improved input form the user community.<br> >><br> >> How to interpret this ? Well, Castor has been an open source proje= ct now<br> >> for 10+ years. And I'd like to see it that way for another 10 = years. But<br> >> I have already invested a lot of time into this project (having be= en a<br> >> committer for the last 8 years), and it honestly feels quite '= lonely'<br> >> out there from time to time.<br> >><br> >> Having said that, I have seen some increased feedback on Jira issu= es in<br> >> the weeks before the 1.3.2 release, and I believe that such feedba= ck<br> >> (whether in form of testing or patch provision or documentation pa= tches<br> >> or new HOW-TOs) does pay back, indeed. At least to me it did in th= e<br> >> sense that it (once again) provided enough motivation to keep myse= lf<br> >> going and work towards the 1.3.2 release two weeks ago. A process = that<br> >> has been painful now an then, to be honest.<br> >><br> >> Here's what I'd like to discuss in general terms and propo= se to/ask of<br> >> the community in terms of making Castor more iterative and improve= its<br> >> quality/feature base:<br> >><br> >> * The more communication we (committers) get, the more it feels li= ke an<br> >> open source project with actual involvement from the community. Mo= st of<br> >> the Jira issues we get to see are bug reports (for a valid reason,= that<br> >> is). But most of the time, that's it. Being an open source pro= ject,<br> >> there's the sources. It actually is possible to assess the sou= rce code<br> >> and identify a problem area. Not everyone is capable/willing to pr= ovide<br> >> a patch out of nothing, but a patch does not have to actually incl= ude<br> >> working code and resolve a problem completely. We are very happy t= o take<br> >> patches that provide comments (that actually match the flow of a t= est<br> >> case provided, that identify code areas that you think are wrong, = ...),<br> >> pseudo code, etc.<br> >><br> >> * Communication is essential, indeed. There's Jira to report i= ssues and<br> >> have meaningful conversations (at least we try) about their resolu= tions.<br> >> But there's more to an open source project. There's mailin= g lists, like<br> >> this one, where the community can ask questions related to the pro= duct<br> >> offerings. There's the dev list, which to my surprise seem to = be highly<br> >> unused. Why is this ? And more generally speaking: what else has b= een<br> >> missed over the last years ?<br> >><br> >> * How many people actually visit Castor's Jira instance on a r= egular<br> >> base ? How many are actually 'reading' (aka following) the= activity<br> >> stream on the 'Summary' page '? How many are subscribe= d to the RSS feed<br> >> representing this 'activity stream' ?<br> >><br> >> * And most importantly, what are folks actually missing most from = Castor<br> >> ? Is there a genuine feeling that the product e.g. is not mature e= nough,<br> >> lacks (certain) features, etc. ?<br> >><br> >> I most definitely do acknowledge that Castor is a complex project,= <br> >> especially in terms of its code base (with major parts having been= <br> >> written around 2000), which could use some heavy refactoring. But = in the<br> >> end this needs to be a community effort, and that's what I'= ;d like to see<br> >> happen.<br> >><br> >> Thanks for your time reading this, and thanks (once again) to ever= ybody<br> >> that provided well-though feedback and input during the last few w= eeks.<br> >> And please do not hesitate to ask questions as a result of this em= ail.<br> >><br> >> Kind Regards<br> >> Werner Guttmann<br> >><br> >> ------------------------------------------------------------------= ---<br> >> To unsubscribe from this list, please visit:<br> >><br> >> =A0 =A0<a href=3D"http://xircles.codehaus.org/manage_email" target= =3D"_blank">http://xircles.codehaus.org/manage_email</a><br> >><br> >><br> >><br> ><br> </div></div></blockquote></div> --20cf300258bc942cd504a260872b--