On 06/02/2015 10:02 AM, Jacques Le Roux wrote:
Le 05/02/2015 15:41, Ron Wheeler a écrit :
Releases are stable.
Things that are not released are mutable.
The use of unconventional conventions should be stopped as soon as
possible.
+1! Thanks Ron, I'd hope that people express more their opinions
before events happen than ranting after it's done, too late!
I' also like to see us (committers) more as community servants than
code owners. I must say, sometimes I also tend to believe it's my
property, but it's not!
The community gives us the power, not the code...
If a branch has reached a state where no more changes except bug
fixes are expected then prioritize and clean up the JIRA issues that
are sufficiently important and likely to get fixed in the short term
and release it and start the development branch or trunk on the way
to the next minor release.
I still prefer to give some time to time (It's said to be an Haitian
proverb). It's not because we use to do that but because it's safer,
and to be frank, also less work... In other words, I think our "one
year before releasing" strategy is OK. Of course security issues are
priority and accelerate the pace.
I would like to see more releases with smaller deltas so that the trunk
can be a bit more open to work where mistakes are not so critical and
cause so much grief since SI's will not feel that they have to fork the
trunk to get their customers a working product.
Security bugs need to be fixed, backported to all supported versions and
released before the exploit becomes public knowledge.
This means that there must be an agile release process if you want
end-users to feel comfortable that their core data can be secure while
using OFBiz.
This does not mean releasing things before they are ready.
However once the team decides that a "release" is immutable, it is time
to start the release process.
This is perhaps the time for the community to get involved and more
committers allowed to help prepare the release.
This may be a bit paradoxical - the closer to production - the less
knowledgeable the talent required.
It does reflect that facts that no architectural decisions are being
made, few of the steps actually involve code modification and this can
be done by the core committers.
A lot of the work is preparing release notes, fixing documentation,
testing installation processes, updating seed data to demonstrate new
features and testing under various scenarios.
These are time-consuming and require different skills than adding
features and fixing JIRA issues.
If there are a lot of required issues, then make it a community
project to release it and get it done.
If it is not clear about the state of a release branch, then have a
meeting and make a decision.
Either it is
a) still under development and unstable or
b) it is a release candidate and only a defined and agreed upon set
of bugs will be fixed before it is released and other low priority
bugs and backports will get done in the next minor release. If a new
critical bug is found after it is declared a RC, then the team gets
to decide if it is included and adds it to the priority list or
defers it.
If it is deferred, add a note in the release notes that an important
bug is not fixed in the release but is or will be available as a
patch to the version in the trunk or development branch.
This is not rocket science and if it done properly, in an organized
way, it will be clear to Adrian and everyone how any backporting or
bug fixing should be done.
Wait, we have already a rule about that. Yours are maybe not rocket
science but are too complicated IMO.
Do you have a link to the desription of the rule?
How does Adrian's offer fit?
There are 3 main types of changes:
1) New features
2) Improvements
3) Bug fixes
3 should normally go in the release branches, as much as they can.
Security fixes should trigger a new released packages.
1 and 2 should never get into a release. Exceptions may occur, but
they need a consensus, and as ever can be vetoed (only by committers,
though this rule can be adapted by the community:
http://www.apache.org/foundation/voting.html#binding-votes)
"Sort of" stable branches is not really acceptable as a management
policy for a production quality software product.
I totally agree. I personally consider the trunk *bleeding edge*, a
new "just frozen but not yet released branch" *edge* (it's still
stabilising, like R14.12 is today) and a "released branch" (like
R13.07) *stable*.
Agreed.
What is the current procedure for Adrian's offer to backport to 14.12.
Does he have to start a 14.12.01 branch or can it be applied to 14.02?
Who makes that decision? Is there already a policy that applies and does
not need further discussion.
Ron
Jacques
Ron
On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
I would though wait that all the possibly related opened Jiras will
be fixed. Some projects are based on the R14.12 branch and people
expect this branch to be stable even if not yet released.
Jacques
Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
On Jan 17, 2015, at 11:16 PM, Adrian Crum
<adrian.c...@sandglass-software.com> wrote:
After all of this work is completed, I would like to backport it
to the R14 branch.
Hi Adrian,
I just wanted to mention that I agree that we should backport all
this work to the 14.12 branch, which is pretty new and still needs
to undergo to the stabilization process: in this way it will be
easier to maintain it (by backporting the fixes) in the future years.
Jacopo
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
