I try to follow the discussions on IRC regularly, and I have some worries after what I have seen in the last couple of weeks. There seem to be too many problems with broken checkins. The translation breaks, tests stop working etc. While I understand that running tests takes an enormous amount of time, it worries me that we have to fix things on the trunk so very often. I think this eats up time that could be better spent. If people need to leave testing for automated tests, there ought to be a less disruptive way of doing this. Of course I may be wrong, and this is really the optimal way of moving forward, but the I would like to be reassured that it is that way. A second thing that is bothering me is that there does not seem to be a canonical list of software that our development system is designed to work with. I feel that this is important. It is difficult enough to make things work with a specific set of tools. Currently we should be making sure that things work with one set of tools and the generalization to various different versions of pygame, grapviz, gcc and whatnot can happen later. I know this is not quite attainable, since preferred versions of the various tools don't work on all platforms, but I hope you see the core point. Trying to make things work with all possible combinations of peripheral software will just generate lots and lots of work. We need a public stance on what we support. Jacob Hallén
On Wed, 11 Oct 2006 01:53:04 +0200, Jacob Hallén <jacob@strakt.com> wrote:
I try to follow the discussions on IRC regularly, and I have some worries after what I have seen in the last couple of weeks.
There seem to be too many problems with broken checkins. The translation breaks, tests stop working etc. While I understand that running tests takes an enormous amount of time, it worries me that we have to fix things on the trunk so very often. I think this eats up time that could be better spent.
If people need to leave testing for automated tests, there ought to be a less disruptive way of doing this.
Of course I may be wrong, and this is really the optimal way of moving forward, but the I would like to be reassured that it is that way.
I'd like to echo this sentement. It's really amazing how much progress the PyPy project has made over the last year or so, but it's frustrating to never be sure if updating to the latest revision is going to eliminate my ability to do anything with it. The translation process is currently immensely expensive, so I can certainly understand that people want to commit to trunk without doing extensive testing (I can imagine such testing taking up an entire day or more in some cases). But as well all know, the introduction of regressions into trunk comes with costs too. I'm not going to suggest any specific course of action, because I'm confident everyone involved with the PyPy project can recognize this problem and consider ways to address it. Howeverr, if there's anything I can do to help come up with or enact a solution, I offer what assistance I can. For starters, if it would be helpful, I may be able to offer some hardware to run the automated test suite. This aside, PyPy has come a long way, and everyone involved should be very proud of what you guys have created. I have confidence that these growing pains will soon be behind the project.
A second thing that is bothering me is that there does not seem to be a canonical list of software that our development system is designed to work with. I feel that this is important. It is difficult enough to make things work with a specific set of tools. Currently we should be making sure that things work with one set of tools and the generalization to various different versions of pygame, grapviz, gcc and whatnot can happen later. I know this is not quite attainable, since preferred versions of the various tools don't work on all platforms, but I hope you see the core point. Trying to make things work with all possible combinations of peripheral software will just generate lots and lots of work. We need a public stance on what we support.
Jacob Hallén
Jean-Paul
participants (2)
-
Jacob Hallén
-
Jean-Paul Calderone