Le 11/02/2015 21:14, Ron Wheeler a écrit :
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.
I told you in the last message: look at the Donwload page
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.
Actually it's more simple than that. It's explained in the Download page and there is
also a README in the "OFBiz root (folder)"
Maybe we should think otherwise and remove all things in the wiki which might
not been ALWAYS maintained.
From this conversation I begin to wonder if it's not the right solution. Keep
the documentation as simple as possible!
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.
Agreed, not an OFBiz team issue
What is the range of functionality tested?
All tests present in OFBiz
How is the GUI tested?
That's missing. There was an effort, started by Erwan, but it was abandoned
when he left the project.
https://issues.apache.org/jira/issues/?filter=12315391#
I also tried to taker over another Erwan's effort, but had to give up for now:
https://issues.apache.org/jira/browse/INFRA-3590
Are there written scripts describing each of the screens and combinations of
data-entry values that are tested?
Nope
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.
I have already been surprised few times. Problems: it does not always last...
By making it easy to work on an RC, the committers will have less work to do.
In theory more work at start but less once done, in theory... Nothing prevents
people to help, we are adults, aren't we?
That's how I started in 2005, I picked a subject (the POS then) and did my way
from that.
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."
Sincerely... I have some doubts about that...
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.
This was clear so far. As I said we can write it, but it will not fundamentally
change things, since we (committers) agreed on this already
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.
I'm not against writing it, best place already suggested... Other opinions are
welcome, if ever I missed something...
Jacques
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
