I would like to react to the testing issue, and to propose sg.
(Please forgive me if it's not accurate, I admit I did not even downloaded the Jython sources)
I think that whatever the testing framework, the project should be able to be downloaded, compiled, tested ...in just a few clicks. The idea is that when a new developer comes, it must be very easy to start; otherwise the time it takes to understand how it works stops most of us.
If you can have your project "mavenized", it would be great. Download it, "maven eclipse" it (if you use Eclipse) and your Eclipse project is set, "maven test" it and it is compiled / tested. You can start coding, every dependent jar is downloaded, the project configuration is OK, etc, etc.
If you can do that, I'll try to have my company put several integration environments, at least Solaris, Linux and Windows, may be others (Tru64, HP-UX, AIX). They would d/l, compile, test and send emails to a predefined list of users each time sg is commited on the code. The biggest issue is about security, so I need to see how I could have the code be tested without beeing able to access any company's resource. That's the only problem, but it is such a big one...
About the framework which should be used to create the test... well, several things :
- First, I prefer TestNG, and this is a framework we know
- Second, JUnit is OK, but has so many restrictions...
...these two framework make readable reports, and that's the only thing that counts : being able to understand quickly what works/does not work.
- but I can also give help to create Jython tests that can be run by the TestNG or Junit framework. It is important because it gives you the ability to take the power of testNG or Junit tests/reports, and to write your tests in your prefered language (Jython, anybody ?). I work on a project which enables this (Yactu).
Just my 2 cents,
(Clark, sorry for the 2 emails...)
> 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.
Yes. Although it sounds like with the reorg Frank is doing
those instructions may be changing. Ideally, the process
is straightforward and reasonably bullet proof, even to people
new to this kind of environment.
And your summary didn't mention the testing issues--which I
think are also quite important. I burned way more cycles trying
to understand the testing than I did the build.
> - 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?)
I don't mean to sell anyone else short. Maybe Frank or others
could have tackled new style classes and such. I just know
I never understood the core and frequently wished there was
a "trail map" to look at. I'm sure some people can dig through
the code and figure it all out--but even a small amount of
documentation would make it easier for everyone.
> - There is a process of contributing code: write a patch (useing
> diff....) --> submitt for review, and eventually getting it committed.
There's a couple of processes involved:
> patch submission
> bug reporting
> bug fixing
> development on a branch
> others I'm not even aware of
There's a right way and many wrong ways to do them, and it
involves the sourceforge functionality. It's not rocket
science--but you'd think this would all be spelled out
somewhere since there's so many sourceforge projects. At
least when I was getting involved, I never found anything
that explained it all. Maybe there's better resources now.
When should a bugs status be changed to fixed? When should
it be changed to closed? Maybe someone that knows this stuff
well from other project work could document it on the wiki.
> - 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.
There's probably no substitute for people just rolling up
their sleeves and diving in anyway. Money might potentially
just mess things for some of the reasons already mentioned
on the list.
> once again...thanks for your excellent account...
I've just been waiting for the right moment to jump in :-)
> 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.
"doesn't have access" is more like "doesn't know" or
"couldn't figure out for himself". And as I mentioned,
there is plenty that one can contribute without knowing
Lastly, I regrettably made it sound like I was the only one that
did the collections integration work--it was most definitely a
multi-person effort. Brian Zimmer did the set stuff, I was only
helping Mike Garcia on the dictionary implementation, and Andrew
Howard was a big help with making PyArray align with Python 2.4,
and Samuele was always willing to weigh in with advice. Thanks
to everyone involved.
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
Jython-dev mailing list