From: "Carsten Schinzer" <[email protected]> [snip]
I would be very much in favour of a bi-annual release schedule, say a spring and an autumn release. (I think that's not a surprise to anyone). And I think that's feasible, wouldn't it?
Actually OFBiz is big, and it's take time to backport to 2+ releases for each bugs... OFBiz is not an Apache project like the other. I don't know how Compiere and its forks are handling that BTW ?
However, as stated a couple of times here, there are some preparatory steps / functions not being fulfilled right now (at least not obviously) which I think any IT project - and similarly an open source project -- will need to fulfill if it takes it's responsibilities more seriously: - Scope Management -- could be introduced by e.g. classifying bugs and feature requests from JIRA
+1, there is already some means in Jira : voting, by compoment, issues status, etc. What would you suggest further ?
- Release maintenance should focus on bugs, not features
That's what we do already
- Major releases should focus on new functionality; if all feature
It's trunk in OFBiz :D
requests being handed in during a 6 months period are too heavy: start splitting into the component sets and only put e.g. framework and applications under release management and let special-purpose develop it's own way. There could be a way to treat specialpurpose applications as sub-projects (as e.g. Ant does)
More things to deal with, I'm afraid :/
That is the reason why I asked for statistics on JIRA the other day. In order to see whether these splits would make sense. I think, though, similar to other ASF projects, it's mainly up to the committers, more precisely the PMC members, to manifest how they want to move forward.
Have we enough human ressources to do that, I'm not sure. It's hard to organize a project like OFBiz not only because it's big but mostly because it's community driven...
Despite of that, I'm amazed every day... Jacques
Regards Carsten
