Release and packaging process for SuperCollider

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

Release and packaging process for SuperCollider

Nathan Ho
Hi list,

As 3.9 approaches, I think it's time to take a look at what our release
and packaging process is. It seems that some of the packaging details
have been forgotten in the natural course of people joining and retiring
from the project. Let's make an effort to document the process ahead of
time so we know exactly what we're doing going into the next release.

I'd welcome any contributions, but I also have some specific questions:

- How do we package binaries for Linux? (3.7 and 3.8 didn't have them.)
- Most Linux repositories have fallen behind. How do we update them?
- GitHub's source code packaging doesn't include submodules. How should
we deal with that?

About a month ago I jotted down the process of managing a release (i.e.
my duties):
https://github.com/supercollider/supercollider/wiki/git-workflow


Nathan

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Release and packaging process for SuperCollider

Rainer Schuetz
> About a month ago I jotted down the process of managing a release (i.e. my duties): https://github.com/supercollider/supercollider/wiki/git-workflow

Nice! I have two comments and an addendum ;):

- merging the release branch into master turned out to be problematic. These can be large merges where git often enough makes choices that turn out to be wrong. High risk of introducing regressions. And it is also not trivial to keep release branch specific commits out of this merge. The principle that fits sc better: move commits from master to release branch by cherry picking. Release branch specific fixes should of course go into the release branch only

- committing to the release branch is reserved to the release manager (as an agreement, no buttons required). This makes sure that s/he doesn't loose the overview. S/he also has the last word in controversial cases.

Another crucial point is to split off the release branch as late as possible. Here pessimism rather than optimism is the right attitude. Beta-phases should be as short as possible, not more than a month, and there should not be more than one or two, otherwise attention between master and release branch will be divided too long. In effect the release branch should only be split off once we think we are ready for release. Then feedback from public exposure of the beta will hopefully produce a few error-reports that can be fixed before the actual release.

You say that master is unstable, but I don't see that SC has the woman-power to keep an unstable and stable branch yet. Master always needs to remain as stable as we manage to, features that could reduce functionality/stability need to remain in separate development branches until they can be considered "stable" or complete. The reason for this is that we have too often in the past been hit by provisional contributions to master that then were never - or only with an intolerable delay - fixed by the original contributor. The responsibility for the stability of new contributions lies strictly with the original contributor. Also, as has been the case for years and without there being a sign that this might change in the closer future: the actual use of the master branch is the only real world testing new contributions get before a release. If master cannot be used, this crucial testing will fall away. Therefore it is also not good if large commits are done shortly before a release.

Best
.r.



_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Release and packaging process for SuperCollider

Nathan Ho
On 2017-03-04 16:40, Rainer Schuetz wrote:

>> About a month ago I jotted down the process of managing a release
>> (i.e. my duties):
>> https://github.com/supercollider/supercollider/wiki/git-workflow
>
> Nice! I have two comments and an addendum ;):
>
> - merging the release branch into master turned out to be problematic.
> These can be large merges where git often enough makes choices that
> turn out to be wrong. High risk of introducing regressions. And it is
> also not trivial to keep release branch specific commits out of this
> merge. The principle that fits sc better: move commits from master to
> release branch by cherry picking. Release branch specific fixes should
> of course go into the release branch only

Hi Rainer,

Wouldn't cherrypicking cause *more* issues than merging? The
dependencies between commits can be complex. Here is some info on
cherrypicking vs merging: http://stackoverflow.com/a/1241829

I think a better solution would be to merge from release to master
regularly so that conflicts are sorted out proactively, not reactively.
This also addresses your concern about splitting off the release branch
as late as possible. It would merge in release-specific commits, so
SCVersion.txt might be screwed up for a while in master, but I consider
that a small price to pay.

I wish we had better unit test coverage, because we'd have a better idea
of when stuff breaks during risky merges or cherrypicks...

To anyone reading: I'm still waiting for some answers regarding
packaging for Linux, so I'd appreciate if anyone has any information!


Nathan

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Release and packaging process for SuperCollider

Tim Blechmann-2
In reply to this post by Nathan Ho
> - GitHub's source code packaging doesn't include submodules. How
> should we deal with that?

https://github.com/supercollider/supercollider/blob/master/package/package#L42


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Release and packaging process for SuperCollider

bbarros
In reply to this post by Nathan Ho
On 3/4/17 6:11 PM, Nathan Ho wrote:
> - Most Linux repositories have fallen behind. How do we update them?

Arch and Fedora are up-to-date I think, but packaging for all gnu/linux
distros is a lot of work... nobody does it. Debian is always a problem I
think, but now there is also this:

https://snapcraft.io/ - ``Package any app for every Linux desktop,
server, cloud or device, and deliver updates directly.''



_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Release and packaging process for SuperCollider

patrick

Hi,


To clarify with regards to Fedora, there's no SuperCollider package in the official repositories. The CCRMA repos provide SC 3.7.2 + plugins only to Fedora 22-24.


The SC dev team needs someone to maintain the SC package in the Debian repos. I don't think Snaps, Flatpaks, or AppImages are useful in this regard. Members of the community are welcome to create third-party repositories to provide SC packages for their distro of choice.


Cheers,

Patrick 

Reply | Threaded
Open this post in threaded view
|

Re: Release and packaging process for SuperCollider

bbarros
On 4/2/17 3:20 PM, P Dupuis wrote:
>
> To clarify with regards to Fedora, there's no SuperCollider package in
> the official repositories. The CCRMA repos provide SC 3.7.2 + plugins
> only to Fedora 22-24.
>
>

Also 25, check it again. planetccrma is so common that I even forget
it's `unofficial' :-)



_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Release and packaging process for SuperCollider

bbarros
In reply to this post by patrick
On 4/2/17 3:20 PM, P Dupuis wrote:
>
> The SC dev team needs someone to maintain the SC package in the Debian
> repos. I don't think Snaps, Flatpaks, or AppImages are useful in this
> regard. Members of the community are welcome to create third-party
> repositories to provide SC packages for their distro of choice.
>


If I'm not mistaken, cmake can be configured to create Debian and RPM
packages


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Release and packaging process for SuperCollider

patrick
In reply to this post by bbarros
I didn't know 25 was there. I only see up to 24 : http://ccrma.stanford.edu/planetccrma/software/

Is there a SC 3.8 package for Fedora?

Patrick
From: [hidden email] <[hidden email]> on behalf of Bernardo Barros <[hidden email]>
Sent: April 2, 2017 3:41:31 PM
To: [hidden email]
Subject: Re: [sc-dev] Release and packaging process for SuperCollider
 
On 4/2/17 3:20 PM, P Dupuis wrote:
>
> To clarify with regards to Fedora, there's no SuperCollider package in
> the official repositories. The CCRMA repos provide SC 3.7.2 + plugins
> only to Fedora 22-24.
>
>

Also 25, check it again. planetccrma is so common that I even forget
it's `unofficial' :-)



_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Release and packaging process for SuperCollider

bbarros
On 4/2/17 5:07 PM, P Dupuis wrote:
> I didn't know 25 was there. I only see up to 24 :
> http://ccrma.stanford.edu/planetccrma/software/
>
> Is there a SC 3.8 package for Fedora?

Sorry

No, it seems it's still 3.7.2 for Fedora 25.

I think Nando waits a little after major updates, and we never got a
3.8.1, maybe that's the reason?



_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Release and packaging process for SuperCollider

patrick
In reply to this post by bbarros
From what I understand, official Debian packages have to comply with the distro's package policy. It takes some work on the part of the maintainer.

Patrick
From: [hidden email] <[hidden email]> on behalf of Bernardo Barros <[hidden email]>
Sent: April 2, 2017 3:43:43 PM
To: [hidden email]
Subject: Re: [sc-dev] Release and packaging process for SuperCollider
 
On 4/2/17 3:20 PM, P Dupuis wrote:
>
> The SC dev team needs someone to maintain the SC package in the Debian
> repos. I don't think Snaps, Flatpaks, or AppImages are useful in this
> regard. Members of the community are welcome to create third-party
> repositories to provide SC packages for their distro of choice.
>


If I'm not mistaken, cmake can be configured to create Debian and RPM
packages


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Release and packaging process for SuperCollider

patrick
In reply to this post by bbarros
Now that the devs are releasing more often, it must be hard for maintainers to keep an updated SC in their repos. Ccrma should just wait for 3.9 at this point.

I should try and use Ccrma's low-latency kernel some day.

Patrick
From: [hidden email] <[hidden email]> on behalf of Bernardo Barros <[hidden email]>
Sent: April 2, 2017 5:32:08 PM
To: [hidden email]
Subject: Re: [sc-dev] Release and packaging process for SuperCollider
 
On 4/2/17 5:07 PM, P Dupuis wrote:
> I didn't know 25 was there. I only see up to 24 :
> http://ccrma.stanford.edu/planetccrma/software/
>
> Is there a SC 3.8 package for Fedora?

Sorry

No, it seems it's still 3.7.2 for Fedora 25.

I think Nando waits a little after major updates, and we never got a
3.8.1, maybe that's the reason?



_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/