I saw the comment below about OFBiz becoming a "developers playground." I'll admit I have been thinking for a while that many contributions do not meet business (ie end-user) needs nor do they make it easier to meet end-user needs, and in fact in some cases even make that more difficult. However, my opinion is that this is caused by end-user oriented contributors being less active than technically oriented contributors, in fact I would say FAR less active, and less active now than in years past.
Still, all of this comes down to the same message: if you want something to be done, or to be a certain way, either you figure out how to get other people to do it or you do it yourself. -David On Feb 15, 2010, at 9:03 AM, Ruth Hoffman wrote: > Jacopo Cappellato wrote: >> I know this subject has been already discussed several times in the past, >> but I still would like to rethink our strategy for releases in OFBiz. >> I am under the impression that, considering the release branch 9.04, that is >> our latest release branch: >> * there are more users than maintainers >> > This is probably true. But to get a better understanding of who is using > what, maybe we could look into getting download statistics? I have already > put in a request to the infrastructure team for this, but have not heard > anything back from them. Maybe a project committer has more clout and could > get this implemented? Without that, we are just speculating about who is > doing what with the code. >> * because of this, no real maintenance plan, test strategy etc.. has been >> created around it from the community of users and interested parties (in >> fact we were not really able to officially release it) >> * a lot of new users start eveluating OFBiz from that instead of the trunk >> * it is rather old, several new features are missing and also code >> improvements (that could fix bugs etc) >> > I thought all the bug fixes were retrofitted to the release? Is this not true? >> * because of this, it tends to be less stable than the trunk >> > How could the release be less stable than the trunk if bug fixes are applied > to the release and the trunk? >> The main cons of this situations are the following: >> 1) not real interest in maintaining a release branch means that we will not >> be able to spend time on it and officially release it: the OFBiz community >> will miss the advantage of using the marketing channel represented by a new >> release >> 2) new users will get the wrong impression that the project is slowing >> improving if they just get the releases >> > Project committers should consider this behavior pattern: Most people > evaluating code will not want the latest release. They will patiently wait > until someone else has taken on the risk (and reward) of debugging it. Do not > think that just because the project releases a new release of OFBiz, that > everyone will stampede to get it. Far from it. Now if we had download > statistics we could verify my claim, but I'd be willing to bet real money, > that the only people who will jump to download this new release will be > project committers. >> 3) it is much easier for a user to stay up to date with the trunk rather >> than with a release: I mean that there is no guarantee that one day someone >> will build an upgrade plan from the old release to the new one... users of >> the old release may be left behind forever >> >> > I think you mistake "user" with "committer". What "user" is actively trying > to stay current with the trunk? Just some food for thought. >> What I suggest is based on the following assumptions: >> 1) community is not ready or interested in maintaining releases >> > Only the "committers" are not interested. Users out there may have a > different story to tell. Personally, I'd like to see releases "maintained". >> 2) new users prefer to start evaluating OFBiz with a release instead of the >> trunk >> 3) it is good for the project to announce new releases often >> > True. Very true. >> 4) because our current policies (slowly increasing number of committers, >> peer reviews, etc...) our trunk is (and will be) more stable than older >> releases >> >> > Again, why? I thought bug fixes are committed back to a release if > appropriate. Is this not the case? >> Here is what I suggest: >> A) define an official release plan that says that we officially issue a >> release every approx 6 months (just to give you an idea): since there is no >> way to define a set of features that will go in the next release, our >> releases will be based on dates instead of features; but of course we can >> discuss the exact time of a release based on what is going on 1-2 weeks >> before the release date >> > Don't release every 6 months. That's crazy. Once a year is sufficient. Put in > place a real release plan including features, fixes and upgrade instructions > in advance and then work towards making OFBiz something more than just a > developer's playground. Make it "stable" by setting out in advance what > "stable" means. And then work towards making each release meet the > "stability" requirements. Just releasing something every 6 months or a year > does not a "stable" release make. >> B) there is no guarantee that patches will be backported to releases, that >> upgrade scripts will be created from release to release >> >> > If so, then what is the point of even having releases? Just have nightly > trunk builds and everyone is happy. >> It is true that the ASF policies ask that a release, that represents the >> code that is distributed by the ASF to the larger audience of users, is a >> "stable" deliverable; but if we continue with the current approach, even if >> it is intended to get a stable and maintained release, what we are really >> doing is distributing the code in the trunk (this is what we suggest our >> users to use instead of the release), not the "stable" release. >> >> > IMHO, one of the true benefits of going with the ASF is the structure and > stability they enforce on umbrella projects. Why not use these "restrictions" > to the project's advantage instead of trying to circumvent them. I think I'm > agreeing with you in that maybe "we" should start pointing users to releases > instead of trunk code. Just a thought. > > Ruth >> What do you think? >> >> Jacopo >> >> >> >> >>
