HI, > One thing you may want to do is suggest is for the RM to ask the PMC if > their VOTEs may be "carried through", especially in the case of some minor > update to a new RC that doesn't involve a critical bug fix +1 to that, several RCs have just been README/RELEASE_NOTE or similar low risk changes.
> Another idea is to think about a lazy consensus release model There may be some objections to that idea as it my be seen as being a bit risky as we're not good at getting new releases out quickly and don't want to put a potentially buggy release in users hands. Since the last release we've made the nightly release more easily available and there have been more issues reported by users so hopefully than mean less unknown bugs in the next release. > Finally, improvements in CI and automated testing may help here Other than making it easier to debug when a test fails I'm not sure what major improvements could be made here. The CI have reasonable good coverage, but as it's a large codebase some areas are better tested than others. Not many committers have added new tests. I would also like to see more frequent releases, but not many committers actually want to be a release manager (AFAIK). It's a large effort to get the code in shape for a release, manage the branching/merging of changes, try and encourage other people to help out, as well as all the post release tasks. Here the current release process: https://cwiki.apache.org/confluence/display/FLEX/Release+Guide+for+the+SDK Anyone see anyway of making this easier or simpler? Thanks for the ideas. Justin
