I concur. On Wed, Nov 1, 2017 at 12:48 PM, Steve Lawrence <[email protected]> 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
