I was hoping you'd forward my reply so I don't have to write it again. Here it is again:
So far, the two other folks on the incubator who replied to my question there have not supported your position. They said we could label the website version as a "development version" or "snapshot" (like Maven) does. I don't see any reason to add process where process is not required so if we can save time by not having to through the release process to fix bugs in the website version of TDF, we should save time and do so. In fact, I would argue it would give us better community involvement because someone can post a JIRA with a new or fixed example and we can place it on the site in minutes, not 72 hours or more later. And it would save us time because often more than one person reports the same bug so we have to service more duplicate JIRAs and emails. We've got plenty of other projects that do need a release process for folks who are looking to learn how to be an RM and serve as the model. I'm going to wait another day or two to see if Justin can get any support on the incubator list, and if not, I think we should start fixing bugs and adding to the web-site version of TDF so its users get the best possible experience. -Alex On 8/26/14 12:40 AM, "Justin Mclean" <jus...@classsoftware.com> wrote: >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 >
