I think that many projects that are "important" and are hard to
upgrade (user facing or customized at each installation) are fully
supported until end of support and between EOS and EOL get fixes for
bugs that have security implications where publishing the issue and fix
to the current release or trunk will give hackers easy access to data
held in the old version or in some way open companies using that version
to serious harm.
It may be somewhat difficult to get people to fix older versions but
there may be things that we could do to make this more likely.
1) Bugs can not be closed until it is fixed in all of the versions to
which it must be applied (according to our EOS and EOL rules). It might
be better to generate new issue that specifically addresses the patch to
be applied rather than a full description of the symptoms of the
original problem which is a main feature of the original report and make
this new issue a dependency of the original.
2) Open a sub-project for the older releases with different committers
who are interested in the older version and are not committing to the trunk.
This might be a way for someone to get started in OFBiz programming.
The activity in this sub-project would be a good way to judge the
community's interest in maintaining the older release. One would expect
that companies running the old version would be interested in supporting
this sub-project even if they have no interest in the trunk.
Ron
On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
Inline
Le 23/09/2014 09:26, Jacques Le Roux a écrit :
Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
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
Yes, hopefully we (I mean the really concerned persons) will not have
to enforce (ie do it ourselves) the "should" :/
* 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
Yes it's already like that and those are only rare exceptions, right
way for me
<<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)
Yes that's an important point indeed. We begin to get traction with
(mostly thanks to the bug crush effort so far) and hopefully it will
continue :)
* 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
The point I'd really want to be highlighted/explained is we don't
guarantee that old bugs fixed in trunk are backported. Let's face it,
we can't guarantee that, we have not real means to enforce it.
We have still no mention of that in the download page. I recently
backported a number of bug fixes done in the last HWM bug crush in
R12.04, but I (nobody I guess) can't guarantee we will always backport
all bug fixes in living releases branches. I don't know how other TLP
projects do, but it seems to me that to be correct/honest with our
users we need to clarify that. We should even give a mean, or at least
a way, to check that by themselves. By comparing the trunk and
releases change logs for instance? I also suggested below
<<We should then explain to our releases users how they can use the
Jira changes logs to check and amend what they use (maybe a link to
wiki from download page to not clutter this main page).
I will think about what you wrote above and see how we can inform our
our releases users (I mean a process to follow maybe even something
more automated) >>
Jacques
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).
This will need a strict observance from committers about versions to
fix and fixed. I believe it's indeed the right way, anyway we have no
others/betters (I mean offered by Jira) .
We should then explain to our releases users how they can use the
Jira changes logs to check and amend what they use (maybe a link to
wiki from download page to not clutter this main page).
I will think about what you wrote above and see how we can inform our
our releases users (I mean a process to follow maybe even something
more automated)
Jacques
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
