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@xxxxxxxxxx> wrote:
On Tue, Mar 13, 2018 at 7:07 AM, Shyam Ranganathan <srangana@xxxxxxxxxx>
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@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
--
regards
Aravinda VK
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
