Note I am not proposing changes to how we do QA. We already have "pretty
good" automated tests (the "mtest") and while we could certainly use more
of them, I'm not suggesting spending effort on that right now. No matter
how good your QA is, regressions happen. The question is, how do you
respond to them.
I don't know the answers to Geoff's questions, but those are exactly the
sorts of questions I think we *need* to deal with.
Marc
On Wed, May 24, 2017 at 1:19 PM Geoff Lehr <[email protected]> wrote:
> I'd certainly like to see more frequent releases myself, so I don't have
> to maintain a custom build on my own machine.
>
> To that end (and forgive me for my ignorance on these items, I'm largely a
> user so I haven't delved into the musescore processes):
>
> - What all goes into packaging a release?
> - What isn't automated that can be?
> - Who could/would do that automation?
> - What remains that can't be automated, and why can't it be automated?
> - Is lasconic the only one who can do the packaging / releasing?
> - If so, why? (e.g. only lasconic has the signing keys, etc)
> - If not, what non-automatable parts can be distributed?
> - Is the issue the QA, as Sideways Skullfinger suggests?
> - Is there a pre-release user group that could be leveraged to
> report issues?
> - If so, how do we go about getting them new builds automatically?
>
> Thanks,
>
> Geoff
>
> On Wed, May 24, 2017 at 10:48 AM, Marc Sabatella <[email protected]>
> 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
>
------------------------------------------------------------------------------
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
