That's very similar to our present process, for big changes, branch off,
develop and merge back.
I did that with the policy providers and other security stuff then
merged, the way I merged brought all the change logs and commits made
while creating that code.
For small changes commits are
I'm confident the code in qa_refactoring will pass River 2.2.0's qa test
suite (or 2.2.1 for that matter), qa_refactoring should be ready this
weekend or the next, once I can be sure I can no longer cause
concurrency test failures.
Some tests may fail due to thread visibility issues when run
There's a tool called Gerrit, it's uses git, reviewers can view two code
versions sided by side from a web page, it also allows reviewer comments.
Is anyone familiar with these code review tools?
The issue doesn't appear to be the code; it appears that the current
development framework doesn't
If we dont have a process wrt RTC, then it doesn't really matter what tools or
SCMs you bring into the fold, it wont help. On most projects I've been on we
typically create a branch for feature development or per Jira issue that
represents a story or epic. When you consider your work done, all
I disagree that scm choice is orthogonal to workflow and policy because
some scms and related tooling support a given workflow much better than
others. It's the combination of a given scm and workflow that should be
evaluated versus others. I have a great deal of respect for the Apache
Foundation
Hi all:
Peter brings up an excellent point here, something that I've found
troubling in this release process. It is exceedingly difficult to
identify what changes have been made to the code, and why, or to trace
changes to JIRA issues. By extension it's very hard to identify which
revisions
