You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Ron Wheeler <rw...@artifact-software.com> on 2015/02/09 15:10:27 UTC
Release policy
On 09/02/2015 5:21 AM, Jacques Le Roux wrote:
>
> Le 06/02/2015 17:27, Ron Wheeler a écrit :
>> 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.
>
> 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.
>
>>
>> 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.
>
> As soon as we freeze a release branch it's normally immutable. It's
> though not yet ready to be released
>
What does immutable mean in this context? What is the process to go from
"immutable" to released?
>> This is perhaps the time for the community to get involved and more
>> committers allowed to help prepare the release.
>
> For now Jacopo prefer to do it himself. I'm not sure why. This should
> be rather documented...
>
>>
>> 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.
>
>>
>> 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?
>>
>> 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.
>
>> 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.
How many operating systems and database combinations are tested?
What is the range of functionality tested?
How are the tests maintained.
Is this something that the community could do?
>
>> 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.
>> 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.
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 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.
>
>>
>>>
>>>> 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?
I am not sure that my release strategy would be described as a consensus
view yet.;-)
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".
Who manages this? How is the list developed? Who determines when enough
testing has been done?
How is progress tracked? How is help from the community solicited during
this phase.
>
>>
>> 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).
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.
>> Who makes that decision? Is there already a policy that applies and
>> does not need further discussion.
>
> 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.
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
>>>>>> <ad...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Release policy
Posted by Ron Wheeler <rw...@artifact-software.com>.
+1
We should be careful about adding things to the project infrastructure.
If it will not be kept up to date, don't add it into the main sections.
Things that are private musings or a best partial specifications of a
potential enhancement should be clearly marked as such and kept out of
the view of someone trying to get started with OFBiz.
The current effort should help identify and clean up the important items
and move old stuff to the archives.
We can be a bit ruthless since nothing is really lost forever.
Ron
On 12/02/2015 2:40 AM, Jacques Le Roux wrote:
> This is something I really want to do now, I will try to remove as
> much as possible things from Confluence!
>
> Jacques
>
> Le 11/02/2015 23:23, Jacques Le Roux a écrit :
>> 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!
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Release policy
Posted by Jacques Le Roux <ja...@les7arts.com>.
This is something I really want to do now, I will try to remove as much as possible things from Confluence!
Jacques
Le 11/02/2015 23:23, Jacques Le Roux a écrit :
> 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!
Re: Release policy
Posted by Jacques Le Roux <ja...@les7arts.com>.
BTW, I think suggested a wrong page to put the rules, better to use
https://cwiki.apache.org/confluence/display/OFBADMIN/Release+Plan
BTW why both?
https://cwiki.apache.org/confluence/display/OFBADMIN/Release+Management+Guide+for+OFBiz
https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Release+Management+Roadmap
While at it, we could maybe get rid (or archive?) of
https://cwiki.apache.org/confluence/display/OFBADMIN/Press+Releases and children. Reasons: we don't need to keep widely broadcasted information and
next releases did not follow this pattern
https://cwiki.apache.org/confluence/display/OFBADMIN/Announcement+for+new+release+Apache+OFBiz+09.04.01
https://cwiki.apache.org/confluence/display/OFBADMIN/Announcement+for+new+release+Apache+OFBiz+10.04
https://cwiki.apache.org/confluence/display/OFBADMIN/Press+Release+for+Release+Branch+9.4
Jacques
Le 12/02/2015 01:31, Ron Wheeler a écrit :
> It is getting a bit long so I will make my comments at the top.
>
> What is the plan for the next release?
> Will it be 13.07.02 or 14.12.01?
There is no plan yet
>
> Who is the project manager for the release project?
For the moment Jacopo insisted to always be the RM
>
> What has to be done to get it finalized?
>
> What help is required? How do people sign up to help?
>
> Is there going to be a meeting to kick off the process?
I don't know
Jacques
>
> Ron
>
> On 11/02/2015 5:23 PM, Jacques Le Roux wrote:
>>
>> 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 <ad...@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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: Release policy
Posted by Ron Wheeler <rw...@artifact-software.com>.
It is getting a bit long so I will make my comments at the top.
What is the plan for the next release?
Will it be 13.07.02 or 14.12.01?
Who is the project manager for the release project?
What has to be done to get it finalized?
What help is required? How do people sign up to help?
Is there going to be a meeting to kick off the process?
Ron
On 11/02/2015 5:23 PM, Jacques Le Roux wrote:
>
> 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
>>>>>>>>>> <ad...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Release policy
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ad...@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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: Release policy
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
>>>>>>>> <ad...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Release policy
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
>>
>>>
>>> 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
>
>>>
>>> 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...
>
>>
>>> 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/)
>
> How many operating systems and database combinations are tested?
Only Linux and Derby. It's a matter of resources.
> What is the range of functionality tested?
All tests present in OFBiz
> How are the tests maintained.
As well as possible
> 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.
>
>>
>>> 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
>
>
>>> 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 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!)
>
> 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?
>
>
>
>>
>>>
>>>>
>>>>> 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.
>
> 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 .-
> 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
>>
>> 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!
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 <ad...@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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>