|
From: <sv...@va...> - 2013-12-01 12:42:40
|
Author: philippe
Date: Sun Dec 1 12:42:30 2013
New Revision: 13739
Log:
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.
Added:
trunk/README_DEVELOPERS_processes
Modified:
trunk/NEWS
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Sun Dec 1 12:42:30 2013
@@ -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)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Added: trunk/README_DEVELOPERS_processes
==============================================================================
--- trunk/README_DEVELOPERS_processes (added)
+++ trunk/README_DEVELOPERS_processes Sun Dec 1 12:42:30 2013
@@ -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 ?
|