<blockquote><i>My second point: there must be a dedicated "sdm watcher", someone whose priority would be going through bugs in sdm and fixing them, closing
invalid bugs etc. Otherwise sdm will become useless very quickly. Clearly not many people qualify for this position: this someone would have to have
full cvs access and ability to close bugs in sdm. </i></blockquote>
Well, if in your opinion there *must* be an SDM watcher, back up your words by offering to volunteer your time to take on this role! As always, I find that people are more willing to offer criticism than to step up and offer ten or so hours a week of volunteer time.
<p>
And, yes, I do appreciate the fact that you've passed along some bug fixes as well as bug reports. Still, we're volunteers here and my long experience with volunteer crews tells me that there will be little patience with folks *demanding* that certain roles be filled unless those folks are willing to volunteer to pitch in and help.
<p>
Roberto's answered your criticism of 3.2 very well. If you or someone
else wants to volunteer to go through the SDM and mark fixed bugs as being closed, that would be great.
<p>Any takers? Just e-mail Roberto, I'm sure he'll welcome the logistical help.
<p>As far as OpenACS 4 goes, no, we won't fix all reported bugs in this release. Hope to burst anyone's bubble, but aD left us with a lot of shortcomings, unfinished pieces, and out-and-out bugs in the code base. While I do hope we can fix many of the out-and-out bugs, the first priority is to make sure we have a solid replica, if you will, of the aD 4.2 code base running on both Oracle and Postgres.
<p>Of course we will want to move quickly on to address shortcoming and to fix as many bugs as possible in the coming months, but unless folks want to wait until 2002 for a release, we're going to have to accept the fact that we can't make all the improvements nor fix all the shortcomings in the code base before making our first release.
<p>Does this mean that testing and bug reporting is therefore a fruitless task? My guess, Yon, is that you're just about the only person who will look at it that way.
<p>Part of our test plan will include working to make sure package porters are kept up to date on bug reports on their packages, that we get some idea as to how and when bugs will be fixed, etc. I can tell you right now, though, that the person who has offered to *coordinate* this effort isn't going to have time to do all of the work themselves.
<p>They will need help. We've already been talking about the need for things like regression testing, good performance testing and the like (most of which *won't* happen during this first release cycle, but which we want to get started on). In other words a more formal testing program. These things don't happen by hand-waving on the part of consumers, they happen by virtue of hard work on the part of producers.
<p>Now let me repeat: we're looking for volunteer testers. Let's not turn this into another argument over whether or not the project's on the right path, OK? If you want to discuss such issues, please start another thread so folks don't lose sight of the purpose of my post.
