Hi, > I may change my mind about this in the morning, but this is just too much > process. I see it as more of a list of what you may need to think about/get other people to help you out along the way with rather than a step by step process. Perhaps I should of left off the numbers? I certainly don't think that a contribution would need to address all of those concerns initially but it would be not to nice to say to the list "I've not considered any localisation issues with this contribution can someone take a look at that for me" or "I've no idea if this works well n Android/iOS".
Currently when something is checked into the trunk (or rather the patches branch) it's going to have little or no effect - we don't have any nightly builds for instance so all we are doing at worse is breaking a potential future build or someone's custom build. Any bit of code committed can just as easily be reverted. We've all been a bit commit shy (including me). Putting up stuff that is working but needs a little polish may actually give people something to do. > My only criteria before it goes in a release is that you tried to prove that > it doesn't break anything. Sounds fine by me. > And that's why I liked the staged branching plan where stuff goes from > whiteboard to something in-between before going to trunk/release. I'm liking this idea more. We could actually use apache.flex (or org.apache.flex) as the intern package in the patches branch? Justin
