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?
