BJ, If I understand you well, Jira seems the best place
Jacques De : "BJ Freeman" <[EMAIL PROTECTED]> > Well I am pulling my foot out of mouth a lot. > seems there is a sequence to do this and I have documented them > question is where to put them so someone else does not have to hunt them > down and stumble like me. > > > Jonathon -- Improov sent the following on 11/27/2007 6:02 PM: > > BJ has mentioned a few outstanding issues that could make the binary > > release look incomplete. > > > > Frankly, OFBiz 4.0 is far from complete, but not because it doesn't have > > anything more than half-baked features. It's because it has so many new > > features slapped on that are not fully implemented yet. OFBiz 4.0 has > > enough core features to be a fully functional release. > > > > While it is true that it would be good to remove those half-baked > > features (red herrings), it would take way too much time. Also, the > > effort would be destructive, not constructive. Would rather evolve OFBiz > > 4.0 into the 4.x family to complete those half-baked features over time. > > > > Also true that OFBiz 4.0, with its numerous new features that are > > half-baked, could make it look bad. If we already had *one* binary > > release, we could still use that binary release to continue collecting > > bug reports for the next release. But as it is now, we don't have a > > single binary release for OFBiz 4.0. With a binary release, chances are > > we will have more testers. > > > > Ok, I've done my bit for the "social aspect" of this binary release. > > What do the others think? > > > > David is right about one thing, definitely. If there are only few of us > > who respond to Jacques' social call for release discussion, then there > > isn't enough homework done (outstanding issues review and such) for a > > proper release. Any other issues we need to look at? > > > > (Thanks BJ, for highlighting the outstanding issues. Those fixes that > > are easy to do would likely be thrown into the release). > > > > Jonathon > > > > Jacques Le Roux wrote: > >> 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 > >>>> > >> > >> > > > > > > > > >
