As a side note, it will make your in-line responses more readable if you leave an extra line of space between the quote and the response.
Thanks, Om On Tue, Aug 26, 2014 at 3:21 PM, Alex Harui <aha...@adobe.com> wrote: > 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 > >
