Alex, > exciting, but I feel like there is still enough activity in the existing > Flex SDK to warrant spending time to make sure we don't inject issues that > prevent folks from switching to Apache Flex. And I see it as my role to > tackle the nasty regressions like that ADG cursor issue that you looked at > earlier today that are just going to take too much of volunteer time.
To be sure: that issue turned out to have nothing to do with ADG at all. It has it's roots in CursorManager or something deeper. I've included example code in the JIRA issue that shows and abstracts the same behaviour in a Button subclass. >> It was my understanding that a bug is considered fixed if it doesn't >> break prior tests and fixes the issue at hand. Am I wrong? > I think as a volunteer you are welcome to use your definition, but > unfortunately, even 30,000 mustella tests are not an exhaustive check of the > current code and don't pick up performance and memory leak issues, so that's > why I keep quickly scanning commits. To me, if I spend a few seconds to > catch something before it goes out, it is the right use of my time. You make it sound like I came up with that 'definition'. I think the workflow I refer to - fix, test (Mustella, checkintests), commit - is understood by most committers to be THE way to contribute. If there are other requirements, we (you?) need to document those so the few contributors that still dare to touch the SDK know how to properly work on it... EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
