long-duration branch, or allow performance and other regressions on master??

[Mike Beckerle <mb...@tresys.com>]

My recent work on refactoring the schema compiler creates a situation.


Though I set out to make a small-as-possible incremental change (Daffodil-1855), it's a big change. There will be performance regression in order to get functional correctness done. There are functional regressions I'd rather fix later or get help from others to figure out, so I'd like to just park them in scala-debug intentionally.


For example: I want to turn off all optimizations associated with alignment processors. This will slow lots of things down. It will also cause deadlock errors for some unparser tests.


But we know we have to refactor that aspect of the optimizer, and fixing all these things is something multiple developers really need to contribute to. Otherwise I expect the whole effort will come to naught.


Question: Should we bless a separate development non-master branch (e.g., refactor-2017-11-01 or something like that), or is it ok to just be clear that master will have some performance, and possibly even functional regressions for a while?


What I'm seeking is what is the right way to engage other developers on work based on a branch other than master? Or do we do it on master, being clear that master is allowed to regress, preferably when it is intentional?


Either way the expected behavior for 'sbt compile test' would be no-errors no-warnings (though we may want to allow deprecation warnings for a while), so developers know where they stand and what their changes affect. But some bugs may get moved to scala-debug until they get fixed again.


Thoughts?

Re: long-duration branch, or allow performance and other regressions on master??

[Taylor Wise <tw...@gmail.com>]

I concur.

On Wed, Nov 1, 2017 at 12:48 PM, Steve Lawrence <sl...@apache.org>
wrote:

> I think I would personally rather see such a large refactoring done on a
> separate branch and merged in when all regressions are fixed. Otherwise,
> it's too easy to break things and forget to fix them. I'd rather have
> tests always fail and when everything passes the branch can be
> rebased/committed to master. This would be especially important if
> Daffodil were a much bigger project with more users/developers--would
> definitely want to avoid regressions and messing up other devs. And if
> we realize that this refactoring is all wrong, it's easy to just delete
> the branch and blow it all away.
>
> The only difficultly this adds is dealing with potential merge
> conflicts, but with our low number of devs, good communication, and
> frequent rebases to master, that shouldn't be too much of an issue.
>
> - Steve
>
> On 11/01/2017 10:57 AM, Mike Beckerle wrote:
> > My recent work on refactoring the schema compiler creates a situation.
> >
> >
> > Though I set out to make a small-as-possible incremental change
> (Daffodil-1855), it's a big change. There will be performance regression in
> order to get functional correctness done. There are functional regressions
> I'd rather fix later or get help from others to figure out, so I'd like to
> just park them in scala-debug intentionally.
> >
> >
> > For example: I want to turn off all optimizations associated with
> alignment processors. This will slow lots of things down. It will also
> cause deadlock errors for some unparser tests.
> >
> >
> > But we know we have to refactor that aspect of the optimizer, and fixing
> all these things is something multiple developers really need to contribute
> to. Otherwise I expect the whole effort will come to naught.
> >
> >
> > Question: Should we bless a separate development non-master branch
> (e.g., refactor-2017-11-01 or something like that), or is it ok to just be
> clear that master will have some performance, and possibly even functional
> regressions for a while?
> >
> >
> > What I'm seeking is what is the right way to engage other developers on
> work based on a branch other than master? Or do we do it on master, being
> clear that master is allowed to regress, preferably when it is intentional?
> >
> >
> > Either way the expected behavior for 'sbt compile test' would be
> no-errors no-warnings (though we may want to allow deprecation warnings for
> a while), so developers know where they stand and what their changes
> affect. But some bugs may get moved to scala-debug until they get fixed
> again.
> >
> >
> > Thoughts?
> >
> >
> >
> >
>
>


-- 
-Taylor Wise

Re: long-duration branch, or allow performance and other regressions on master??

[Steve Lawrence <sl...@apache.org>]

I think I would personally rather see such a large refactoring done on a
separate branch and merged in when all regressions are fixed. Otherwise,
it's too easy to break things and forget to fix them. I'd rather have
tests always fail and when everything passes the branch can be
rebased/committed to master. This would be especially important if
Daffodil were a much bigger project with more users/developers--would
definitely want to avoid regressions and messing up other devs. And if
we realize that this refactoring is all wrong, it's easy to just delete
the branch and blow it all away.

The only difficultly this adds is dealing with potential merge
conflicts, but with our low number of devs, good communication, and
frequent rebases to master, that shouldn't be too much of an issue.

- Steve

On 11/01/2017 10:57 AM, Mike Beckerle wrote:
> My recent work on refactoring the schema compiler creates a situation.
> 
> 
> Though I set out to make a small-as-possible incremental change (Daffodil-1855), it's a big change. There will be performance regression in order to get functional correctness done. There are functional regressions I'd rather fix later or get help from others to figure out, so I'd like to just park them in scala-debug intentionally.
> 
> 
> For example: I want to turn off all optimizations associated with alignment processors. This will slow lots of things down. It will also cause deadlock errors for some unparser tests.
> 
> 
> But we know we have to refactor that aspect of the optimizer, and fixing all these things is something multiple developers really need to contribute to. Otherwise I expect the whole effort will come to naught.
> 
> 
> Question: Should we bless a separate development non-master branch (e.g., refactor-2017-11-01 or something like that), or is it ok to just be clear that master will have some performance, and possibly even functional regressions for a while?
> 
> 
> What I'm seeking is what is the right way to engage other developers on work based on a branch other than master? Or do we do it on master, being clear that master is allowed to regress, preferably when it is intentional?
> 
> 
> Either way the expected behavior for 'sbt compile test' would be no-errors no-warnings (though we may want to allow deprecation warnings for a while), so developers know where they stand and what their changes affect. But some bugs may get moved to scala-debug until they get fixed again.
> 
> 
> Thoughts?
> 
> 
> 
>