Hi Ron,
You suggestions are often great, let's see now if the users community if
sufficiently interested to help the OFBiz de team in achieving all this....
Remember that the Apache way is more about flexiliby and lazy consensus[1]... In other words, as volunteers, we must adapt are the daily reality we
all face...
For the sake of OFBiz history, I must say that, not all but at least a good part of the applications at least, has been built in a process of
agglomeration. Contributors (committers or not) work for a client, or their own needs, and decide to give their work to the community. If the quality
is correct and the work is worth it, it's integrated by a committer (with the help of all volunteers). It's not the PMC nor any other group which
really decides of what should be there or not. It's more individual decisions, filtered of course by everybody for the benefit of the community.
Anyone can raise a hand and say his word, that's how it works actually, and it seems you are already aware of that :)
I don't say we can't improve, but I doubt that more rules (enforced? how?)
would help.
For instance, sometimes I even wonder about this page
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
Even if I still think it's helpful, is it not a bit frightening for a new
comers (it's just an exampled not really a question ;)
More answers inline...
Jacques
[1] http://www.apache.org/foundation/voting.html#LazyConsensus
Le 23/09/2014 07:40, Ron Wheeler a écrit :
I think that having a discussion about the policy followed by regular (annual or semi-annual) discussions on the roadmap with the PMC and the user
community will have a couple of effects
- fewer surprises caused by users showing up at the last minute with requests to extend the EOL or EOS (End-Of-Sales->no longer on the download page
and no longer recommended for new uers) dates.
- more commitment from the user community to help with maintenance or to
support sub-projects financially or with resources.
I have not been here long enough to know how the PMC decides on what features will be in a new release or how investigation of new sub-projects such
as the Workflow project, get accepted as "good" ideas or rejected as "out-of-scope" or insufficiently supported by the community.
Is there a formal procedure that I would have to follow to get my favorite
feature included in 14.XX??
Nope as barely explained above
How does the PMC close off the 14.XX spec?
When it's ready :D By lazy consensus (anybody can raises a hand, but he must be
in tune with what happens)
I assume that there is a process that involves the PMS and contributors who will be providing the resources and the user-community that determines
the pluses and minuses of the proposed change.
Nope, we try to avoid "'paper work" as much as possible
What are the current new features that are being considered for the 2014.XX
feature freeze?
Is this discussion documented somewhere?
Nope, but Jira can give you more than a hint
https://issues.apache.org/jira/browse/OFBIZ/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel
This the way we are recently going and it's a huge progress in comparison of
what we had before (almost nothing and despite you see: OFBiz is there)
The people doing the investigation of the Workflow engine presumably need to know when they have to get their proposal finished to make it into the
2014 feature freeze.
Obviously, this does not depend on us (OFBiz dev team) but them (to be ready
and ask to wait if necessary)
Are their guidelines about how the form and content of this proposal (features, dependent software , integration issues, resources required,
estimated time to deliver)?
Nope, would you suggest something?
Jacques
Ron
On 23/09/2014 12:35 AM, Jacopo Cappellato wrote:
On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:
<<the problem is not everybody is aware of bug fixes backported or not. The official download page http://ofbiz.apache.org/download.html, says
that we
stabilize releases with bug fixes. It's not quite clear if we are backporting all or
only some bug fixes.>>
A more formal rule would be:
* commits to the trunk from Jira tickets of type Bugs can and *should* be
backported to all the active releases
* commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be
backported to a specific active release
<<I think we should make that clear and expose a way to users for them to more
"easily" maintain the releases they use.>>
+1 see below
As suggested Ron we could also define our own or refer to
http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download
page where we already mention a tentative end of life; for example now we have:
• April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
But when we specify an end of life, we should also make clear a few things:
* this is a community goal, and the help from the community is required to meet
the goal (i.e. it is not guaranteed)
* the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release
branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low
interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
Now we need to think "technical" and automatize as possible with Jira
In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the
information will be more accurate with new releases).
The idea is to run a query on Jira with the following constraints:
project = OFBiz
type = Bug
status = not resolved
version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g.
"Release 12.04.05")
The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and
outstanding.
For them we will need help from the community (committers and non committers)
to fix the bugs or backport existing fixes.
In the download page, we could add two links (to Jira) next to each available
release:
1) known bugs (links to the above report)
2) release notes (link to the release notes available now)
One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version affected"
set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add "12.04.06" to
affected version).
What I have read so far from Jacopo seems a good start to me
Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information when
I started the version refactoring in Jira, and this conversation is helping to refine some points.
Jacopo
