refactorings in minor versions

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

refactorings in minor versions

julian.rohrhuber
It seems to me that we have just stumbled upon a kind of deadlock in our new workflow. The workflow is intended to make it easier to determine which things should be done when.

If I understand correctly, new features are something that should happen only in major releases, like 3.9 to 3.10.

The problem is that when you refactor code properly, you definitely will create new methods. If those methods are banned, because they imply features, we have to postpone refactoring to major releases. Personally, I find this adds a major hurdle: you have to first find a workaround, before you then find a lasting solution. t can even encourage bad coding style. I agree that “proper” features should be retained, but the problem remains.


Here is the last message on github that I wrote:

https://github.com/supercollider/supercollider/pull/3499#issuecomment-364158950

>I don't mean this as an argument for "let's follow rules for the sake of it". I just want some sort of stability and agreement so we can stop splitting hairs. If we never establish any firm rule whatsoever, there's no chance of that.

sure, I'm fine with rules. I've tried to find the rule you are alluding to, but rereading the guidelines, I couldn't find it. It's a lot of stuff, maybe I've overlooked it.

>For example, we have already spend more time here than it would take to just wait until 3.10 and swap out the method.

We need to keep the flow. 3.10 is scheduled for early July, and I wouldn't want to wait so long. But let's move the discussion to the mailing list. (done just now.)



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: refactorings in minor versions

Nathan Ho
On 2018-02-08 09:15, [hidden email] wrote:
> It seems to me that we have just stumbled upon a kind of deadlock in
> our new workflow. The workflow is intended to make it easier to
> determine which things should be done when.
>
> If I understand correctly, new features are something that should
> happen only in major releases, like 3.9 to 3.10.

hi julian,

i haven't been on the project as long as most of you have, but hasn't it
always been the case that 3.x introduces new features and 3.x.x fixes
bugs? it's still my fault that i didn't document this explicitly, but i
was under the impression that this isn't anything new -- we're just
moving way faster than before.

> The problem is that when you refactor code properly, you definitely
> will create new methods. If those methods are banned, because they
> imply features, we have to postpone refactoring to major releases.
> Personally, I find this adds a major hurdle: you have to first find a
> workaround, before you then find a lasting solution. t can even
> encourage bad coding style. I agree that “proper” features should be
> retained, but the problem remains.

i am, in abstract, against refactoring in 3.x.x releases. in patch
releases we should be playing it safe and touching only what we need to
touch. if a bugfix is elaborate enough to require refactoring on the
side, it has a greater risk of breaking, so it is safer to save it for a
3.x. this is dependent on the urgency of the bug.

in this particular case i acquiesce and i'll let the killProcessByID
method through for 3.9.2. it's pretty harmless. i wouldn't be happy if
we let a dozen more small features through.

one option is to speed up the 3.x release cycle to 4 months. i'm
impressed with our productivity so far this year and i don't think
there's much harm in that. for 3.10 i resolve to be much less lenient
about the deadline than i was for 3.9.


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: refactorings in minor versions

brianlheim
> for 3.10 i resolve to be much less lenient about the deadline than i was for 3.9.

Hurrah!

> in this particular case i acquiesce and i'll let the killProcessByID method through for 3.9.2. it's pretty harmless. i wouldn't be happy if we let a dozen more small features through.

Can I ask, for purposes of documentation, what reasoning we could use to make future conversations smoother? The git workflow and guidelines page currently reads:

> The current release branch (like 3.9), to which only bug fixes can be merged. (Features will occasionally be merged into release branches if they are considered critical for that release.)

Maybe we should have a sentence like: "A bug fix may contain a new feature if the feature is minor, and if implementing the fix without this feature would require additional work."

Btw, this also brought to light that the explanations of "patch" and "feature" may not be clear enough. I think the documentation should include a few sentences on that.

-Brian

On Thu, Feb 8, 2018 at 1:34 PM, <[hidden email]> wrote:
On 2018-02-08 09:15, [hidden email] wrote:
It seems to me that we have just stumbled upon a kind of deadlock in
our new workflow. The workflow is intended to make it easier to
determine which things should be done when.

If I understand correctly, new features are something that should
happen only in major releases, like 3.9 to 3.10.

hi julian,

i haven't been on the project as long as most of you have, but hasn't it always been the case that 3.x introduces new features and 3.x.x fixes bugs? it's still my fault that i didn't document this explicitly, but i was under the impression that this isn't anything new -- we're just moving way faster than before.

The problem is that when you refactor code properly, you definitely
will create new methods. If those methods are banned, because they
imply features, we have to postpone refactoring to major releases.
Personally, I find this adds a major hurdle: you have to first find a
workaround, before you then find a lasting solution. t can even
encourage bad coding style. I agree that “proper” features should be
retained, but the problem remains.

i am, in abstract, against refactoring in 3.x.x releases. in patch releases we should be playing it safe and touching only what we need to touch. if a bugfix is elaborate enough to require refactoring on the side, it has a greater risk of breaking, so it is safer to save it for a 3.x. this is dependent on the urgency of the bug.

in this particular case i acquiesce and i'll let the killProcessByID method through for 3.9.2. it's pretty harmless. i wouldn't be happy if we let a dozen more small features through.

one option is to speed up the 3.x release cycle to 4 months. i'm impressed with our productivity so far this year and i don't think there's much harm in that. for 3.10 i resolve to be much less lenient about the deadline than i was for 3.9.


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: refactorings in minor versions

julian.rohrhuber

> Can I ask, for purposes of documentation, what reasoning we could use to make future conversations smoother? The git workflow and guidelines page currently reads:
>
> > The current release branch (like 3.9), to which only bug fixes can be merged. (Features will occasionally be merged into release branches if they are considered critical for that release.)
>
> Maybe we should have a sentence like: "A bug fix may contain a new feature if the feature is minor, and if implementing the fix without this feature would require additional work.”

yes, that sounds good! Maybe:

"A bug fix may bring with it minor features if it would require additional work to implement otherwise."

>
> Btw, this also brought to light that the explanations of "patch" and "feature" may not be clear enough. I think the documentation should include a few sentences on that.
>

that would be good, in computer music, a patch is something else normally (https://www.retrolinear.com/media/17723/_DSC0091.jpg)

OT: does anyone have an image for those removable patch boards on old modular synths?






signature.asc (849 bytes) Download Attachment
i
Reply | Threaded
Open this post in threaded view
|

Re: refactorings in minor versions

i
In reply to this post by Nathan Ho

On 8 Feb 2018, at 18:34, [hidden email] wrote:

one option is to speed up the 3.x release cycle to 4 months.

Please, or even 3! We’ve been talking about doing this for ages, and it would just solve so many problems and render so many disagreements irrelevant. Worst case is some modest releases, but there’s nothing wrong with that. It’s not like we need to sell the upgrades to pay the rent!

(How do we pay the rent, btw? ;-)

S.
Reply | Threaded
Open this post in threaded view
|

Re: refactorings in minor versions

alberto.decampo
dear brian & nathan,

first of all, thanks so much for pushing development of SC forward, this is really great, and much appreciated!
Also, faster cycles are great news, and I am happy to help with those in any way I can.

best a

> On 09/02/2018, at 11:07 , [hidden email] wrote:
>
>
>> On 8 Feb 2018, at 18:34, [hidden email] wrote:
>>
>> one option is to speed up the 3.x release cycle to 4 months.
>
> Please, or even 3! We’ve been talking about doing this for ages, and it would just solve so many problems and render so many disagreements irrelevant. Worst case is some modest releases, but there’s nothing wrong with that. It’s not like we need to sell the upgrades to pay the rent!
>
> (How do we pay the rent, btw? ;-)
>
> S.


_______________________________________________
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: refactorings in minor versions

brianlheim
OK, the git workflow page has been updated with the changes that Julian seconded.

>> one option is to speed up the 3.x release cycle to 4 months.
> Please, or even 3!

I'd be fine with either of these things. I think we (maybe projecting...) are putting too much pressure on ourselves to make the minor releases more than they need to be. I agree that a few modest releases would be OK, people might actually read the release notes!

-Brian


On Fri, Feb 9, 2018 at 8:24 AM, <[hidden email]> wrote:
dear brian & nathan,

first of all, thanks so much for pushing development of SC forward, this is really great, and much appreciated!
Also, faster cycles are great news, and I am happy to help with those in any way I can.

best a

> On 09/02/2018, at 11:07 , [hidden email] wrote:
>
>
>> On 8 Feb 2018, at 18:34, [hidden email] wrote:
>>
>> one option is to speed up the 3.x release cycle to 4 months.
>
> Please, or even 3! We’ve been talking about doing this for ages, and it would just solve so many problems and render so many disagreements irrelevant. Worst case is some modest releases, but there’s nothing wrong with that. It’s not like we need to sell the upgrades to pay the rent!
>
> (How do we pay the rent, btw? ;-)
>
> S.



Reply | Threaded
Open this post in threaded view
|

Re: refactorings in minor versions

brianlheim
> > > one option is to speed up the 3.x release cycle to 4 months.
> > Please, or even 3!

> I'd be fine with either of these things.

And by "I'd be fine with", I mean "I want them". :)

-Brian
Reply | Threaded
Open this post in threaded view
|

Re: refactorings in minor versions

Nathan Ho
In reply to this post by alberto.decampo
On 2018-02-09 05:24, [hidden email] wrote:
> dear brian & nathan,
>
> first of all, thanks so much for pushing development of SC forward,
> this is really great, and much appreciated!
> Also, faster cycles are great news, and I am happy to help with those
> in any way I can.

hi all,

since we have pretty strong support for a faster release cycle, i've
moved the deadline for 3.10 to April 15.

also, reminder that 3.9.2 is due in less than two weeks, on February 21
:)


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: refactorings in minor versions

Paul Miller
In reply to this post by julian.rohrhuber
Hi Julian,

On 9 Feb 2018, at 09:52, [hidden email] wrote:

> OT: does anyone have an image for those removable patch boards on old modular synths?

Do you mean something like the VCS3 which uses pins rather than patch cables for routing:

https://en.wikipedia.org/wiki/File:EMS_VCS3_Mk_II_routing_matrix.jpg

from:  https://en.wikipedia.org/wiki/EMS_VCS_3

Best,
Paul


_______________________________________________
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: refactorings in minor versions

julian.rohrhuber
Hi Paul,

sorry I had overlooked your reply.

Someone had told me that the word “patch” originates from removable patch boards that you would use to swap quickly between different sets of cable patchings for one and the same synthesiser. You’d patch the synth through the patch board and could then remove it without destroying the patchings.

Best,
Julian

> On 09.02.2018, at 21:53, [hidden email] wrote:
>
> Hi Julian,
>
> On 9 Feb 2018, at 09:52, [hidden email] wrote:
>
>> OT: does anyone have an image for those removable patch boards on old modular synths?
>
> Do you mean something like the VCS3 which uses pins rather than patch cables for routing:
>
> https://en.wikipedia.org/wiki/File:EMS_VCS3_Mk_II_routing_matrix.jpg
>
> from:  https://en.wikipedia.org/wiki/EMS_VCS_3
>
> Best,
> Paul
>
>
> _______________________________________________
> 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/


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: refactorings in minor versions

Paul Miller
Hi Julian,

Oh I see. I hadn't heard of that technique.
Sounds like a good solution to the memory issue with hardware patching  (which we get around so easily in software!).

Best,
Paul

On 17 Feb 2018, at 15:31, [hidden email] wrote:

> Hi Paul,
>
> sorry I had overlooked your reply.
>
> Someone had told me that the word “patch” originates from removable patch boards that you would use to swap quickly between different sets of cable patchings for one and the same synthesiser. You’d patch the synth through the patch board and could then remove it without destroying the patchings.
>
> Best,
> Julian
>
>> On 09.02.2018, at 21:53, [hidden email] wrote:
>>
>> Hi Julian,
>>
>> On 9 Feb 2018, at 09:52, [hidden email] wrote:
>>
>>> OT: does anyone have an image for those removable patch boards on old modular synths?
>>
>> Do you mean something like the VCS3 which uses pins rather than patch cables for routing:
>>
>> https://en.wikipedia.org/wiki/File:EMS_VCS3_Mk_II_routing_matrix.jpg
>>
>> from:  https://en.wikipedia.org/wiki/EMS_VCS_3
>>
>> Best,
>> Paul
>>
>>
>> _______________________________________________
>> 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/
>


_______________________________________________
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/