On 2/04/2013 7:51 PM, Dennis Reedy wrote:
On Apr 2, 2013, at 338AM, Peter Firmstone wrote:
The formatting didn't work out, I'll create a Jira issue to discuss.
Patricia's done a great job detailing the dependencies and issues with
TaskManager's Task implementations.
I recall a list discussion from the original Sun developers who had intended to
replace TaskManager, the runAfter method has issues.
Being so prevalent, it's quite possible that TaskManager is causing issues and
it might also explain why as performance improves more issues arise.
If a task completes before another task which it's supposed to runAfter but
isn't present in the queue; that could explain some issues.
I much prefer idempotent code myself.
This could take some effort to fix, any volunteers?
Dennis are you able to continue with your 2.2.1 branch release?
At this point I am unsure what branch to base the 2.2.1 release off of.
The 2.2.0 release, it might benefit from backports of synchronization
fixes that improve correctness, but not performance, if some volunteers
can diff the qa-refactoring branch and the 2.2.0 branch, there are
numerous simple synchronization fixes.
Additionally, what are the steps necessary to create a release?
1. First create a branch of 2.2.0, call it 2.2.1.
2. Developers will need to update their developer keys in the keys file.
3. Backport sensible synchronization fixes for existing classes
(don't get carried away, just essentials).
4. Definitely fix LookupLocator serialization which was accidentally
broken (similar to Levels an additional field was added that
should have been transient), look at the qa-refactoring release
for the fix, which is backward compatible with all releases.
5. Run the rat report tool, there should be a shell script for that,
it checks for licence compliance.
6. Increment version numbers (find 2.2.0 and replace with 2.2.1, but
don't replace all occurrences of 2.2.0, this has to be inspected
manually).
7. Update the release documentation.
8. Post pre release artifacts for wider community testing.
9. Wait about two weeks for feedback.
10. Then vote on the release artifacts.
11. Publish the artifacts.
12. I have some handwritten notes about the release process, they're
about 200km away from where I'm presently working, I should be
able to access them on the weekend.
This release will probably only be supportable on Linux and Solaris,
Windows only passed all tests recently, Windows users will want to wait
until we sort out the concurrency issues (ironically I haven't
reproduced any concurrency test failures on Windows, maybe the Windows
jvm is less aggressive with optimisations, or its the hardware being
tested).
For now I'm going to continue focusing my efforts on the qa-refactoring
branch, as it's been over three years since 2.2.0 was released, I'm
close and don't want to delay 2.3.0 much longer. This is a big release
which has culminated in 3 years of ongoing efforts.
In future I'd like to break River up into separate smaller components
that are far easier to release, I don't think I can do it again for
another 3 years, but we can save that discussion until after we've
released so we don't get distracted. I would like to see a more agile
release process.
Regards,
Peter.
