Dear all,

I’d like to put to a vote here a proposal for reorganising the Csound Github project to
make it easier for development and collaboration.

The background to this is that the state of the main Csound library repo has become somewhat
unwieldy and bloated. This is a legacy of the way we used to organise the project historically,
first in a single tree under John’s curation, then in the CVS repo, which was also a single tree.
Moving to git helped things, but we mainly continued in the old mode of operation by
piling stuff in the single tree, even after moving to github and its mulitple repository
support.

It is true that some new projects in areas like documentation and help were created
in separate repos, but we continued mostly to put things into one tree, mostly one build,
and as things grew, we are in a impossible state.

So here is my proposal. We move a number of subsidiary projects out of the main
repo into separate (our group repos). In the csound.git repo, we keep mostly the
main library for all platforms, the interfaces library, the CLI frontend and debugger, the opcodes,
and associated test routines. We move out everything else.

This means that, in the first instance, following would go to separate repos

Csound6~
Csound~
csladspa
CsoundAC
CsoundVST
CS6Editor
winsound
nwjs
icsound
beats
Csound Android App

It does not mean we have to have a separate repo for each, but some bigger
projects might do.

Additionally, we move the installer scripts to a separate repo and re-work the scripts
to pull from the main Csound and other relevant places. In the repos, we will
rework the CMake scripts to pull from csound.git and build.

This would have the advantage of streamlining the library build and testing, help us to
focus on projects separately, and generally tidy up the process. I think this is
ultimately a requirement for us to start proper development of Csound 7.

Alongside this, we want to simplify the mechanism for third-party
components to be used in Csound without having to be maintained in the
project.

So I would like to propose this for a vote. If we make the decision, then we
can spend some time re-arranging things and testing the builds, then do
a final 6.11 release using the new mechanisms, which would be the final
non-bugfix release of 6.x.

Please vote on your preference: (a) changes (b) keep the status quo.

best

Victor

Dear all,

I’d like to put to a vote here a proposal for reorganising the Csound Github project to
make it easier for development and collaboration.

The background to this is that the state of the main Csound library repo has become somewhat
unwieldy and bloated. This is a legacy of the way we used to organise the project historically,
first in a single tree under John’s curation, then in the CVS repo, which was also a single tree.
Moving to git helped things, but we mainly continued in the old mode of operation by
piling stuff in the single tree, even after moving to github and its mulitple repository
support.

It is true that some new projects in areas like documentation and help were created
in separate repos, but we continued mostly to put things into one tree, mostly one build,
and as things grew, we are in a impossible state.

So here is my proposal. We move a number of subsidiary projects out of the main
repo into separate (our group repos). In the csound.git repo, we keep mostly the
main library for all platforms, the interfaces library, the CLI frontend and debugger, the opcodes,
and associated test routines. We move out everything else.

This means that, in the first instance, following would go to separate repos

Csound6~
Csound~
csladspa
CsoundAC
CsoundVST
CS6Editor
winsound
nwjs
icsound
beats
Csound Android App

It does not mean we have to have a separate repo for each, but some bigger
projects might do.

Additionally, we move the installer scripts to a separate repo and re-work the scripts
to pull from the main Csound and other relevant places. In the repos, we will
rework the CMake scripts to pull from csound.git and build.

This would have the advantage of streamlining the library build and testing, help us to
focus on projects separately, and generally tidy up the process. I think this is
ultimately a requirement for us to start proper development of Csound 7.

Alongside this, we want to simplify the mechanism for third-party
components to be used in Csound without having to be maintained in the
project.

So I would like to propose this for a vote. If we make the decision, then we
can spend some time re-arranging things and testing the builds, then do
a final 6.11 release using the new mechanisms, which would be the final
non-bugfix release of 6.x.

Please vote on your preference: (a) changes (b) keep the status quo.

best

Victor

I vote for the (a) option.

François

2018-01-17 10:23 GMT+01:00 Victor Lazzarini <Victor.Lazzarini@mu.ie>:

Dear all,

I’d like to put to a vote here a proposal for reorganising the Csound Github project to
make it easier for development and collaboration.

The background to this is that the state of the main Csound library repo has become somewhat
unwieldy and bloated. This is a legacy of the way we used to organise the project historically,
first in a single tree under John’s curation, then in the CVS repo, which was also a single tree.
Moving to git helped things, but we mainly continued in the old mode of operation by
piling stuff in the single tree, even after moving to github and its mulitple repository
support.

It is true that some new projects in areas like documentation and help were created
in separate repos, but we continued mostly to put things into one tree, mostly one build,
and as things grew, we are in a impossible state.

So here is my proposal. We move a number of subsidiary projects out of the main
repo into separate (our group repos). In the csound.git repo, we keep mostly the
main library for all platforms, the interfaces library, the CLI frontend and debugger, the opcodes,
and associated test routines. We move out everything else.

This means that, in the first instance, following would go to separate repos

Csound6~
Csound~
csladspa
CsoundAC
CsoundVST
CS6Editor
winsound
nwjs
icsound
beats
Csound Android App

It does not mean we have to have a separate repo for each, but some bigger
projects might do.

Additionally, we move the installer scripts to a separate repo and re-work the scripts
to pull from the main Csound and other relevant places. In the repos, we will
rework the CMake scripts to pull from csound.git and build.

This would have the advantage of streamlining the library build and testing, help us to
focus on projects separately, and generally tidy up the process. I think this is
ultimately a requirement for us to start proper development of Csound 7.

Alongside this, we want to simplify the mechanism for third-party
components to be used in Csound without having to be maintained in the
project.

So I would like to propose this for a vote. If we make the decision, then we
can spend some time re-arranging things and testing the builds, then do
a final 6.11 release using the new mechanisms, which would be the final
non-bugfix release of 6.x.

Please vote on your preference: (a) changes (b) keep the status quo.

best

Victor

I would have thought that the best solution would be for the projects to pull from the main Csound repo
in their build scripts (e.g. CMake). That way it is possible to keep them in sync more closely. The exact
mechanism can be discussed and we may look to other projects for models.

I don’t think, that in principle, CsoundQT and Cabbage necessarily need to be moved under the
Csound project; in fact, it might good to encourage more third-party projects using the library.

In terms of visibility, some projects that are under Csound might even benefit to be moved into
their own github project, as they can then have their own web resources, independent releases
etc. It may help their promotion and adoption, and I would feel that is something to be considered
by their main developers/contributors.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

> On 17 Jan 2018, at 10:12, Michael Gogins <michael.gogins@gmail.com> wrote:
>
> I think (a) is a good idea.
>
> I don't think this will save work for us as a team, quite the contrary at least in the short term, but I think some separation of concerns would definitely be helpful in the longer term.
>
> Would Csound be used in these other projects as a Git submodule? Or just as an installed library? If not what mechanism would be used to integrate things?
>
> Would CsoundQt or Cabbage or other projects be brought into the Csound group?
>
> Regards,
> Mike
>
>
> On Jan 17, 2018 4:37 AM, "Francois PINOT" <fggpinot@gmail.com> wrote:
> I vote for the (a) option.
>
> François
>
> 2018-01-17 10:23 GMT+01:00 Victor Lazzarini <Victor.Lazzarini@mu.ie>:
> Dear all,
>
> I’d like to put to a vote here a proposal for reorganising the Csound Github project to
> make it easier for development and collaboration.
>
> The background to this is that the state of the main Csound library repo has become somewhat
> unwieldy and bloated. This is a legacy of the way we used to organise the project historically,
> first in a single tree under John’s curation, then in the CVS repo, which was also a single tree.
> Moving to git helped things, but we mainly continued in the old mode of operation by
> piling stuff in the single tree, even after moving to github and its mulitple repository
> support.
>
> It is true that some new projects in areas like documentation and help were created
> in separate repos, but we continued mostly to put things into one tree, mostly one build,
> and as things grew, we are in a impossible state.
>
> So here is my proposal. We move a number of subsidiary projects out of the main
> repo into separate (our group repos). In the csound.git repo, we keep mostly the
> main library for all platforms, the interfaces library, the CLI frontend and debugger, the opcodes,
> and associated test routines. We move out everything else.
>
> This means that, in the first instance, following would go to separate repos
>
> Csound6~
> Csound~
> csladspa
> CsoundAC
> CsoundVST
> CS6Editor
> winsound
> nwjs
> icsound
> beats
> Csound Android App
>
> It does not mean we have to have a separate repo for each, but some bigger
> projects might do.
>
> Additionally, we move the installer scripts to a separate repo and re-work the scripts
> to pull from the main Csound and other relevant places. In the repos, we will
> rework the CMake scripts to pull from csound.git and build.
>
> This would have the advantage of streamlining the library build and testing, help us to
> focus on projects separately, and generally tidy up the process. I think this is
> ultimately a requirement for us to start proper development of Csound 7.
>
> Alongside this, we want to simplify the mechanism for third-party
> components to be used in Csound without having to be maintained in the
> project.
>
> So I would like to propose this for a vote. If we make the decision, then we
> can spend some time re-arranging things and testing the builds, then do
> a final 6.11 release using the new mechanisms, which would be the final
> non-bugfix release of 6.x.
>
> Please vote on your preference: (a) changes (b) keep the status quo.
>
> best
>
> Victor
>
>
>

+1 (a)

On Wed, Jan 17, 2018, 06:45 Rory Walsh <rorywalsh@ear.ie> wrote:

I think (a) sounds good. 

On 17 Jan 2018 11:03 a.m., "Victor Lazzarini" <Victor.Lazzarini@mu.ie> wrote:

I would have thought that the best solution would be for the projects to pull from the main Csound repo
in their build scripts (e.g. CMake). That way it is possible to keep them in sync more closely. The exact
mechanism can be discussed and we may look to other projects for models.

I don’t think, that in principle, CsoundQT and Cabbage necessarily need to be moved under the
Csound project; in fact, it might good to encourage more third-party projects using the library.

In terms of visibility, some projects that are under Csound might even benefit to be moved into
their own github project, as they can then have their own web resources, independent releases
etc. It may help their promotion and adoption, and I would feel that is something to be considered
by their main developers/contributors.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

> On 17 Jan 2018, at 10:12, Michael Gogins <michael.gogins@gmail.com> wrote:
>
> I think (a) is a good idea.
>
> I don't think this will save work for us as a team, quite the contrary at least in the short term, but I think some separation of concerns would definitely be helpful in the longer term.
>
> Would Csound be used in these other projects as a Git submodule? Or just as an installed library? If not what mechanism would be used to integrate things?
>
> Would CsoundQt or Cabbage or other projects be brought into the Csound group?
>
> Regards,
> Mike
>
>
> On Jan 17, 2018 4:37 AM, "Francois PINOT" <fggpinot@gmail.com> wrote:
> I vote for the (a) option.
>
> François
>
> 2018-01-17 10:23 GMT+01:00 Victor Lazzarini <Victor.Lazzarini@mu.ie>:
> Dear all,
>
> I’d like to put to a vote here a proposal for reorganising the Csound Github project to
> make it easier for development and collaboration.
>
> The background to this is that the state of the main Csound library repo has become somewhat
> unwieldy and bloated. This is a legacy of the way we used to organise the project historically,
> first in a single tree under John’s curation, then in the CVS repo, which was also a single tree.
> Moving to git helped things, but we mainly continued in the old mode of operation by
> piling stuff in the single tree, even after moving to github and its mulitple repository
> support.
>
> It is true that some new projects in areas like documentation and help were created
> in separate repos, but we continued mostly to put things into one tree, mostly one build,
> and as things grew, we are in a impossible state.
>
> So here is my proposal. We move a number of subsidiary projects out of the main
> repo into separate (our group repos). In the csound.git repo, we keep mostly the
> main library for all platforms, the interfaces library, the CLI frontend and debugger, the opcodes,
> and associated test routines. We move out everything else.
>
> This means that, in the first instance, following would go to separate repos
>
> Csound6~
> Csound~
> csladspa
> CsoundAC
> CsoundVST
> CS6Editor
> winsound
> nwjs
> icsound
> beats
> Csound Android App
>
> It does not mean we have to have a separate repo for each, but some bigger
> projects might do.
>
> Additionally, we move the installer scripts to a separate repo and re-work the scripts
> to pull from the main Csound and other relevant places. In the repos, we will
> rework the CMake scripts to pull from csound.git and build.
>
> This would have the advantage of streamlining the library build and testing, help us to
> focus on projects separately, and generally tidy up the process. I think this is
> ultimately a requirement for us to start proper development of Csound 7.
>
> Alongside this, we want to simplify the mechanism for third-party
> components to be used in Csound without having to be maintained in the
> project.
>
> So I would like to propose this for a vote. If we make the decision, then we
> can spend some time re-arranging things and testing the builds, then do
> a final 6.11 release using the new mechanisms, which would be the final
> non-bugfix release of 6.x.
>
> Please vote on your preference: (a) changes (b) keep the status quo.
>
> best
>
> Victor
>
>
>