On 11/02/2015 1:56 PM, Jacques Le Roux wrote:
Le 09/02/2015 15:10, Ron Wheeler a écrit :
On 09/02/2015 5:21 AM, Jacques Le Roux wrote:
Le 06/02/2015 17:27, Ron Wheeler a écrit :
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.
I believe people should rather user the last release branch than
forking trunk or such
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.
What does mean "agile" here for you?
I do not have specific criteria in mind.
If the integrity of OFBiz data or business processes is at risk from
a security problem that has been raised in a JIRA, diagnosed, fixed
and advertised to the hacker community through the forum and JIRA,
it would be a good idea to issue a release and suggest that people
upgrade or issue an upgrade that can safely be applied by end-users
to their system ASAP.
Waiting for a year to issue a new release is not sufficiently agile
and I would expect a gradual improvement in the responsiveness over
time.
I am not sure how many security patches get issued each year and how
they are currently identified and tracked by the PMC.
I thought you were not specifically speaking about security problems.
Anyway, it's not done that way. Roughly: someone (a white-hat hacker)
find an issue in OFBiz and report to the ASF security team
http://www.apache.org/security/ (or rarely directly to the PMC, in
private ML, so can't be read but by PMC members). The ASF security
team then send the information to the PMC. The PMC fixes the issues
ASAP. Then this issue is fixed in trunk and backported in all living
branches in a shoot, a new release is created and a CVE
https://cve.mitre.org/ created. Then the OFBiz Download page is updated
How many security issues have been addressed in the past.
Perhaps I am worrying about a case that never comes up.
I have never seen an issue that was sufficiently important to trigger a
release since I started following the project.
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.
Yes of course, that's how it's done. We don't publicize
vulnerabilities before they are fixed in committed code
This may be a bit paradoxical - the closer to production - the less
knowledgeable the talent required.
I don't get it
End-user's (system admins, business consultants) can create test
scripts, document them, run them, create JIRA issues, try the
installation of several operating systems, tweak the installation
documentation, create test data.
None of these activities require the skills needed to write new
features, patch bugs.
OK
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.
Still not
What is the problem with this statement?
Is there some particular concern that I am not addressing?
Actually it's more the goal you try to reach here I can't understand.
Also the sentence
<<few of the steps actually involve code modification and this can be
done by the core committers. >>
Seems contradictory to me
I was trying to make the point that even if most of the work can be done
by people who are not writing code, there may still be some bugs found
that require code to fix and the code committers are still going to be
available to do this.
The goal is to free up the people committing code by having the rest of
us take on some of the load involved in getting a release out.
A lot of the work is preparing release notes,
We decided to let Jira does it, based on committers actions in Jira
Still needs to be edited for clarity , inconsistencies and missing
items need to be detected and fixed.
fixing documentation,
Are we doing that rightly? I doubt
The community can help if the PMC make the decision to work in a way
that allows this to happen.
Which decisions wouldyou suggest (apart splitting in sub-projects, we
have all understand it's your pet subject ;) )?
We need to be more pragmatic here...
1) Decide to finish the release with the current set of issues (solved
and outstanding)
2) Branch an RC.
3) List all of the tasks that need to be done and agree that completion
of these tasks will result in a new release.
4) Create JIRAs against the tasks with the RC as the version including
documentation, test configurations,
5) Solicit community involvement to accept assignment to JIRA issues
6) Fix JIRA items that require code changes
7) Vote out the release
testing installation processes,
Buildbot takes care of that
I am not sure that this is true.
You and I found errors in the Wiki the first time I tried to install
and run OFBiz.
You speak about "testing installation processes", this has nothing to
do with the wiki. Builbot takes care of the tests for the trunk and
the living branches and a bit more (updates and upload Javadoc
http://ci.apache.org/projects/ofbiz/site/javadocs/, creates Apache Rat
reports http://ci.apache.org/projects/ofbiz/rat-output.html, creates
snapshots http://ci.apache.org/projects/ofbiz/snapshots/, copy test
results http://ci.apache.org/projects/ofbiz/logs/)
If the instructions in the wiki prevent the product from being deployed,
that is an installation problem.
So the person trying to use OFBiz, it does not matter why it does not work.
How many operating systems and database combinations are tested?
Only Linux and Derby. It's a matter of resources.
The community should be testing the combinations that they care about.
It is their interest to be sure that the new release work for them.
What is the range of functionality tested?
All tests present in OFBiz
How is the GUI tested?
Are there written scripts describing each of the screens and
combinations of data-entry values that are tested?
How are the tests maintained.
As well as possible
Of course!
Is this something that the community could do?
Yes the community could help. I'm not sure of the modality. I know for
instance that the Neogia team is running their tests on Jenkins.
I hope that this discussion is helping move this forward.
updating seed data to demonstrate new features and testing under
various scenarios.
It's normally done correctly
I hope so but I notice that the Party demo data is pretty minimal and
does not include basic elements such as Classifications or Postal
Addresses.
It has no customers or suppliers which would seem to be pretty
important for testing an ERP.
Then we (the community) should create Jira issues and if possible
attach patches to those
Once I have the current ADTransform data loading scripts finished, I
will be able to contribute a tool that will help by making it easier to
add customers and employees with some of the standard supporting
entities (postal addresses, e-mail, SIC Classification, telephone).
These are time-consuming and require different skills than adding
features and fixing JIRA issues.
Yes, but since it's done on a continuous-flow basis in Jira issues,
we are better with that now
I am not sure that it is done.
We are spending a lot of time cleaning up bugs in the Wiki that date
back several releases.
Sorry, I don't consider that the wiki contains bugs, it only misses
some love. BTW, thanks for your help there!
The Wiki is almost as important as the code to someone trying to adopt
OFBiz.
I hope that we can attract the same kind of community involvement in
other areas of the project.
The installation procedure documentation was not correct.
I am not sure that data is added to the demo data to test/demonstrate
each new function.
It's still not always done when new features are added, and missing
demo data from the past are not often considered.
But the situation is MUCH better than few years ago and it continues
to improve (thanks Nicolas for your continued work on this!)
Great.
It also takes too long since it is being done by people who are busy
elsewhere.
The current process also does not encourage the community to get
involved.
OK, would you not recommend to split the project in sub-projects?
I would but for other reasons.
We can do this by providing a bit more leadership from the PMC and
current committers.
Sometimes you will be surprised by the response from people when you ask
for help.
By identifying specific tasks that need to be done and asking for
volunteers, we might be surprised at the response.
By making it easy to work on an RC, the committers will have less work
to do.
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?
No but you can create it in the wiki using what I wrote below
I thought that you said that you had a rule?
It was not written yet, but we could write it here
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
I am not sure that my release strategy would be described as a
consensus view yet.;-)
To clarify your view:
a) A release branch can't be in your situation a). No developments
should occur in release branch, only bug fixes or trivial non
functional changes committed by consensus. Else it breaks the rule!
b) I agree about your point b)
I am certainly willing to help document this but I am certainly going
push for something close to what I described above.
What is the list of tasks that have to be done between a "freeze" and
a "release".
This indeed needs to be documented. But in a better manner than what
we have achieved so far at
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
Too much documentation kills the documentation (people use rather TL;DR)
Who manages this? How is the list developed? Who determines when
enough testing has been done?
It's not organised yet.
The question to the committers is"
"Is it worthwhile taking the time to get organized so that others can
help do the work."
How is progress tracked? How is help from the community solicited
during this phase.
Not properly done yet.
How does Adrian's offer fit?
I want to write more about that. Hopefully soon...
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?
A 14.12.01 branch would be confusing (with the to come R14.12.01
Release which is unrelated). Another name could be used, we have
never done that and I'm against this idea
Agreed but without a policy that is agreed and followed, it makes
these discussions difficult and sometime more heated than is good for
the project.
If 14.12.01 is coming out sometime in 2015 (no date) and he can't
backport to the 4.12.01RC, he should start a 14.12.02 (sorry for my
typo above which made things confusing).
He can't backport if it's not bug fixes or trivial consensus changes .-
Should be documented as a policy so it does not become a clash of wills.
However this now means that new patches need to be applied to the
trunk, 14.12.01 (if they meet the unwritten criteria for inclusion in
an immutable release) and 14.02.02 plus backported to earlier
supported that need it.
I'm against that
Who makes that decision? Is there already a policy that applies and
does not need further discussion.
Most of the time the community makes the decision by lazy consensus
(the"famous" Apache way), but a PMC member can in all cases veto it.
http://apache.org/foundation/voting.html
Needs to be more transparent and set as policy to avoid conflicts whre
policy is challenged in parallel with application of policy.
Never completely avoidable but should be few and far between.
No, we need to discuss about that
+1.
I hope that this is helping a bit.
I have changed the subject line since we have hijacked Adrian's topic.
Yes, thanks!
Ron
Jacques
Ron
Jacques
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
