I don't think that we are a long way off having a clear statement of policy.
The PMC needs to meet on this and hash out the policy in a general way
and then apply this to 11.04, 12.04 and 13.07.
The PMC may feel the need to draw in more users and contributors into
the discussion.
The current vagueness about the intentions of the team about the future
makes it hard for anyone to adopt OFBiz as an end-user product.
The Integrators may not feel this is an issue for their customers since
they probably have internal policies about their EOL intentions that
they can communicate to their clients to give a clear picture about when
the client will be forced to face a future upgrade.
Once the team decides that 12.04 (current release) will only get
security fixes after Dec 2014??? and will not get any fixes after Dec
2015???, then everyone running 12.04 will know that they have a project
to budget in 2015.
If you decide that 13.07 will be supported until Dec 2017???, then
system managers/IT managers will know that their initial implementation
is protected until that date.
The team will know which issues to create in the JIRA each time a
problem is identified and know what work has to be done in order to
properly support the community.
As Adrian points out, no one individual contributor can be forced to fix
any particular bug but their will be some peer pressure to maintain
one's "merit" reputation by fixing related bugs or at least documenting
the fix in one release so that someone else can fix it in another.
It may be that people will actually want to help out on fixing 12.04 by
porting the bugs fixed in 13.07 if they are actually running it.
It may also be a good way for new contributors to learn the framework
and code by backporting bug fixes.
Probably more relevant for porting trunk fixes back to 13.07 once 13.07
actually becomes the official stable release rather than the defacto
stable release.
Ron
On 22/09/2014 3:58 PM, Jacques Le Roux wrote:
OK I began this convo. Inline...
Le 22/09/2014 21:15, Jacopo Cappellato a écrit :
We are maintaining somewhat similar information in these pages:
http://ofbiz.apache.org/download.html
This is where we should be more specific and explain things better as
I kinda suggested in one of my message
http://markmail.org/message/pos2gnyj47uxsn5s
Excerpts:
<<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.>>
<<I think we should make that clear and expose a way to users for them
to more
"easily" maintain the releases they use.>>
As suggested Ron we could also define our own or refer to
http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
Now we need to think "technical" and automatize as possible with Jira
What I have read so far from Jacopo seems a good start to me
Jacques
http://www.apache.org/dist/ofbiz/
Jacopo
On Sep 22, 2014, at 8:31 PM, Ron Wheeler
<rwhee...@artifact-software.com> wrote:
Here are some examples of End Of Life policy statements for open
source products.
http://wiki.centos.org/About/Product
http://tomcat.apache.org/tomcat-55-eol.html
http://www.openoffice.org/development/releases/eol.html
http://support.rightscale.com/15-References/End_of_Support_and_End_of_Life_Schedule
is a very nice presentation of EOS and EOL dates with definitions.
Perhaps the PMC can take up this issue and settle what they want to
offer as a "warranty" to users who download a version or have a
version installed and are making their upgrade and security
calculations for their ERP.
Ron
On 22/09/2014 12:42 PM, Pierre Smits wrote:
Jacopo,
Your first suggestion is a bit cumbersome. If an issue affects
multiple
versions and it is not fixed in all versions, why not simply keep
it open
as long as the release branch it affects is in the maintenance cycle?
Your second suggestion is ambiguous.
Which part of the community are you referring to with respect to
decreased
interest?
What if the installed versions amongst our user base is significant
different than you expect? We can suggest the users what to use,
but it is
down to migration costs and added value of the newer version how
customers
decide.
And what if there is enough interest among the non-committing
contributors
to continue to support a release branch, while none of the
committers is
willing to? Is the PMC going to invite these non-committing
contributors to
be committers as well?
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxmedia.com> wrote:
Some ideas to manage this workflow in a better way:
* if a bug that affects an old release branch is not backported,
when we
resolve the ticket we create a new one that is linked to the
original and
has the field "affected releases" set the affected old branch;
this will be
a placeholder for the ones willing to maintain the old branch
* about the end of life of release branches: when we perceive a
decreasing
interest from the community to backport to an old release, we
could run a
vote to decide if the community is ok to anticipate the end of
life of a
release branch; the ones that vote to keep the branch alive could
offer to
help in the backporting process
Jacopo
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
