Releases and packaging

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Releases and packaging

Marc Sabatella
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.
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

sideways
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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

Geoff Lehr
In reply to this post by Marc Sabatella
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

byan61
This sounds like QA issue.
I am relatively new to MuseScore development and releasing process.

Normally software releases go through following stages:
Alpha (internal testing)
Beta (external/user testing)
Final release

All obvious regressions should have been discovered in the Alpha and Beta releases, and fixed before the final release is made.
I do not see any Beta release announcements for MuseScore 2.1.  Please correct me if I am wrong.
We should have Beta release(s) about 3-4 weeks before making the final release.
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

Marc Sabatella
In reply to this post by Geoff Lehr
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

lasconic
Administrator
In reply to this post by Marc Sabatella
Hi,

First, let me say that I agree that it would be good to have a release to fix the issues you listed and I do have more or less the same list. We can discuss this but probably in another thread.

Then, why we don't release more often. This is a multifaceted issue.

1. All the time we (as a community) spend making bug fix release, or point release, including the time we spend fixing the bugs, we don't spend it developing the next version of MuseScore. As a personal illustration, in the past ~6 months, I dedicated most of my time on MuseScore on 2.1, master has been left aside to a point that I just spent today fixing the nightlies on Windows, on Mac and AppImage x86_64. Werner has been mainly alone working on master.

2. Assuming all bugs are fixed, and tested (meaning nightly builds are being created), translations are done (that's a big assumption) actually releasing a MuseScore version currently takes around 20 full days but the time is not spent where you might think. 

a. Linux and Mac builds should be built by travis when tagging. That's fast if the signing certificate are still valid on Mac (it was not the case for 2.1)
b. Windows build is not automated at all. I build the MSI on my computer (nightlies are built on a server I administer). We can improve on this point https://musescore.org/en/node/106071
c. For 2.1, we also made a release on the Windows Store but a.b.c. (pure packaging) can be done in < 2 days. It could be made faster, if we would release more often since we would detect automation issues more often.

d. Community supported builds: Portable apps, 64bit, noSSE, Linux distributions (this is still ongoing for MuseScore 2.1)

e. Updating MuseScore website, the update checkers xml files (Thomas does that), support users with disappearing files (...), no sound on update etc...

f. Communicating the release. Draft the release notes, the announcement, a newsletter, update the different online directories (kdeapp, macupdate etc...). For MuseScore 2.1, we sent the newsletter yesterday, partly because it needs to be written, partly because we want to make sure that the release is not completely broken, partly because it's better if we have Portable, x64 version (PPA) if we don't have to have dozens of support emails.

g. Updating all the other projects that depends on MuseScore itself : MuseScore apps (released yesterday on android and today on iOS) & MuseScore.com backends.

3. Testing. If we have this discussion, it's because there are still annoying bugs in MuseScore 2.1. Still, we have tests (mtest + vtest) but never enough... The tuplet corruption should have been detected by tests. Then, we have nightlies. I spent quite some time making sure that we do have nightly builds being created in order to be tested. Unfortunately we don't have enough "expert" eyeballs using these nightly builds. We should probably make the status of the nightlies clearer, meaning they are documented as extremely unstable which was not the case for nightlies just before 2.1. Also, we should have an automated way to update nightlies.

Ok. That was lot of text. I will read the other answers now :)

lasconic



2017-05-24 18:48 GMT+02:00 Marc Sabatella <[hidden email]>:
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

Jojo-Schmitz
In reply to this post by byan61
Alpha -> we have nightly builds
Beta -> we had an RC

-----Original Message-----
From: byan61 [mailto:[hidden email]]
Sent: Wednesday, May 24, 2017 10:03 PM
To: [hidden email]
Subject: Re: [Mscore-developer] Releases and packaging

This sounds like QA issue.
I am relatively new to MuseScore development and releasing process.

Normally software releases go through following stages:
Alpha (internal testing)
Beta (external/user testing)
Final release

All obvious regressions should have been discovered in the Alpha and Beta
releases, and fixed before the final release is made.
I do not see any Beta release announcements for MuseScore 2.1.  Please
correct me if I am wrong.
We should have Beta release(s) about 3-4 weeks before making the final
release.




--
View this message in context:
http://dev-list.musescore.org/Releases-and-packaging-tp7580247p7580250.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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

Marc Sabatella
In reply to this post by byan61
I wonder if maybe there couldn't be a more streamlined process for purely bug fix releases?  Not every release necessarily requires a lengthy announcement or a newsletter, maybe not all require updating apps, not all have translation implications, etc.

Because absolutely I agree we shouldn't divert more attention from 3.0 development than necessary.  I think that given the magnitude of the changes coming for 3.0, having 2.1 made sense even though it was a pretty big release.  I would hope to not have another anything like that before 3.0, so if 2.1 took 20 days, maybe we see how we can make 2.1.x releases in under a week, with more people helping out so that it isn't a full time commitment for anyone.

Ideally it would be easier to have more regular bug fix updates.  It's actually quite encouraging that the half dozen or so issues I mentioned are essentially *all* that has been reported in the several weeks since the release.  So if we did a 2.1.1 in June, I would doubt we'd need a 2.1.2 this year.  Depending on the status of 3.0, maybe eventually we hit the 2.0.3 bugs that didn't quite make the list for 2.1, but it's an easier call to make if we can find a way to do it without taking as much effort as we spend now - or at least, if we can better distribute the work.

At the very least, what if someone else were to own the coordinating community builds for Linux, portable apps, etc?

On Wed, May 24, 2017 at 2:23 PM byan61 <[hidden email]> wrote:
This sounds like QA issue.
I am relatively new to MuseScore development and releasing process.

Normally software releases go through following stages:
Alpha (internal testing)
Beta (external/user testing)
Final release

All obvious regressions should have been discovered in the Alpha and Beta
releases, and fixed before the final release is made.
I do not see any Beta release announcements for MuseScore 2.1.  Please
correct me if I am wrong.
We should have Beta release(s) about 3-4 weeks before making the final
release.




--
View this message in context: http://dev-list.musescore.org/Releases-and-packaging-tp7580247p7580250.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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

lasconic
Administrator
So we are not talking about improving our process here. We are talking about a 2.1.1.
Let's not overthink it. We have a 2.2 branch, I'm ready to merge any fix in this branch. We just need to make sure we have nightlies and testers.

lasconic

2017-05-24 22:45 GMT+02:00 Marc Sabatella <[hidden email]>:
I wonder if maybe there couldn't be a more streamlined process for purely bug fix releases?  Not every release necessarily requires a lengthy announcement or a newsletter, maybe not all require updating apps, not all have translation implications, etc.

Because absolutely I agree we shouldn't divert more attention from 3.0 development than necessary.  I think that given the magnitude of the changes coming for 3.0, having 2.1 made sense even though it was a pretty big release.  I would hope to not have another anything like that before 3.0, so if 2.1 took 20 days, maybe we see how we can make 2.1.x releases in under a week, with more people helping out so that it isn't a full time commitment for anyone.

Ideally it would be easier to have more regular bug fix updates.  It's actually quite encouraging that the half dozen or so issues I mentioned are essentially *all* that has been reported in the several weeks since the release.  So if we did a 2.1.1 in June, I would doubt we'd need a 2.1.2 this year.  Depending on the status of 3.0, maybe eventually we hit the 2.0.3 bugs that didn't quite make the list for 2.1, but it's an easier call to make if we can find a way to do it without taking as much effort as we spend now - or at least, if we can better distribute the work.

At the very least, what if someone else were to own the coordinating community builds for Linux, portable apps, etc?

On Wed, May 24, 2017 at 2:23 PM byan61 <[hidden email]> wrote:
This sounds like QA issue.
I am relatively new to MuseScore development and releasing process.

Normally software releases go through following stages:
Alpha (internal testing)
Beta (external/user testing)
Final release

All obvious regressions should have been discovered in the Alpha and Beta
releases, and fixed before the final release is made.
I do not see any Beta release announcements for MuseScore 2.1.  Please
correct me if I am wrong.
We should have Beta release(s) about 3-4 weeks before making the final
release.




--
View this message in context: http://dev-list.musescore.org/Releases-and-packaging-tp7580247p7580250.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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

Marc Sabatella
I guess my reason for talking about improving our process is to make it so if/when the time comes to consider a 2.1.2 as well, we don't put it off because our process is still too cumbersome.  But I'm OK with not crossing that bridge until we get to it.

I will see about submitting PR's on 2.2 for the issues I feel comfortable fixing myself.

On Wed, May 24, 2017 at 3:16 PM Lasconic <[hidden email]> wrote:
So we are not talking about improving our process here. We are talking about a 2.1.1.
Let's not overthink it. We have a 2.2 branch, I'm ready to merge any fix in this branch. We just need to make sure we have nightlies and testers.

lasconic

2017-05-24 22:45 GMT+02:00 Marc Sabatella <[hidden email]>:
I wonder if maybe there couldn't be a more streamlined process for purely bug fix releases?  Not every release necessarily requires a lengthy announcement or a newsletter, maybe not all require updating apps, not all have translation implications, etc.

Because absolutely I agree we shouldn't divert more attention from 3.0 development than necessary.  I think that given the magnitude of the changes coming for 3.0, having 2.1 made sense even though it was a pretty big release.  I would hope to not have another anything like that before 3.0, so if 2.1 took 20 days, maybe we see how we can make 2.1.x releases in under a week, with more people helping out so that it isn't a full time commitment for anyone.

Ideally it would be easier to have more regular bug fix updates.  It's actually quite encouraging that the half dozen or so issues I mentioned are essentially *all* that has been reported in the several weeks since the release.  So if we did a 2.1.1 in June, I would doubt we'd need a 2.1.2 this year.  Depending on the status of 3.0, maybe eventually we hit the 2.0.3 bugs that didn't quite make the list for 2.1, but it's an easier call to make if we can find a way to do it without taking as much effort as we spend now - or at least, if we can better distribute the work.

At the very least, what if someone else were to own the coordinating community builds for Linux, portable apps, etc?

On Wed, May 24, 2017 at 2:23 PM byan61 <[hidden email]> wrote:
This sounds like QA issue.
I am relatively new to MuseScore development and releasing process.

Normally software releases go through following stages:
Alpha (internal testing)
Beta (external/user testing)
Final release

All obvious regressions should have been discovered in the Alpha and Beta
releases, and fixed before the final release is made.
I do not see any Beta release announcements for MuseScore 2.1.  Please
correct me if I am wrong.
We should have Beta release(s) about 3-4 weeks before making the final
release.




--
View this message in context: http://dev-list.musescore.org/Releases-and-packaging-tp7580247p7580250.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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

lasconic
Administrator
The majority of the issues you listed applies to master too. It would then make sense to fix them in master first. No?

lasconic

2017-05-24 23:37 GMT+02:00 Marc Sabatella <[hidden email]>:
I guess my reason for talking about improving our process is to make it so if/when the time comes to consider a 2.1.2 as well, we don't put it off because our process is still too cumbersome.  But I'm OK with not crossing that bridge until we get to it.

I will see about submitting PR's on 2.2 for the issues I feel comfortable fixing myself.

On Wed, May 24, 2017 at 3:16 PM Lasconic <[hidden email]> wrote:
So we are not talking about improving our process here. We are talking about a 2.1.1.
Let's not overthink it. We have a 2.2 branch, I'm ready to merge any fix in this branch. We just need to make sure we have nightlies and testers.

lasconic

2017-05-24 22:45 GMT+02:00 Marc Sabatella <[hidden email]>:
I wonder if maybe there couldn't be a more streamlined process for purely bug fix releases?  Not every release necessarily requires a lengthy announcement or a newsletter, maybe not all require updating apps, not all have translation implications, etc.

Because absolutely I agree we shouldn't divert more attention from 3.0 development than necessary.  I think that given the magnitude of the changes coming for 3.0, having 2.1 made sense even though it was a pretty big release.  I would hope to not have another anything like that before 3.0, so if 2.1 took 20 days, maybe we see how we can make 2.1.x releases in under a week, with more people helping out so that it isn't a full time commitment for anyone.

Ideally it would be easier to have more regular bug fix updates.  It's actually quite encouraging that the half dozen or so issues I mentioned are essentially *all* that has been reported in the several weeks since the release.  So if we did a 2.1.1 in June, I would doubt we'd need a 2.1.2 this year.  Depending on the status of 3.0, maybe eventually we hit the 2.0.3 bugs that didn't quite make the list for 2.1, but it's an easier call to make if we can find a way to do it without taking as much effort as we spend now - or at least, if we can better distribute the work.

At the very least, what if someone else were to own the coordinating community builds for Linux, portable apps, etc?

On Wed, May 24, 2017 at 2:23 PM byan61 <[hidden email]> wrote:
This sounds like QA issue.
I am relatively new to MuseScore development and releasing process.

Normally software releases go through following stages:
Alpha (internal testing)
Beta (external/user testing)
Final release

All obvious regressions should have been discovered in the Alpha and Beta
releases, and fixed before the final release is made.
I do not see any Beta release announcements for MuseScore 2.1.  Please
correct me if I am wrong.
We should have Beta release(s) about 3-4 weeks before making the final
release.




--
View this message in context: http://dev-list.musescore.org/Releases-and-packaging-tp7580247p7580250.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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

Marc Sabatella
True.  Only the tuplet issue is 2.1-specific as far as I know.  I haven't tried the fix given by https://github.com/musescore/MuseScore/pull/2880 but I'm hoping that merging that and reverting https://github.com/musescore/MuseScore/pull/2861 would do the job.  I need to get a 3.0 build going again, I guess this weekend I'll do that.

Marc

On Wed, May 24, 2017 at 3:48 PM Lasconic <[hidden email]> wrote:
The majority of the issues you listed applies to master too. It would then make sense to fix them in master first. No?

lasconic

2017-05-24 23:37 GMT+02:00 Marc Sabatella <[hidden email]>:
I guess my reason for talking about improving our process is to make it so if/when the time comes to consider a 2.1.2 as well, we don't put it off because our process is still too cumbersome.  But I'm OK with not crossing that bridge until we get to it.

I will see about submitting PR's on 2.2 for the issues I feel comfortable fixing myself.

On Wed, May 24, 2017 at 3:16 PM Lasconic <[hidden email]> wrote:
So we are not talking about improving our process here. We are talking about a 2.1.1.
Let's not overthink it. We have a 2.2 branch, I'm ready to merge any fix in this branch. We just need to make sure we have nightlies and testers.

lasconic

2017-05-24 22:45 GMT+02:00 Marc Sabatella <[hidden email]>:
I wonder if maybe there couldn't be a more streamlined process for purely bug fix releases?  Not every release necessarily requires a lengthy announcement or a newsletter, maybe not all require updating apps, not all have translation implications, etc.

Because absolutely I agree we shouldn't divert more attention from 3.0 development than necessary.  I think that given the magnitude of the changes coming for 3.0, having 2.1 made sense even though it was a pretty big release.  I would hope to not have another anything like that before 3.0, so if 2.1 took 20 days, maybe we see how we can make 2.1.x releases in under a week, with more people helping out so that it isn't a full time commitment for anyone.

Ideally it would be easier to have more regular bug fix updates.  It's actually quite encouraging that the half dozen or so issues I mentioned are essentially *all* that has been reported in the several weeks since the release.  So if we did a 2.1.1 in June, I would doubt we'd need a 2.1.2 this year.  Depending on the status of 3.0, maybe eventually we hit the 2.0.3 bugs that didn't quite make the list for 2.1, but it's an easier call to make if we can find a way to do it without taking as much effort as we spend now - or at least, if we can better distribute the work.

At the very least, what if someone else were to own the coordinating community builds for Linux, portable apps, etc?

On Wed, May 24, 2017 at 2:23 PM byan61 <[hidden email]> wrote:
This sounds like QA issue.
I am relatively new to MuseScore development and releasing process.

Normally software releases go through following stages:
Alpha (internal testing)
Beta (external/user testing)
Final release

All obvious regressions should have been discovered in the Alpha and Beta
releases, and fixed before the final release is made.
I do not see any Beta release announcements for MuseScore 2.1.  Please
correct me if I am wrong.
We should have Beta release(s) about 3-4 weeks before making the final
release.




--
View this message in context: http://dev-list.musescore.org/Releases-and-packaging-tp7580247p7580250.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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Releases and packaging

lasconic
Administrator

2017-05-25 1:39 GMT+02:00 Marc Sabatella <[hidden email]>:
True.  Only the tuplet issue is 2.1-specific as far as I know.  I haven't tried the fix given by https://github.com/musescore/MuseScore/pull/2880 but I'm hoping that merging that and reverting https://github.com/musescore/MuseScore/pull/2861 would do the job.  I need to get a 3.0 build going again, I guess this weekend I'll do that.

Marc

On Wed, May 24, 2017 at 3:48 PM Lasconic <[hidden email]> wrote:
The majority of the issues you listed applies to master too. It would then make sense to fix them in master first. No?

lasconic

2017-05-24 23:37 GMT+02:00 Marc Sabatella <[hidden email]>:
I guess my reason for talking about improving our process is to make it so if/when the time comes to consider a 2.1.2 as well, we don't put it off because our process is still too cumbersome.  But I'm OK with not crossing that bridge until we get to it.

I will see about submitting PR's on 2.2 for the issues I feel comfortable fixing myself.

On Wed, May 24, 2017 at 3:16 PM Lasconic <[hidden email]> wrote:
So we are not talking about improving our process here. We are talking about a 2.1.1.
Let's not overthink it. We have a 2.2 branch, I'm ready to merge any fix in this branch. We just need to make sure we have nightlies and testers.

lasconic

2017-05-24 22:45 GMT+02:00 Marc Sabatella <[hidden email]>:
I wonder if maybe there couldn't be a more streamlined process for purely bug fix releases?  Not every release necessarily requires a lengthy announcement or a newsletter, maybe not all require updating apps, not all have translation implications, etc.

Because absolutely I agree we shouldn't divert more attention from 3.0 development than necessary.  I think that given the magnitude of the changes coming for 3.0, having 2.1 made sense even though it was a pretty big release.  I would hope to not have another anything like that before 3.0, so if 2.1 took 20 days, maybe we see how we can make 2.1.x releases in under a week, with more people helping out so that it isn't a full time commitment for anyone.

Ideally it would be easier to have more regular bug fix updates.  It's actually quite encouraging that the half dozen or so issues I mentioned are essentially *all* that has been reported in the several weeks since the release.  So if we did a 2.1.1 in June, I would doubt we'd need a 2.1.2 this year.  Depending on the status of 3.0, maybe eventually we hit the 2.0.3 bugs that didn't quite make the list for 2.1, but it's an easier call to make if we can find a way to do it without taking as much effort as we spend now - or at least, if we can better distribute the work.

At the very least, what if someone else were to own the coordinating community builds for Linux, portable apps, etc?

On Wed, May 24, 2017 at 2:23 PM byan61 <[hidden email]> wrote:
This sounds like QA issue.
I am relatively new to MuseScore development and releasing process.

Normally software releases go through following stages:
Alpha (internal testing)
Beta (external/user testing)
Final release

All obvious regressions should have been discovered in the Alpha and Beta
releases, and fixed before the final release is made.
I do not see any Beta release announcements for MuseScore 2.1.  Please
correct me if I am wrong.
We should have Beta release(s) about 3-4 weeks before making the final
release.




--
View this message in context: http://dev-list.musescore.org/Releases-and-packaging-tp7580247p7580250.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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer