Create 3.10.0 section in NEWS, add (first draft of) README_DEVELOPERS_processes

* add the new sections for next 3.10.0 release in NEWS.
* add file README_DEVELOPERS_processes.

As discussed on valdev and documented in README_DEVELOPERS_processes,
the idea is to document fixed bugs or new features in NEWS together
with the commit fixing/implementing these.

Looking at SVN, the below bugs should be added in 3.10.0 fixed bugs.
I will add them in NEWS shortly.

Thanks

Philippe


r13709 | tom | 2013-11-01 11:46:28 +0100 (Fri, 01 Nov 2013) | 2 lines

Clear direction flag after tests on amd64. BZ#326983.

r13712 | weidendo | 2013-11-12 16:32:58 +0100 (Tue, 12 Nov 2013) | 17 lines

Fix bug 327238.

 assertion failure in Callgrind: bbcc.c:585 (vgCallgrind_setup_bbcc):
 Assertion 'passed <= last_bb->cjmp_count' failed

r13715 | mjw | 2013-11-20 12:54:38 +0100 (Wed, 20 Nov 2013) | 5 lines

dwz compressed alternate .debug_info and .debug_str not read correctly.

Bug #327837. The buildid from the .gnu_debugaltlink section was parsed
incorrectly (from the wrong offset). Causing the debug alt file not to
be found.

r13718 | mjw | 2013-11-24 18:19:35 +0100 (Sun, 24 Nov 2013) | 5 lines

Bug 327916 - DW_TAG_typedef may have no name

We already accepted DW_TAG_typedef without a name for Ada. But g++ for
OpenMP can also emit such nameless DW_TAG_typedefs. Just accept them.
Also fix up anonymous enum and typedef printing in tytypes.c.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13739

NEWS

@@ -1,3 +1,30 @@
+Release 3.10.0 (?? ?????? 201?)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+3.10.0 is not yet released.
+
+* ================== PLATFORM CHANGES =================
+
+* ==================== TOOL CHANGES ====================
+
+* Helgrind:
+
+* ==================== OTHER CHANGES ====================
+
+* ==================== FIXED BUGS ====================
+
+The following bugs have been fixed or resolved.  Note that "n-i-bz"
+stands for "not in bugzilla" -- that is, a bug that was reported to us
+but never got a bugzilla entry.  We encourage you to file bugs in
+bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
+than mailing the developers (or mailing lists) directly -- bugs that
+are not entered into bugzilla tend to get forgotten about or ignored.
+
+To see details of a given bug, visit
+  https://bugs.kde.org/show_bug.cgi?id=XXXXXX
+where XXXXXX is the bug number as listed below.
+
+
+
 
 Release 3.9.0 (31 October 2013)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

README_DEVELOPERS_processes

@@ -0,0 +1,94 @@
+This file documents various "processes" that are used by Valgrind
+developers for development and release activities.
+This file contains one section for each process.
+A summary of each process is given here. Each process is described
+more in details afterwards.
+
+
+* Update of the NEWS file: NEWS describes fixed bugs and new features.
+  It is updated and committed together with the code fixing the bug/implementing
+  the feature.
+
+* Major release production: 
+  See docs/internals/release-HOWTO.txt (currently a bit out of date)
+
+* Minor/correction release production: TBD
+
+
+Processes detailed descriptions:
+
+Update of the NEWS file.
+========================
+  The NEWS file gives for each release:
+    - the list of fixed bugs,
+    - a short description of each functional change,
+    - a short description of each technical change impacting the users.
+  
+  The update of the NEWS file should be committed together with the
+  code change (or as part of the last committed change) that fixes the
+  bug or implements the new feature/technical change.
+  The documentation (e.g. user manual) should also be committed as part of
+  the code change.
+
+  Fixing a bug
+  ------------
+  When fixing a bug, add a line in the 'FIXED BUGS' section of
+  the NEWS file.  Keep the list of bugs sorted by bugzilla entry number.
+
+  Once you have commit the change, update the bug status in bugzilla,
+  adding in the comment the revision number of the commit fixing the bug.
+
+  If a bug is not entered in bugzilla (not encouraged), use "n-i-bz"
+  and add the bug line at the end of the bug list.
+
+  The file docs/internals/X_Y_BUGSTATUS.txt (where X_Y is the last
+  major release e.g. 3_9) contains information/statuses for some bugs.
+  If a bug is fixed, remove the (possible) bug info from this file.
+
+  Implementing a change
+  ---------------------
+  When implementing a functional or 'user impacting' technical change,
+  add a short description of the change in the relevant sub-section
+  (e.g. TOOL CHANGES, PLATFORM CHANGES, ...).
+
+
+  Some special cases:
+  -------------------
+  Some bugs or changes only touch the VEX SVN repository, so it is not
+  possible to commit the NEWS change together with the code changes.
+  In such a case, first commit the VEX change. Then just after, commit
+  the NEWS change. In the bugzilla status, reference (at least) the Valgrind
+  revision number.
+
+  Some changes or bug fixes are very big and might be implemented over
+  a significant period. In such a case, update the NEWS as part of the
+  final commit.
+  If relevant, you might already update the NEWS file as part of
+  earlier commits, using the word 'PARTIAL' to indicate that the change or
+  bug fix is not complete yet.
+
+  Some bugs are reported more than once in bugzilla.
+  Also document in NEWS that such duplicated bugs have been fixed, using a line
+  such as:
+     308333 == 307106
+  to indicate that the bug 308333 is a duplicate of 307106, and was thus
+  fixed in the commit that fixed 307106.
+  Change also the status of the duplicated bug  in bugzilla,
+  indicating in the comment the commit revision that fixed the 'master bug'.
+
+
+
+Minor/correction release:
+=========================
+Describe here how to do changes and bug fixed in a minor (correction) release
+and how/when to merge the branch to the trunk.
+
+Proposal to be discussed:
+When a bug is fixed on the branch, the NEWS file is updated on the branch
+(i.e. a 3.9.1 section is created if needed).
+
+When often to merge the branch to trunk ?
+  after each fix ?
+  just after the correction release is produced ?
+
+How is the branch merged to the trunk ?