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?
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
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
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
A lot of the work is preparing release notes,
We decided to let Jira does it, based on committers actions in Jira
fixing documentation,
Are we doing that rightly? I doubt
testing installation processes,
Buildbot takes care of that
updating seed data to demonstrate new features and testing under various
scenarios.
It's normally done correctly
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
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
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
Who makes that decision? Is there already a policy that applies and does not
need further discussion.
No, we need to discuss about that
Jacques
Ron
Jacques
Ron
On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
I would though wait that all the possibly related opened Jiras will be fixed. Some projects are based on the R14.12 branch and people expect this
branch to be stable even if not yet released.
Jacques
Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
On Jan 17, 2015, at 11:16 PM, Adrian Crum <adrian.c...@sandglass-software.com>
wrote:
After all of this work is completed, I would like to backport it to the R14
branch.
Hi Adrian,
I just wanted to mention that I agree that we should backport all this work to the 14.12 branch, which is pretty new and still needs to undergo
to the stabilization process: in this way it will be easier to maintain it (by backporting the fixes) in the future years.
Jacopo