Dev meeting minutes

Development
#1

Hey all, in the interest of more transparency and dialogue between devs and users I’m starting this thread to post minutes from sc-dev meetings. They currently happen every two weeks. Feel free to reply here or start a new thread if there is a topic that interests you.

Note that minutes for all our meetings are kept on github at https://github.com/supercollider/supercollider/wiki/Dev-Team-Meeting-Minutes

1 Like
#2

2020-04-12

People present: Nathan H, Brian H, Patrick D, Geoffrey M, James S, Gianluca E, Josh P

Welcoming Gianluca!

What people are up to

  • Geoffrey: looking at autoindent in IDE, waiting for review on #4797
  • James: reviews, working on implementing spelling correction suggestions in sclang parser
  • Nathan: working on other projects
  • Patrick: refactoring TestBuffer to break out server-requiring tests
  • Josh: managing releases
  • Brian: reviewing, beginning to implement RFC #1

3.11.1

  • discussed Brian’s cherry-pick PR
  • need to merge in scel update for support on ubuntu
  • decided to postpone outstanding issues (#4544, #4826)
  • decided to release ASAP

sc3-plugins

  • discussed merging Scott C’s PR and doing a release
  • Josh P said he thinks we should merge it and include in 3.11, general agreement

Other PRs and issues

  • Patrick asked about best practice quitting servers in unit testing
1 Like
#3

2020-05-10

People present: Brian H, Marcin P, Luke N, James S, Nathan H, Patrick D, Gianluca E, Tejaswi P

Luke N talked a bit about Scintillator (https://github.com/ScintillatorSynth/Scintillator)

Brian gave a short overview of what things have been merged in recently

Gianluca discussed his help browser PR (#4883) and associated RFC (#9)

Discussed issues around SuperCollider versioning and standalones

Some points of discussion:

  • ease of learning - interactive learning environment
  • interoperability with other technologies (web, etc, LSP?)
  • standalones - for performers
  • multiple versions of supercollider
    • dev work
    • possible, but very difficult currently
    • backward compatibility
    • run ‘from a USB stick’
  • app bundle design
  • server/IDE/language search paths
1 Like
#4

2020-05-24

Members present: Brian H, Marcin P, Luke N, James S, Patrick D, Gianluca E, Tejaswi P, Josh P, Geoffrey M, Julian R

Release status

  • Josh P has had some reports of unsigned sc3-plugins not working with 3.11 on macOS 10.15
    • hasn’t been able to reproduce. thinks that everything is in order, but not sure.
    • Marcin offered to test

Release process scripting

  • Brian brought up the idea of automating / scripting the release process
    • James S, Josh P, Brian H, Marcin P decided to form a working group for this

vcpkg - https://github.com/supercollider/supercollider/issues/4928

  • James S has used it before and offered some advice
    • one issue is that packages need to be built from source, not a good way to provide Qt
    • generally positive impression
  • Marcin P tried it, ran into an issue with powershell
    • for portaudio, issue with asio sdk
  • James S mentioned asio sdk is in vcpkg, and seems like it provides CMake integration
  • Brian noted ExternalProject in CMake is also an option for managing external dependencies
  • Luke N and Marcin P said vcpkg support for CI first might be a good way to test it out, and then recommend it if it works
    • James S said he would look into that

portaudio vendoring - https://github.com/supercollider/supercollider/issues/4928

  • Marcin P did work to shift over to fresh, non-sc-org portaudio
  • Brian suggested using ExternalProject in CMake to get around
  • Discussed tradeoffs of vcpkg vs ExternalProject
  • Decided to do more research and revisit

issue management - https://github.com/supercollider/supercollider/issues/4940

  • Josh P wants to reset everything and start from scratch
  • Luke N also likes this idea, but said we need to have a policy to avoid it happening again
  • Josh P said most projects don’t actually run as long as SC. issue trackers work good for shorter term projects, but maybe not for this duration
    • fresh start could give some focus
  • James S explained his ideas regarding stale issues and automation
  • Julian R said a bot would add a kind of neutrality/fairness to it, but is concerned that closing issues will hide valuable information
  • James S suggested updating issue template or other obvious place to note that you may want to search closed issues
  • Everyone agreed messaging around closing issues is important
  • Discussed a gradual approach to transitioning between current process and more controlled approach
  • There was a proposition to have a two-step approach where a bot would comment every issue that’s been stalled for more than X months, which would explain the triage process. Then, after some other time to be determined, the issue would be closed
  • Someone proposed to start with proposition some texts for these messages.

Other topics and PRs:

1 Like
#5

Thanks for posting!!