[Gluster-devel] Release 3.11: RC1 is tagged!
Shyam
srangana at redhat.com
Wed May 24 16:32:01 UTC 2017
On 05/24/2017 12:21 PM, Amar Tumballi wrote:
>
>
> On Wed, May 24, 2017 at 7:16 PM, Shyam <srangana at redhat.com
> <mailto:srangana at redhat.com>> wrote:
>
> On 05/24/2017 02:05 AM, Amar Tumballi wrote:
>
> Was looking at Milestone in Github:
> https://github.com/gluster/glusterfs/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3.11+%28STM%29%22
> <https://github.com/gluster/glusterfs/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3.11+%28STM%29%22>
>
> It is still showing many things as open. I see some of them are
> done for
> sure. Please feel free to mark them as 'Closed'. Ideal to have
> commit id
> (from git log) while closing.
>
>
> This is intentional Amar. The idea being once we have delivered all
> pieces we can mark if as closed.
>
> All pieces are design+code+documentation, IOW commits for
> gluster-specs, glusterfs, and release notes/glusterdocs commits.
>
> Once we have that in place, we can close the issue (even prior to
> the actual release). If not post the final release, I will cleanup
> the items in the lane as appropriate.
>
> Thoughts?
>
>
> Thanks for clarifying. I was thinking of PR / patch having 'fixes #NNN',
> which means automatically an issue would be closed. Hence the question.
Exactly, so let's say the last piece is the release notes, then that
commit can/should contain the 'fixes #NNN' message and things will get
done automatically.
>
> Makes sense to keep it open if there is a piece pending from the
> feature, no issues there, rather that is the proper way.
>
> +1.
>
> Regards,
> Amar
>
>
>
> -Amar
>
> On Tue, May 23, 2017 at 7:43 PM, Shyam <srangana at redhat.com
> <mailto:srangana at redhat.com>
> <mailto:srangana at redhat.com <mailto:srangana at redhat.com>>> wrote:
>
> On 05/23/2017 09:27 AM, Shyam wrote:
>
> A note on release notes:
>
> 1) release-notes are a part of the code repository,
> hence use
> gerrit to
> submit your changes to the release notes
>
>
> Here is an example: https://review.gluster.org/#/c/17372/
> <https://review.gluster.org/#/c/17372/>
> <https://review.gluster.org/#/c/17372/
> <https://review.gluster.org/#/c/17372/>>
>
>
> 2) Also, as we use github for features, and most content
> that
> would be
> submitted to the release notes would be for features,
> use the
> same issue
> # as the code submission to submit the release notes
> changes as
> well.
>
> For example, to submit release notes for "Enhance handleops
> readdirplus
> operation to return handles along with dirents", use
> "Updates:
> #174" in
> the release notes commit message. There is *no* *need*
> for a BUG
>
> The advantages of this are that, we can track all
> submissions
> for said
> feature from the same issue in github (all submissions
> refers to
> feature-spec, code, release-notes, documentation changes).
>
>
> Here is how it gets reflected in the issue:
>
> https://github.com/gluster/glusterfs/issues/174#issuecomment-303403925
> <https://github.com/gluster/glusterfs/issues/174#issuecomment-303403925>
>
> <https://github.com/gluster/glusterfs/issues/174#issuecomment-303403925
> <https://github.com/gluster/glusterfs/issues/174#issuecomment-303403925>>
>
>
>
> 3) If a release-note is being added for a non-feature
> (say a warning
> about some feature, or that some functionality is still
> experimental,
> IOW things that do not have github issues), then use a
> bug for the
> submission as before.
>
> Thanks,
> Shyam
>
> "Releases are made better together"
>
> On 05/22/2017 09:37 PM, Shyam wrote:
>
> Hi,
>
> We just finished tagging release 3.11.0 RC1, that
> contains a
> few more
> fixes post 3.11.0 RC0.
>
> Packages for the same will be made available soon.
>
> *Attention* contributors:
> - We still are to see any updates to the release-notes
> [2], we have a
> week before the release, please update the release notes
> appropriately
>
> *Attention* all:
> - Any pending bugs that are critical to the
> release need
> to be marked
> as a blocker against [1] and we have about a week
> left to
> close out
> these bugs!
>
> Thanks,
> Shyam
>
> [1] Tracker BZ for 3.11.0 blockers:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.11.0
> <https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.11.0>
>
> <https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.11.0
> <https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.11.0>>
>
> [2] Release notes:
>
> https://github.com/gluster/glusterfs/blob/release-3.11/doc/release-notes/3.11.0.md
> <https://github.com/gluster/glusterfs/blob/release-3.11/doc/release-notes/3.11.0.md>
>
> <https://github.com/gluster/glusterfs/blob/release-3.11/doc/release-notes/3.11.0.md
> <https://github.com/gluster/glusterfs/blob/release-3.11/doc/release-notes/3.11.0.md>>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> <mailto:Gluster-devel at gluster.org>
> <mailto:Gluster-devel at gluster.org
> <mailto:Gluster-devel at gluster.org>>
>
> http://lists.gluster.org/mailman/listinfo/gluster-devel
> <http://lists.gluster.org/mailman/listinfo/gluster-devel>
>
> <http://lists.gluster.org/mailman/listinfo/gluster-devel
> <http://lists.gluster.org/mailman/listinfo/gluster-devel>>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
> <mailto:Gluster-devel at gluster.org
> <mailto:Gluster-devel at gluster.org>>
> http://lists.gluster.org/mailman/listinfo/gluster-devel
> <http://lists.gluster.org/mailman/listinfo/gluster-devel>
> <http://lists.gluster.org/mailman/listinfo/gluster-devel
> <http://lists.gluster.org/mailman/listinfo/gluster-devel>>
>
>
>
>
> --
> Amar Tumballi (amarts)
>
>
>
>
> --
> Amar Tumballi (amarts)
More information about the Gluster-devel
mailing list