Sorry in advance for the point-for-point rebuttal, but I couldn't resist...
On 8/26/14 2:46 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: >>I don't see any reason to add process where process is not required >It's about community building. I'm not sure extra process invites community building. > >> we can save time by not having to through the release process to fix >>bugs >> in the website version of TDF >Can you spell out the process here. Modify the landing page to give a proper label: "Daily Update", "Bleeding Edge", "Snapshot", etc. Fix or modify code in the repo or maybe a separate branch if we need to reference 3rd party stuff that we don't want in the official versions. Someone compiles it, if they like it, they push it up to the site. If someone feels like it, cut another release. But hopefully not too often. > >As I see it - benefits of using a voting process: >- PMC endorsement What are the benefits of that. Are you claiming more people will use it if endorsed? >- Legal angle covered (IP issues etc) No more dangerous than any other nightly build. >- Community engagement (testing RCs + finding / fixing bugs + responding >to release announcement) Seemed like more folks waited until announced instead of helping with the RC. >- Voting process is relatively simple and straight forward >- Testing RCs and being involved in process == more "points" towards >committership * Me, I'd rather submit a few patches to the examples than test the RC. Seems like that's the pattern we see from other folks too. >- RC process encourages people to find and report issues It does, but it hasn't worked. >- Hopefully potential people to consider for commitership Folks submitting patches would also be considered wouldn't they? >- Hopefully encourage a person to step forward and be a release manger I'd rather encourage folks to spend time making TDF better. >- Clear idea of changes between versions (via release notes) >- Can announce on apache lists and in blogs - we can't announce snapshots >(basically nightly builds) that way Can we not blog that some new example was added to the TDF on the site? You're right that we can't use an Announce email, but it seems like we'd be able to make more noise by blogging often as each new example comes in. >- Not in "under construction" / "development use only" mode continually. >Different quality perception. IMO, having a bug up there for 3 days is a worse quality perception than fixing in minutes. > >Only down side I see is that we can't make changes very quickly (ie a few >hours or days). But how quickly do we fix errors that arise anyway? >There's JIRA's about broken examples that have been open for a few days >but no one rushed in to fix them yet I see. ;-) If we were set up as I propose, I'd be more inclined to fix something instead of waiting until there's a push for a new release. > >If we make changes directly on web site: >- Gives an expectation that issues will be fixed quickly - can we >actually do that? We do that already for some issues in other packages. We tell folks to try the nightly build. >- IP or other legal issues may arise if all checkin /patches are not >carefully monitored Is true for any other nightly build. >- Less reason for community to be involved (no RCs to test or vote on) Most folks I know want to write code instead of run manual tests. >- No need for a release manager or in fact any further releases True, that's another time saving we could spend elsewhere. >- Pages on web site / artefacts in dist will become out of date and not >match site Could release every 3 to six months if someone has the time and energy. >- JIRAs may become confused as we may not have version numbers (what's >the version number of a nightly build?) Same for any other nightly build. If someone tries any nightly build and finds a problem, how do they report it? >- Can't announce on apache lists and in blogs = less apache exposure and >less social media engagement IMO, we could blog more often, and maybe the person who contributes the change would blog right away as well instead of having to wait days to do it. > > >How about let's see if we can make a release or two under the existing RC >candidates / voting system and if that process causes any issues revisit >it? We'll see what others think. I'd rather just save the time. I don't get why we need to have 3 people look at simple changes before they go on the site. -Alex
