QA is the most challenging thing to get right for a complex software application. Add the fact that this is open source, and there are no dedicated QA human resources, and you're in for a challenge. The primary "establishment" answer to your question is:
1) Maintain an accurate and complete technical specification of the application, which leads to... 2) Maintain an accurate and complete test matrix for the application, which leads to... 3) Ideally implement and maintain that test matrix in automated testing software 4) Run your test matrix on a regular basis. The MuseScore setup on github.com already has some of this going on. It's a C++ based testing system, I'm not sure what the right terminology is. Someone or some group of people needs to update and augment this test bed to a "complete" level, and then it must be maintained, certainly prior to major releases. It's a lot of work, and a lot of documentation and detail. Without dedicated human resources it requires an even higher level of central organization and management. That's the stock answer to your question, AFAIK. If anyone knows of other ways, please chime in. I hope that helps, though I'm really stating the obvious. It's a good starting point. __ Sideways On 5/24/2017 10:48 AM, Marc Sabatella wrote: > Generally speaking, we don't release bug fix updates as often as some > projects do, and I get the sense that a big reason for this is how much work > is involved in actually producing packages for release. On the assumption > that this is in fact the case, I'm wondering, what can we do to lessen / > share this load? > > I ask because, as is often the case with a relatively big release, there are > a small number of very unfortunate regressions in 2.1 that are being > reported over and over, and I would like to be able to address them. I > believe we understand these issues well enough to be able to fix them > quickly, and as far as I am concerned doing this is worth a certain amount > of pain on our part. I think as the user base of MuseScore grows and the > applications continues to be taken more seriously, we need to be > increasingly conscious of how responsive we are. > > I think we probably all have a sense of what I am talking about, but > specifically, I have in mind: > > - tenor drum silent due to mix up between soundfont and instruments.xml > - loud pops in some sounds due apparently to a fix for a different issue > - inability to enter rests by mouse on drum staves > - corruption on copy/paste (or save/load) of any non-reduced tuplet > - loss of information on "regroup rhythms" (at least, we should preserve > enharmonic spelling) > - maybe add a note to the save online dialog mentioning the dependency on > LAME for custom audio? > > I realize that currently, producing a new release basically comes down to > lasconic doing a whole ton of work mostly on his own, and I greatly > appreciate all he has been doing keeping things running as smoothly as they > have been. But I think it is high time we look at improving this situation. > I'm not saying we should spend a lot of time putting out new releases every > month or whatever, but I do think we need to have a better strategy than we > do right now. > > > > -- > View this message in context: > http://dev-list.musescore.org/Releases-and-packaging-tp7580247.html > Sent from the MuseScore Developer mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Mscore-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mscore-developer ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
