[Gluster-devel] [Gluster-Maintainers] Release 4.1: LTM release targeted for end of May

[Aravinda]

On 03/13/2018 04:00 PM, Shyam Ranganathan wrote:
> On 03/13/2018 03:53 AM, Sankarshan Mukhopadhyay wrote:
>> On Tue, Mar 13, 2018 at 1:05 PM, Pranith Kumar Karampuri
>> <pkarampu at redhat.com> wrote:
>>>
>>> On Tue, Mar 13, 2018 at 7:07 AM, Shyam Ranganathan <srangana at redhat.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> As we wind down on 4.0 activities (waiting on docs to hit the site, and
>>>> packages to be available in CentOS repositories before announcing the
>>>> release), it is time to start preparing for the 4.1 release.
>>>>
>>>> 4.1 is where we have GD2 fully functional and shipping with migration
>>>> tools to aid Glusterd to GlusterD2 migrations.
>>>>
>>>> Other than the above, this is a call out for features that are in the
>>>> works for 4.1. Please *post* the github issues to the *devel lists* that
>>>> you would like as a part of 4.1, and also mention the current state of
>>>> development.
>>>>
>>>> Further, as we hit end of March, we would make it mandatory for features
>>>> to have required spec and doc labels, before the code is merged, so
>>>> factor in efforts for the same if not already done.
>>>
>>> Could you explain the point above further? Is it just the label or the
>>> spec/doc
>>> that we need merged before the patch is merged?
>>>
>> I'll hazard a guess that the intent of the label is to indicate
>> availability of the doc. "Completeness" of code is being defined as
>> including specifications and documentation.
> As Sankarshan gleaned, spec and doc should be merged/completed before
> the code is merged, as otherwise smoke will not vote a +1 on the same.

I have following suggestion for managing release notes. Let me know
if this can be included in automation document.


If a Github issue used in Commit message as "Fixes: #<id>" then Smoke
test should fail if patch does not contain `$SRC/release-notes/<issue>.md`
(if `$SRC/release-notes/<issue>.md` not already exists in codebase)

On branching, delete all these release-notes from Master branch and start
fresh. Release branch now contains these notes for all the features
went in after the last release. Release manager's job is to merge all
these release notes into single release notes document.

We can restrict on the format of release-note as,

     First Line is Title
     Tags: component-name, keywords etc
     --
     Description about the feature, example, links etc

If all patches are submitted with `Updates` instead of `Fixes`, then
Issue can't be closed without submitting patch with release-note.


>
>> That said, I'll wait for Shyam to be more elaborate on this.
>>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel


-- 
regards
Aravinda VK