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
<[email protected]> 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: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
