I'd like to comment (no flames) on a few of Lee's statements noted below. -Tim --- Tim Ellison ( [EMAIL PROTECTED] ) Integrated Technical Services ( http://www.itsco.com )
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pedlow, Lee Sent: Tuesday, April 18, 2006 2:11 PM To: flexradio@flex-radio.biz Subject: Re: [Flexradio] Am I Missing Something? Or Is Everyone? I think that Gerald's previous point (not the rant) and Jim's comment bear some discussion. The value and efficiency of the Flex product model is that there is rapid, diverse peer review of each build posted. This provides efficient convergence on major bugs and also provides corner-case testing because of the diverse applications, host platforms, use cases, etc. that may either be undetected (test voids) or require a much higher test investment by flex in order to achieve the same level of test coverage. This form of testing is actually very efficient because I'm sure Eric et al at flex have structured tests used for build checking, while the ad-hoc community has just the opposite. These concurrent implementation of these two opposing test philosophies mitigate systemic test voids (omissions or coverage gaps in the scripted environment) through the ad-hoc process, yet still has the pragmatic coverage also necessary and lacking from the ad-hoc process. [Tim Ellison] These statements could not be more true and it does provide the basis for rapid test/debug/fix cycles. There does need to be clear distinction between what is actually an alpha test and true beta, this is clear. [Tim Ellison] And as Gerald has noted, the distinction is already there. Betas are posted on the web site and Alphas are obtained from SVN. Much of the angst and dissatisfaction expressed on this very reflector is because users grabbed beta code with a high expectation of functionality that couldn't be met. In many cases, the code wouldn't pass a rudimentary "smoke test" on a particular build because of a key flaw and required the rapid release of a subsequent revision. That's truly alpha code - agreed. However, isolating such builds to development trees, web sites, etc. and requiring specialized tools to create the build is not the answer. [Tim Ellison] Why isn't it the answer? The "specialized tools" you mention are free and install in two minutes. You can download the /trunk/bin/release folder in seconds (a few minutes with dial up). You do not have to create the build, the compiled executable is right there in a folder for your consumption. Point, click, run; it doesn't get any simpler. In making the Alpha code just a tad bit less convenient to get, that would in essence help the development team. If Eric has to filter through 100 bug report daily from Alpha code users to filter out the NABs or reports on features not 100% implemented, that is time wasted from actually writing code or thinking up new wiz bang features. I'd rather him spend his valuable time doing the later. If anyone who stumbles upon it can get what is basically non-tested, guaranteed to have problems, can't support it product (remember PowerSDR is a Flex product), then that defeats Gerald's goal of trying to change the untrue perception that PowerSDR is not a mature and stable product, because Alpha code IS and immature unstable product. This defeats the beauty and value of the whole ad-hoc testing arm and relegates flex to "big company" processes. The fact that alpha evaluators have to build the code creates a whole new set of variables, problems, etc. that will obscure or at least delay discovery of actual application errors. [Tim Ellison] This is not the case; you can get the alpha executable de jour from without having to build any code. I am running that executable as I write this. I would respectfully (and professionally) suggest a tiered process available from the existing website that offers formal releases (like today), "real" beta code (like today, but more solid release candidates, as Gerald indicated) and "Build of the day" as finished .exes for alpha testing and with a click-box acknowledgement on download (like the GPL) that bugs are to be only posted to the bug tracking system and no comments or support requests accepted on specific BOD releases on the reflector. [Tim Ellison] In essence that exists today with the SVN tool without having to agree to a usage policy for reporting problems. This way everyone is informed, continues to have full unfettered access to the flex applications at all points in its lifecycle without onerous impediment (tools, compilers, knowledge) to "just run the damn code" and yet the unhappiness and delayed gratification encountered by newbies, neophytes and the nonadventurous can be avoided. As indicated, Flex is facing the growing pains that every start-up goes through. Many software activities begin as grass roots efforts and as they become viable businesses, advancement of the business requires the evolution of processes and practices. I think the suggestions made above resonate with both Gerald's desires and Jim's very valid comments (be nice Jim). Flame away. Lee Pedlow NG6B San Diego, CA -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Lux Sent: Tuesday, April 18, 2006 7:40 AM To: [EMAIL PROTECTED] Cc: flexradio@flex-radio.biz Subject: Re: [Flexradio] Am I Missing Something? Or Is Everyone? At 05:55 AM 4/18/2006, Larry Loen wrote: <snip> >And, in truth, _everyone_ already knows how to download a zip file or >even a self-unpacking .exe file. Browsers are popular for a reason -- >people understand them. <snip> >Is this all for some homely reason like the SVN repository and the flex >web server are on different machines? Requiring everyone to use SVN or >CVS is, so far as I know, pretty unprecedented for an open source >project, especially one where most of the population aren't coders. > Almost everything I can think of in the open source world that really >matters is available as "naked" RPMs or tarballs outside of the >repository proper (including, quite often, alpha/beta level code). > I suspect that *someone* could write a script to automate the process of picking up a SVN tagged version and plunking it at a website for download. The question is who is that *someone*. I think, to a certain extent, we're in that classic situation of companies that roll out a new clunky online timecard application that adds an hour a week to every employee, so that one or two people (payroll clerks) can save a couple hours once a week. SVN makes life much better for the developers, but harder for the consumers, who, as you say, prefer the "grab and explode a .exe", even if there are potential problems with installing new over old, mdb migration, etc. One idea might be to make a "installer program" that you'd install once, that hides all the svn stuff, verifies that you have the right framework and dll files, fetching them if you don't, deals with migration of databases, and, most important, can uninstall older versions. We're sort of treading new ground here.. there's a fair number of technically literate sdr-1000 users out there who would like to experiment using the rapid turnover of development, but aren't interested in being developers themselves (along with the hassles and investment of time/cash that that requires). This seems to be a very different model from most purely software products, where you have "coders" and "users", and not much inbetween. Jim _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
