Ok. I've went through the Tomahawk issue tracker and looked at all Blocker and Critical issues. I find three that appear to be regressions (no patches), and one that appears to affect other frameworks (includes a patch).
Everything else I changed to major priority. But this did bring up another consideration. If we are going to make wide, sweeping changes to Tomahawk, we need to commit all outstanding patches first. Otherwise these patches are going to become obsolete. On 9/15/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
On 9/15/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > Yes. And you don't need to wait for the re-branch to actually happen, > because with Subversion we can copy it from any revision. > > Infrastructure wise, IMO it's fine to go ahead with the Dojo upgrade > on the Tomahawk 1.1.5-SNAPSHOT trunk, and start moving components out > of the sandbox. I think this is a bad idea until we assess the state of Tomahawk. We don't want any arbitrary branch. We want to branch with all blocker issues fixed. If we currently have a blocker in the trunk, and Werner starts migrating massive changes to 1.1.5, then we're going to be developing patches in two separate branches. For blocker in tomahawk, I'd define that as any regression of old behavior in a component (ie, the component doesn't work as well as it did the last release) or any non-component issue that makes the framework unusable. I don't think we can realistically fix every new problem discovered for every component, but everything should work at least as well as it worked in the last release.
