This is quite valuable insight...and I thank you very much for taking
the time (the time to submit a patch no less ) to tell your story.
forgive me, but I'd like to summarize...
- We should all go to the wiki and read
http://wiki.python.org/jython/JythonDeveloperGuide, try it out and
give feedback on where it needs to be improved.
- High Level Design is not clear to us and we should try to get help
and suggestions as to how to get this knowledge. This is very
important as it seems alot of roadblocks can be clarified when we have
this. Clark has already said he is not privy to this info...is
Samuele the only one who knows (other then Jim Huggin?)
- There is a process of contributing code: write a patch (useing
diff....) --> submitt for review, and eventually getting it committed.
- Getting money from your boss at work for an OSS is hard....but I
think that we can approach it from other angles (eg. contributing
through a 3rd party vendor that we are a big customer of...etc etc...)
This is hard to do until we figure out for sure what we need on a
"Design" level...it hard to ask for help if you don't know where it's
needed in the software development process.
once again...thanks for your excellent account...
P.S. Raymond's post is very good to discourage "whiners", but there
must be a genuine problem when 1 of the 5 active developers we have at
jython doesn't have access to some important design information.
On 4/1/06, Updike, Clark <Clark.Updike@...> wrote:
> > Can we get a list of users that have commit access, sort of
> > get an feeling who our "upperclassmen" are ?
> > It would be interesting to see what their views on the recent
> > feedback are...
> I'm not sure exactly what you're looking for comment on,
> but if you'll excuse the long winded and personalized
> account, here's a chronology of my experience as a contributor
> to jython with some commentary/feedback interspersed
> (caveat: these comments are based on the project as it
> was circa June 05 when I last did active development):
> "Jython... A Developer's Story" ;-)
> My work on the jython project was my first (and only to-date)
> experience doing open source development. In other words, I
> was relatively new to cvs, ant, patches, branching,
> project contribution "protocol", etc. But I felt I had
> something to offer, so I rolled up my sleeves and jumped
> in. <comment>So I think it is important to encourage people
> to jump in if they have something to offer. Of course,
> you have to balance that to some extent, because managing
> and guiding new developers takes effort--nothing is free.
> </comment>. Another motivation was that my company had
> been using jython in production for a while. I'd
> broached the subject of my company making some kind of
> monetary contribution to the project, but it didn't go
> over. <comment>Sadly, I think this is a pervasive attitude.
> Companies will pay big bucks to commercial vendors but
> perhaps don't see the ROI in supporting something they
> can get "for free".</comment> Well, if my company won't
> do it, I'll go it alone...
> So I got involved and signed up for the collections
> integration. I enrolled in the "school of hard knocks":
> And I took my lumps asking the occasional stupid question
> or doing the wrong thing. Brian Zimmer was the project
> lead at the time. He was very encouraging and helpful
> (thanks Brian!). <comment.So that's a quality you probably
> need in a project lead--good at mentoring, willing to suffer
> idiots well ;-), can keep a lot of activities coordinated
> and nurse them along, able to leap tall buildings in a
> single bound. One of the issues that came up recently
> I believe was related to "could the project benefit from
> a project manager (that was not necessarily a developer)?"
> I think it is possible, but that such a manager would
> need a technical go-to and that the two would have to
> work closely together.</comment>
> I discussed design alternatives for the collections
> integration with Brian and we'd occasionally tap Samuele
> Pedroni. <comment>Samuele is our connection with the
> past--providing invaluable insight and often able to
> explain why artifacts of the design are what the way the are.
> But he's quite busy with PyPy so we are thankful that he still
> "keeps in touch" and monitors the list.</comment>.
> Okay, I've got an approved approach--time to start coding.
> So I start setting up my development environment for 2.2. It
> was a bit difficult--partly because I had not worked with this
> kind of toolset/project structure--but also because of a lack
> of documentation on how to do it. I think that's been remedied
> somewhat by http://wiki.python.org/jython/JythonDeveloperGuide
> <question>Have people been following these steps and do they
> work as advertised? Can they be improved?</question> I thought
> that I should be following a fairly straightforward recipe at
> the time, but I felt like I had to invent stuff to get it
> up and working--maybe it was just me, maybe there's room
> for improvement.
> Then I tried to get the unit test to run. I don't remember
> all the details, but I remember being bewildered. I remember
> lots of tests were broken and it seemed like there were different
> ways you could run unit tests and you'd end up with different
> results. There were several different types of unit tests
> (py unit, test_descr, ad hoc), and there were several different
> test directories involved including the "external" cpython tests.
> There was also an interaction with the way the build script moved
> stuff around. <comment>I know that there is a certain amount
> of inherent complexity, and the tests are necessarily
> "co-joined at the hip" with our cpython sibling for the forseable
> future (but I believe Brian did discuss segregating pure python
> test cases from cpython implementation specific tests with some
> folks at pycon at one point). But IMHO the testing
> infrastructure could stand some refactoring and pruning
> (there some cruft that could be cleaned up). Based on some email
> exchanges I had with Brian, I'm not sure if anyone understands it
> all. It would be nice if the instructions were more
> comprehensive--describing how it all hangs together, what type of
> tests there are, how to add new tests. Cruft should be cleaned
> out. Developers should know when they broke something, and when
> they haven't. A refactoring would be a big job--there a lot of
> "moving parts" in the test framework(s). It would be nice to
> try to standardize a bit more. I did put some effort into this,
> but it was clear a lot more could be done.</comment>
> So now I'm ready to actually try and write some code. Brian
> explained that "the path to becoming a jython developer
> starts with submission of a patch (hint: and you might want to
> make sure the unit tests pass or provide new unit tests if it
> is new functionality)". So I did my thing and eventually
> submitted a patch. Brian dutifully reviewed it and eventually
> committed it. I had inspired sufficient confidence in Brian
> that he offered me committer rights (scary--I could do some
> real damage now ;-). Eventually I was asked to work with/
> help out others, and review other patches.
> Ultimately, I wound down after the big push to get my stuff
> completed on schedule, and started enjoying a full nights
> sleep again. I was planning on taking a few months downtime
> and then picking back up again. Unfortunately, I was overcome
> by events at work and stopped actively developing (sigh!).
> But it was definitely a thrill to toil over the collections
> integration stuff and eventually get it working and ultimately
> committed. And I have cited the experience in my performance
> review where I work (I would hope all companies value their
> employees getting involved with open source). The developers
> I have worked with on the jython project are among the best
> developers I've ever been involved with. I look forward to
> getting more involved again at some point.
> Ok, enough with my story. Hopefully a prospective developer
> would find it interesting/encouraging and get involved. But
> there's a few other issues that didn't come up. One is the
> lack documentation on how jython works at the core. It's
> come up a couple of times before, and I think everyone agrees
> it's a good idea--but it's never been produced. The obvious
> reason is that only a handful of people understand the design
> down to the metal. I'm definitely not one of them. I've
> looked over the code but I have a tough time seeing how it
> all hangs together from 10,000 feet. That doesn't mean I
> can't be a productive developer. But it does limit my ability
> to really change the "core" of jython--whatever that
> means. So some of the really challenging tasks, like
> implementing new style classes, can only be done by one
> or two folks, and that's a bottleneck when those folks are
> busy. I'm not sure I could have _ever_ figured out how to
> implement new style classes (kudos to Samuele for doing so),
> but unless it becomes easier for developers to understand
> everything, these bottlenecks will remain.
> One other long term goal I've discussed with Frank is
> what it would take to eliminate jythonc, to directly
> compile to bytecode like groovy. It seems like jythonc has
> become a maintenance liability, and it sure would be
> nice to get the capability transparently. I understand
> that there is a method signature ambiguity issue but
> there are ways around that. Also, I believe Frank said
> there will be an inherent jythonc incompatibility with
> generators--so maybe it will have to happen anyway.
> So in closing, I've perhaps aired some dirty laundry,
> but don't get me wrong. There should be nothing preventing
> a surge of new developers from getting involved, pushing
> 2.2 out the door, and revitalizing the project. Hopefully
> I've identified some issues that might make it easier to
> bring more developers on in the future. Get involved,
> figure things out, make things better, document for
> others in the wiki (don't be afraid to edit what's there).
> Thanks to those that patrol the lists--that's a valuable
> service to everyone and helps contribute to the sense
> that jython is alive and someone is listening--a jython
> "dial tone" as it were.
> p.s. I probably could have produced a patch in the
> time it took to write this ;-)
Simplicity--the art of maximizing the amount
of work not done--is essential.