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??
How does the PMC close off the 14.XX spec?
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.
What are the current new features that are being considered for the
2014.XX feature freeze?
Is this discussion documented somewhere?
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.
Are their guidelines about how the form and content of this proposal
(features, dependent software , integration issues, resources required,
estimated time to deliver)?
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
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
