Hi, Forwarding to dev@ at Om and Alex's request (with a couple of very minor edits). Please feel free to comment.
Justin > From: Justin Mclean <jus...@classsoftware.com> > Subject: Reason for the release process > Date: 26 August 2014 12:07:29 pm AEST > To: priv...@flex.apache.org > > Hi, > > This is come upon the dev list and incubator lists but is probably more > relevant to the PMC, and a better place to discuss it, so I'm posting here. > > As I understand it Alex is suggesting we directly change TourDeFlex on the > web site (ie deploy new compiled sources that we have not voted on) and not > use the usual release process. Alex please feel free to clarify anything if > I'm misunderstanding anything here. > > The whole point of the release process is to: > 1. Have legal overview by the PMC > 2. Engage and involve the community > > Why would we want to avoid either? As we've seen we've already had some > community involvement in TourDeFlex and I expect a little more over the next > week or so. Perhaps if we're lucky we'll even get someone to try and fix a > bug or two who may in time end up being put forward as a committer. > > As [1] says "Under no circumstances are unapproved builds a substitute for > releases. If this policy seems inconvenient, then release more often." > > I would like to make TourDeFlex a good example of the release process as it's > relatively easy to change and update (compared to the SDK), and not hard to > compile or vote on and a lot easier to make more frequent releases of > (depending on contributions of course). Allso to show that the release > process is it not something we should be scared or or try and avoid and > hopefully even get someone else to try and be a release manager. Doing all of > this means more community involvement and shares knowledge and responsibility > about, which is a good thing in my books. > > And (with my PMC hat on) I'd also note that [1]: > "Deviations from this policy may have an adverse effect on the legal shield's > effectiveness, or the insurance premiums Apache pays to protect officers and > directors, so are strongly discouraged without prior, explicit board > approval." > > Thanks, > Justin > > 1. http://www.apache.org/dev/release.html
