Jonathon,
With all of these comments I think you're forgetting the basic idea of how OFBiz is structured: it is community driven, ie driven from the outside in. It is not centrally driven or driven from the inside out.
So... On Apr 27, 2007, at 10:21 PM, Jonathon -- Improov wrote:
Agreed.Would it be feasible to dedicate a committer to the release branch, a committer who will become very familiar with the branch?
There is no way to do this. If someone wanted to take this on they certainly could, but neither I nor anyone is in a position to tell any other committer what to do and require something like this of them.
A single volunteer would probably not be sufficient anyway. As described in the release plan in order for the release branch to result in a successful stable release, lots of people from the community need to get involved.
Are you also saying that there will not be any release branches that are too old to be maintained by OFBiz committers? It's quite usual to see project developers shelf a release branch, and to see a group of "outsiders" offer to maintain it just because they have clients using it. Those project teams that don't ever "leave any branch behind" are those who are willing to work new bugfixes into the old branches, no matter how far the trunk has deviated from those branches.What happens when OFBiz wants to move to the next version (5.0?).
There is no "OFBiz" to even want such a thing. A release branch will eventually stagnate and die when there aren't enough organizations/ people using it or they are no longer interested in maintaining it.
-David
David E. Jones wrote:On Apr 27, 2007, at 1:31 PM, Jonathon -- Improov wrote:I would recommend including the full log of the bugfix being brought in. At some point, the release branch may be left to "outsiders" (interested parties not within OFBiz team) to maintain, and they'll need good docs.This is not likely to ever happen. In fact, the vetting and monitoring on the release branch will be more strict, not less, than the trunk.-David
smime.p7s
Description: S/MIME cryptographic signature
