http://ofbiz.116.s1.nabble.com/release4-0-OFBIZ-1106-in-or-out-tp185421p185441.html
> 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" <
[hidden email]>
>>>> 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
>>>
>
>
>
>