svn commit: r350089 - head

[Cy Schubert]

Those were my initial thoughts at the time. If an MFC is performed, its associated RELNOTES should also be committed. If committing an MFC, it makes sense to commit the same RELNOTES text through an MFC as well.



On November 8, 2019 11:26:18 AM MST, "Rodney W. Grimes" <freebsd at gndrsh.dnsmgr.net> wrote:
>> On Wed, Jul 17, 2019 at 07:09:06PM +0000, Mark Johnston wrote:
>> > Author: markj
>> > Date: Wed Jul 17 19:09:05 2019
>> > New Revision: 350089
>> > URL: https://svnweb.freebsd.org/changeset/base/350089
>> > 
>> > Log:
>> >   Add an initial RELNOTES file.
>> >   
>> >   The intent is to provide a convenient location to document
>changes
>> >   that are relevant to users of binary FreeBSD distributions, in
>contrast
>> >   with UPDATING, which exists to document caveats for users who
>build
>> >   FreeBSD from source.
>> >   
>> >   This complements the "Relnotes:" tag in commit messages by
>providing a
>> >   place to document the change in more detail, or in case a
>"Relnotes:"
>> >   tag was accidentally omitted.  In particular, "Relnotes:" should
>be
>> >   used if you do not intend to document the change in RELNOTES for
>some
>> >   reason.
>> >   
>> >   Changes to the file should not be MFCed.  For now the file will
>exist
>> >   only in head, but may be updated via direct commits to stable
>branches
>> >   depending on how things go.
>> >   
>> 
>> I had to go look at the original thread to remind myself about this,
>but
>> regarding not MFCing changes from head to stable branches, I think
>there
>> may have been some confusion in the discussion.
>> 
>> By "changes should not be MFCed", at least based on my recollection
>of
>> how the conversation was going, I (at least) meant "not MFCed, but
>> committed as a direct commit to stable branches."  In other words,
>> merging the RELNOTES change from head to stable/X does not really
>make
>> sense, as the revision numbers will have changed, and would
>inevitably
>> cause merge conflicts.
>> 
>> Now that 12.1 is out, maybe we can expand the idea of this file into
>> stable/12 and even stable/11.  One additional idea that came to mind
>is
>> with the formatting for stable branches.
>> 
>> For example, in head, there is:
>> 
>>   rNNNNNN:
>>           The foo(8) utility was added.
>> 
>> For stable branches, I would propose the format of:
>> 
>>  rNNNNNM, MFC of rNNNNNN:
>>           The foo(8) utility was added.
>> 
>> Thoughts?
>
>My thoughs originally on this was that when a release noteable item
>is merged from head to stable the exact related commit to RELNOTES
>should also be merged unaltered.
>
>The RELNOTES file should state that revision numbers in this file
>are ^/HEAD revision numbers, and that a merge serach may be needed
>to find the branch verson of the MFC.
>
>The ^/head RELNOTES file should be trunkated to length 0 when a .0
>branch is crated POST branch creation, thus all the relevant
>entries are in the file on the new branch and can grow as things
>are merged to it.  Thus keeps the RELNOTES file in a state that
>matches the branch as far as entires, just the Rxxxxx is referential
>to when the entry was created relative to head.
>
>> Glen
>-- 
>Rod Grimes                                                
>rgrimes at freebsd.org

-- 
Pardon the typos and autocorrect, small keyboard in use. 
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: https://www.FreeBSD.org

The need of the many outweighs the greed of the few.

Sent from my Android device with K-9 Mail. Please excuse my brevity.