Joe Creator: Would you mind testing my software for me?
Guinea Pig: What is it you want me to test?
Joe Creator: Download the software and see for yourself.
Guinea Pig: I'm a busy guy. I don't have a lot of time to fix problems if what you're giving me impacts me very negatively. What changes did you make?
Joe Creator: Look, either download the software and test it or just say no.
Guinea Pig: Of course, if I knew what I was getting into, I might be willing to test your software, but since you put it that way, no.
Sorry Chris, I disagree. Any time I make changes to something where I work and ask someone to test my changes, its only respectful that I include what I'm asking them to test before they start testing rather than making them go download the software and look for the list of changes. Then, they can make the determination of whether or not to become a guinea pig or not without the time spent downloading. If nothing else, posting a link to the changelog (by itself) would be nicer than "you should know enough about building from source to find the changelog"
Think about it this way - we are all busy people, yourself included, I'm sure. If you want to get my help (as another busy person), making it easier for me to know what I'm "signing up for" helps me understand just how much risk I'll be taking and helps make sure all your testers see what they should be testing. I know I may be "preaching to the choir" here, but hey, we're all volunteers, right?
<soap box mode>
What am I trying to do? GNUCash has the potential to win an awful lot of Quicken users if we keep software quality up. Intuit also releases intermediate updates between its major versions (just like we're proposing with 1.8.2). What would happen with Quicken if Intuit didn't do a good job of pre-testing its intermediate releases with a limited set of "real-world" customers? How about the same with MS Money? At a company I worked for, they had a problem with releasing software far too often and not giving their QA team enough time and information to adequately test the software prior to release. They also didn't get enough testers (people in the company outside the QA dept.) to help them test the software, often because testers didn't know what to look for because they didn't know what had changed. It was killing my team's ability to manage the production environment properly because the product itself was broken more often than not. I wound up being a part of the team that required engineering to publish release notes to the wider audience. What did that do for us? It helped us get more testers by helping them know what they were getting into. Net result - improved testing yielding improved software quality yielding improved customer satisfaction.
</soap box mode>
I would love to see GNUCash be able to compete with Quicken and Money. We're getting closer to that point. The challenge is setting it as a goal, then doing what it takes to get us there. One of the "habits" we'll need to develop to be truly competitive with the commercial packages is to make sure our QA process is very tight for all our releases, something the commercial software developers know quite well. We all know this is a -devel mailing list. Let's make sure the -devel doesn't ignore the needs of the -tester or the -users
I don't know if I have the time to do this, or if anyone is already steering it, but heck, if you guys want me to be a leader on the QA front, I'm willing to consider it. I don't want to step on any toes or get anyone's feelings hurt (Chris - read that to say I'm not trying to take your job). I'm not saying we're doing a bad job, but like anyone, I do think we can do better by changing a habit or two here or there and being more process sensitive. Frankly, I don't know if I want the job, but hey, GNUCash is a critical part of Linux being able to kill M$'s desktop monopoly. I'd like to see them face some real competition and if it comes from the OpenSource world, fantastic.
What do you guys think about the whole thing? Should we start a gnucash-tester list? If we were to start a gnucash-tester mailing list, how would it help and what would the objectives be? If we did start the list, what recruiting process would we use? How would we best use the list to the benefit of all? What part would the -tester list play in the quality assurance process? When should the -tester group be engaged? Should the -tester group be responsible for determining "releasability" status? Am I totally off-base?
On Tue, 2003-03-04 at 19:21, Chris Lyttle wrote:
On Tue, 2003-03-04 at 12:49, Kevin Benton wrote: > How about posting the changes (1.8.1 vs 1.8.2) here so we all know what > to look for before giving our thumbs up or down? > > Kevin Benton > > On Tue, 2003-03-04 at 12:56, James A. Treacy wrote: > > > On Mon, Mar 03, 2003 at 09:29:03PM -0800, Chris Lyttle wrote: > > > > > > I've put a release candidate in > > > http://www.gnucash.org/pub/gnucash/sources/unstable/release-candidate/gnucash-1.8.1.5.tar.gz > > > > > > Packagers please try it out and feedback any problems. If this goes well > > > I'll release a tarball friday for you to package against for a sunday > > > release of 1.8.2. > > > > Compiled and ran on Debian unstable on the first try. > This is a candidate for packagers to test for the sunday release, not a general release. This is why there is no changelog posted. If you want to package for a specific distro/platform release then you should know enough about building from source to find the changelog as part of your process. The general release sunday will have details of the changes. Chris
|
-- Kevin Benton <[EMAIL PROTECTED]> |
<<attachment: smiley-3.png>>
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
