flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: Ideas for dealing with less VOTEs per RC
Date Fri, 20 Sep 2013 03:43:08 GMT
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 
Mime
View raw message