Re: proposal for branch patches after first release

[Doug Evans <dje at google dot com>]

On Thu, Nov 29, 2012 at 6:14 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> Hello,
>
> I would like to propose a change in our procedures when a patch gets
> checked in a release branch.  This would only concern changes that
> are made after the first release off that branch is made.
>
> For instance, once we've made the GDB 7.6 release, any new patch on
> the gdb_7_6-branch would be affected by this proposal.
>
> The problem is the following:
>   - The time it took to assemble the GDB 7.5.1 tarballs, and put
>     them on both sourceware.org and gnu.org was under 30mins.
>   - The amount of time it takes me to write the associated announcement
>     was over 2 hours.
>
> The reason for taking this amount of time is that I'd like to tell
> everyone what it is exactly that 7.5.1 fixes over 7.5. For the first
> major release (Eg 7.5), I can use the NEWS file, which provides
> enough information. But for the 7.5.1, I have nothing other than
> the revision log. So I went through every single commit, and tried
> to write a small description for each commit (I skipped testsuite
> changes to save time).
>
> The proposal:
>
>     Once a release has been published off a branch, any patch merged
>     on the release branch requires a corresponding update in the
>     NEWS file.
>
> I think that it makes sense regardless of the problem that affects me
> because, if someone feels strongly enough that the problem should
> be fixed in a subsequent corrective release, I think it deserves
> a NEWS entry. Also, it will allow users to refer to the NEWS files
> to determine what exactly the corrective release fixes. And it will
> save me tons of time because I can now write the annoucement using
> the information there.
>
> Technically, I think we'll want the NEWS update to be checked in
> both HEAD + branch.  But I don't think we can add the entries in
> the HEAD branch right away, because we don't know ahead of time
> whether a corrective release will be made or not.  So what I propose
> is the following: The NEWS entry should be checked in the branch.
> And the Release Manager (me) will add those entries to the HEAD
> when publishing the new release.

If it were me I'd just diff the ChangeLogs, write something based on
that (but not worry about being too detailed if it'll take too much
time to dig deeper), require bug numbers or whatever to be in the
ChangeLogs,
and leave it at that.