Jonathon, all, One day or another "we" will have to pass a vote about exposing officially the release as tarball and such. I guess one reason "we" don't do it as fast as you'd like is that it's a one man process (David has exposed number of other reasons, which you discussed below). As David briefly explained (he talked about keys) there is a release manager for each TLP (note the idea about technical and social ones) http://incubator.apache.org/guides/releasemanagement.html#glossary-release-manager. And releases must follow certains guidelines http://www.apache.org/dev/release.html http://incubator.apache.org/guides/releasemanagement.html#best-practice. . I think we have achieved all the requirements regarding licence and such . There seems to be less and less bugs to back port and anyway this is not a criteria as explained in links above. . The documentation sounds pretty updated.
But there is still some works to do : . Prepare release announcements and advertising . Create the tarballs (different types for Linux, Windows, etc.) as it was done here http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Incubating+4.0.0+Test+Snapshot+Release following http://docs.ofbiz.org/display/OFBADMIN/Release+Plan#ReleasePlan-HowtodoOFBizReleaseRelatedTasks . Check all points in the 1st 2 links above . Launch an official vote (only PMC votes are binding) . Certainly some points I forgot... By chance "we" should have been thru all this during incubation (see snapshot release link above) So I think "we" are not so far from releasing. The main thing would be to have more testing for the current release4.0, and especially feedback from real production environments. Maybe we should ask for this last point on user ML ? Thanks Jacques De : "Jonathon -- Improov" <[EMAIL PROTECTED]> > >> Perhaps a good 99% of the population don't want to hear the 3 letters "SVN" > >> when they attempt to download and test OFBiz. > > > There is certainly a target audience in that. But consider the nature of > > OFBiz: it is most commonly used by developers or analysts that full-on > > customize or at least significantly configure OFBiz to make it possible > > to use in their businesses. It just isn't designed and hasn't been > > implemented for OOTB (out-of-the-box) use. > > But isn't there value in mass market? The classic "funnel" structure? > > If 100 people knew about OFBiz, maybe 90 could get interested due to the easy > download and install > process. With SVN, maybe only 10! > > If 90 download OFBiz, maybe 9 will customize it themselves. The others might > be interested enough > to find help customizing it, if they see a polished or shrink-wrapped product > (no half-implemented > features that send them flying off cliff when they click on one). If OFBiz > has many "red screens > of death" (who coined this quote?) with most button clicks, maybe none of > those non-techies will > buy it. > > It's a numbers game. I don't think you need to pay much attention to the > non-techie testers. Well, > unless they submit bug reports, tons of it. But then, isn't that good for > stabilizing the release > branches of OFBiz? > > I was from sales and marketing before, so the funnel phenomenon is deeply > entrenched. 9 rejections > out of 10 is great result to me. That's why I'm still thinking that hitting > 100 folks with binary > release is still better than hitting 10 folks with SVN release. The top of > the funnel has to be large. > > > Also consider that what we really need for a strong community is for > > users to offer feedback and contributions to move the project forward. > > Then wouldn't we want more non-techie testers? The common complaint I hear is > that there just > isn't enough testers and bug reports for the release branch. > > > In fact that is the ONLY way that OFBiz moves forward as there is no > > company that owns or sponsors OFBiz. > > Some want to own forks. I can't help that. As I had always said, this aspect > of strategic planning > for open source project like OFBiz is beyond me. I can't comment on this. > > > the thought of having thousands of users who don't want to customize and > > don't contribute is REALLY scary. Imagine all of the complaints and > problems > > that the current community isn't big or experienced enough to support for > > free in a good old community fashion... > > On other hand, what about the thought of having OFBiz 4.0 largely untested, > and hardly a candidate > for binary release even after a long year? Maybe a balance somewhere is good? > > I don't think the community is inadequate to handle every and any bug reports > that can come in for > OFBiz. If you're worried about making a bad first impression because we > rolled out a largely > clunky release, you gotta know that first impression was already formed even > now. The fact that > there's no binary release already gave many folks a first impression. It's > always > work-in-progress, and pain (in form of insulting bug reports if need be) is a > good way to improve. > > I'll be upfront with you about my own struggles in this locale. To me, OFBiz > is fighting against > QuickBooks, NetBooks, NetSuite, even SAP. Time after time, my propositions > with OFBiz loses > against those polished products. The first impression was already formed. (So > I'm forced to > package OFBiz into a stable fork for them, unfortunately.) > > You got yourself, Al Byers, Andy, many others. And now even Adrian Crumm is > becoming an expert in > the Widget Engine. Sure, there is room for improvement everywhere. But I > really don't think the > community is inadequate in technical skill sets. > > > To put it in more concrete terms: if I have to spend 20 hours a week > > researching stuff so people don't commit things that are inconsistent or > > difficult to manage or contradict or break things that exist, where do I > get > > time to actually do administrative tasks like creating a binary release? > > I see. Is that why you think the community isn't ready for big-bang exposure? > > Fine. I'll learn whatever necessary to create correct and streamlined patches > (I did). I'll read > whatever I'm told to. Be strict about the coding conventions. If it will > shave that time down from > 20 hours to 2, be strict about it. > > Problem: bad contributions that require administrative overhead to screen and > process > > Possible solution: certify contributors > > Sigh. Are we really that bad? > > > Your comments are always welcome. Feel free to re-hash too, things > certainly > > change over time. > > Ok. I know, things will always change. > > > Just don't be too surprised if I pull out every gun I can think of to argue > > against something that I think will be bad for the project, especially if I > > am re-writing the thoughts. > > If you didn't, I'd think the project is dead. > > For what it's worth, seeing you manage the contributions going into OFBiz is > a needed sign for > many of us that things are moving along. > > Jonathon > > David E Jones wrote: > > > > On Nov 26, 2007, at 10:32 AM, Jonathon -- Improov wrote: > > > >> The way we are doing it now, it's anal-retentive. It's like saying > >> "wait, boss, one more bugfix, just one more", and saying that for a > >> whole long year! I usually publish "release candidates" for my boss, > >> let him test it, let him scream the bug reports to me, then release > >> the next "release candidate" when he's gotten upset enough. > > > > Maybe the way you are doing it now... "we" is going a little far... > > > >> Ok, next question. So why not just let the whole world test the moving > >> OFBiz 4.0 branch? Why bother with publishing tarballs and release > >> candidates? Here's a simple analogy. Try telling our bosses "boss, can > >> you learn some SVN and test my bugfixes, so I don't have to prepare > >> tarballs for you?". Perhaps a good 99% of the population don't want to > >> hear the 3 letters "SVN" when they attempt to download and test OFBiz. > > > > There is certainly a target audience in that. But consider the nature of > > OFBiz: it is most commonly used by developers or analysts that full-on > > customize or at least significantly configure OFBiz to make it possible > > to use in their businesses. It just isn't designed and hasn't been > > implemented for OOTB (out-of-the-box) use. > > > > Also consider that what we really need for a strong community is for > > users to offer feedback and contributions to move the project forward. > > In fact that is the ONLY way that OFBiz moves forward as there is no > > company that owns or sponsors OFBiz. > > > > So, we WANT people to use OFBiz from SVN. I don't know about the others > > who are involved more actively in managing and moderating OFBiz (ie the > > PMC members and committers), but for me the thought of having thousands > > of users who don't want to customize and don't contribute is REALLY > > scary. Imagine all of the complaints and problems that the current > > community isn't big or experienced enough to support for free in a good > > old community fashion... > > > > Don't get me wrong, I ONLY wrote what and I wrote and don't read other > > stuff into it. This (a binary release) IS something that is necessary to > > help grow the project, but with limited resources and most of those > > going into trying to stabilize development and contributions because > > most contributors write WAY more than they read and research... we are > > where we are, and it is what it is. To put it in more concrete terms: if > > I have to spend 20 hours a week researching stuff so people don't commit > > things that are inconsistent or difficult to manage or contradict or > > break things that exist, where do I get time to actually do > > administrative tasks like creating a binary release? > > > >> Also, given that the 3rd-party binaries (more than 50% of OFBiz > >> download size is *not* OFBiz codes!) is in the SVN, it is in the OFBiz > >> PMC's interest to lessen the load on the SVN server wherever possible. > > > > Nice try. Machines are machines and are cheap and easy to manage. People > > are people and are expensive and difficult to manage. It's that simple. > > If it makes things more difficult for developers it will hamper or kill > > the project. > > > > Not gonna happen, especially if we want it to be possible to have enough > > resources to put together a binary release anytime soon... > > > >> Just my 2 cents. I'm feeling very embarrassed for beating this topic > >> so much to death by now. > > > > Your comments are always welcome. Feel free to re-hash too, things > > certainly change over time. Just don't be too surprised if I pull out > > every gun I can think of to argue against something that I think will be > > bad for the project, especially if I am re-writing the thoughts. > > > > -David > > >
