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

[Shyam Ranganathan]

On 03/26/2018 12:33 AM, Aravinda wrote:
>>> Also want to propose that,  we include a release
>>> of http://github.com/gluster/gluster-health-report with 4.1, and make
>>> the project more usable.
>> In the theme of including sub-projects that we want to highlight, what
>> else should we tag a release for or highlight with 4.1?
>>
>> @Aravinda, how do you envision releasing this with 4.1? IOW, what
>> interop tests and hence sanity can be ensured with 4.1 and how can we
>> tag a release that is sane against 4.1?
> 
> Some more changes required to make it work with Gluster 4.x, I will work
> on fixing those issues and test scripts.
> 
> I have not yet started with Packaging for Fedora/Ubuntu. As of now
> available as `pip install`. Let me know if that is fine with 4.1 release.

Aravinda, what issue in the gluster-health-report repo should I track
for closure?

Thanks,
Shyam
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Shyam Ranganathan]

On 03/23/2018 09:18 AM, Niels de Vos wrote:
> On Fri, Mar 23, 2018 at 10:17:28AM +0530, Amar Tumballi wrote:
>> On Thu, Mar 22, 2018 at 11:34 PM, Shyam Ranganathan 
>> wrote:
>>
>>> On 03/21/2018 04:12 AM, Amar Tumballi wrote:
 Current 4.1 project release lane is empty! I cleaned it up, because I
 want to hear from all as to what content to add, than add things
>>> marked
 with the 4.1 milestone by default.


 I would like to see we have sane default values for most of the options,
 or have group options for many use-cases.
>>>
>>> Amar, do we have an issue that lists the use-cases and hence the default
>>> groups to be provided for the same?
>>>
>>>
>> Considering group options' task is more in glusterd2, the issue is @
>> https://github.com/gluster/glusterd2/issues/614 &
>> https://github.com/gluster/glusterd2/issues/454
> 
> Maybe somehow link those with
> https://github.com/gluster/glusterfs/issues/294 ?

All done. Updated the 4.1 release board with the GD2 issues and posted a
comment linking glusterfs issue with the same.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Aravinda]

On 03/22/2018 11:34 PM, Shyam Ranganathan wrote:

On 03/21/2018 04:12 AM, Amar Tumballi wrote:

 Current 4.1 project release lane is empty! I cleaned it up, because I
 want to hear from all as to what content to add, than add things marked
 with the 4.1 milestone by default.


I would like to see we have sane default values for most of the options,
or have group options for many use-cases.

Amar, do we have an issue that lists the use-cases and hence the default
groups to be provided for the same?


Also want to propose that,  we include a release
of http://github.com/gluster/gluster-health-report with 4.1, and make
the project more usable.

In the theme of including sub-projects that we want to highlight, what
else should we tag a release for or highlight with 4.1?

@Aravinda, how do you envision releasing this with 4.1? IOW, what
interop tests and hence sanity can be ensured with 4.1 and how can we
tag a release that is sane against 4.1?


Some more changes required to make it work with Gluster 4.x, I will work 
on fixing those issues and test scripts.


I have not yet started with Packaging for Fedora/Ubuntu. As of now 
available as `pip install`. Let me know if that is fine with 4.1 release.





Also, we see that some of the patches from FB branch on namespace and
throttling are in, so we would like to call that feature out as
experimental by then.

I would assume we track this against
https://github.com/gluster/glusterfs/issues/408 would that be right?
___
maintainers mailing list
maintain...@gluster.org
http://lists.gluster.org/mailman/listinfo/maintainers



--
regards
Aravinda VK

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Niels de Vos]

On Fri, Mar 23, 2018 at 10:17:28AM +0530, Amar Tumballi wrote:
> On Thu, Mar 22, 2018 at 11:34 PM, Shyam Ranganathan 
> wrote:
> 
> > On 03/21/2018 04:12 AM, Amar Tumballi wrote:
> > > Current 4.1 project release lane is empty! I cleaned it up, because I
> > > want to hear from all as to what content to add, than add things
> > marked
> > > with the 4.1 milestone by default.
> > >
> > >
> > > I would like to see we have sane default values for most of the options,
> > > or have group options for many use-cases.
> >
> > Amar, do we have an issue that lists the use-cases and hence the default
> > groups to be provided for the same?
> >
> >
> Considering group options' task is more in glusterd2, the issue is @
> https://github.com/gluster/glusterd2/issues/614 &
> https://github.com/gluster/glusterd2/issues/454

Maybe somehow link those with
https://github.com/gluster/glusterfs/issues/294 ?

Niels
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Amar Tumballi]

On Thu, Mar 22, 2018 at 11:34 PM, Shyam Ranganathan 
wrote:

> On 03/21/2018 04:12 AM, Amar Tumballi wrote:
> > Current 4.1 project release lane is empty! I cleaned it up, because I
> > want to hear from all as to what content to add, than add things
> marked
> > with the 4.1 milestone by default.
> >
> >
> > I would like to see we have sane default values for most of the options,
> > or have group options for many use-cases.
>
> Amar, do we have an issue that lists the use-cases and hence the default
> groups to be provided for the same?
>
>
Considering group options' task is more in glusterd2, the issue is @
https://github.com/gluster/glusterd2/issues/614 &
https://github.com/gluster/glusterd2/issues/454


> >
> > Also want to propose that,  we include a release
> > of http://github.com/gluster/gluster-health-report with 4.1, and make
> > the project more usable.
>
> In the theme of including sub-projects that we want to highlight, what
> else should we tag a release for or highlight with 4.1?
>
> @Aravinda, how do you envision releasing this with 4.1? IOW, what
> interop tests and hence sanity can be ensured with 4.1 and how can we
> tag a release that is sane against 4.1?
>
> >
> > Also, we see that some of the patches from FB branch on namespace and
> > throttling are in, so we would like to call that feature out as
> > experimental by then.
>
> I would assume we track this against
> https://github.com/gluster/glusterfs/issues/408 would that be right?
>

Yes, that is right. sorry for missing out the github issues in the first
email.

-Amar
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Shyam Ranganathan]

On 03/21/2018 04:12 AM, Amar Tumballi wrote:
> Current 4.1 project release lane is empty! I cleaned it up, because I
> want to hear from all as to what content to add, than add things marked
> with the 4.1 milestone by default.
> 
> 
> I would like to see we have sane default values for most of the options,
> or have group options for many use-cases.

Amar, do we have an issue that lists the use-cases and hence the default
groups to be provided for the same?

> 
> Also want to propose that,  we include a release
> of http://github.com/gluster/gluster-health-report with 4.1, and make
> the project more usable.

In the theme of including sub-projects that we want to highlight, what
else should we tag a release for or highlight with 4.1?

@Aravinda, how do you envision releasing this with 4.1? IOW, what
interop tests and hence sanity can be ensured with 4.1 and how can we
tag a release that is sane against 4.1?

> 
> Also, we see that some of the patches from FB branch on namespace and
> throttling are in, so we would like to call that feature out as
> experimental by then.

I would assume we track this against
https://github.com/gluster/glusterfs/issues/408 would that be right?
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Mohammed Rafi K C]

Hi Shyam,

Myself and Sunny are working on snapshot integration effort to gd2. So
we wanted to propose the feature for 4.1,

issue : https://github.com/gluster/glusterd2/issues/461

status : There are were two patch sets targeted, one is merged, one is
under review. One is under development.


Regards

Rafi KC



>
> On Wed, Mar 21, 2018 at 2:05 PM, Ravishankar N  > wrote:
>
>
>
> On 03/20/2018 07:07 PM, Shyam Ranganathan wrote:
>
> On 03/12/2018 09:37 PM, Shyam Ranganathan 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.
>
> Thanks for those who responded. The github lane and milestones
> for the
> said features are updated, request those who mentioned issues
> being
> tracked for 4.1 check that these are reflected in the project
> lane [1].
>
> I have few requests as follows that if picked up would be a
> good thing
> to achieve by 4.1, volunteers welcome!
>
> - Issue #224: Improve SOS report plugin maintenance
>- https://github.com/gluster/glusterfs/issues/224
> 
>
> - Issue #259: Compilation warnings with gcc 7.x
>- https://github.com/gluster/glusterfs/issues/259
> 
>
> - Issue #411: Ensure python3 compatibility across code base
>- https://github.com/gluster/glusterfs/issues/411
> 
>
> - NFS Ganesha HA (storhaug)
>- Does this need an issue for Gluster releases to track?
> (maybe packaging)
>
> I will close the call for features by Monday 26th Mar, 2018.
> Post this,
> I would request that features that need to make it into 4.1 be
> raised as
> exceptions to the devel and maintainers list for evaluation.
>
>
> Hi Shyam,
>
> I want to add https://github.com/gluster/glusterfs/issues/363
>  also for 4.1. It
> is not a new feature but rather an enhancement to a volume option
> in AFR. I don't think it can qualify as a bug fix, so mentioning
> it here just in case it needs to be tracked too. The (only) patch
> is undergoing review cycles.
>
> Regards,
> Ravi
>
>
> 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.
>
> Current 4.1 project release lane is empty! I cleaned it
> up, because I
> want to hear from all as to what content to add, than add
> things marked
> with the 4.1 milestone by default.
>
> [1] 4.1 Release lane:
> https://github.com/gluster/glusterfs/projects/1#column-1075416
> 
>
> Thanks,
> Shyam
> P.S: Also any volunteers to shadow/participate/run 4.1 as
> a release owner?
>
> Calling this out again!
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org 
> http://lists.gluster.org/mailman/listinfo/gluster-devel
> 
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org 
> http://lists.gluster.org/mailman/listinfo/gluster-devel
> 
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org 
> http://lists.gluster.org/mailman/listinfo/gluster-devel
> 
>
>
>
>
> -- 
> Thanks and Regards,
> Kotresh H R
>
>
> 

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

[Amar Tumballi]

On Tue, Mar 13, 2018 at 7:07 AM, Shyam Ranganathan 
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.
>
> Current 4.1 project release lane is empty! I cleaned it up, because I
> want to hear from all as to what content to add, than add things marked
> with the 4.1 milestone by default.
>
>
I would like to see we have sane default values for most of the options, or
have group options for many use-cases.

Also want to propose that,  we include a release of
http://github.com/gluster/gluster-health-report with 4.1, and make the
project more usable.

Also, we see that some of the patches from FB branch on namespace and
throttling are in, so we would like to call that feature out as
experimental by then.

Regards,
Amar


> Thanks,
> Shyam
> P.S: Also any volunteers to shadow/participate/run 4.1 as a release owner?
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>



-- 
Amar Tumballi (amarts)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Amar Tumballi]

Sorry, couldn't respond earlier.


On Fri, Mar 16, 2018 at 7:14 AM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Wed, Mar 14, 2018 at 8:27 PM, Amye Scavarda  wrote:
>
>> Responding on the architects question:
>>
>> On Tue, Mar 13, 2018 at 9:57 PM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>


 On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi 
 wrote:

> >>
>> >> 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.
>>
>>
> I believe this has originated from maintainers meeting agreements [1]
> . The proposal to make a spec and documentation mandatory was submitted 3
> months back and is documented, and submitted for comment @
> https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieI
> yiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing
>
>
 Thanks! This clears almost all the doubts I had :).

>>>
>>> The document above refers to Architects - "Now Architects are approved
>>> to revert a patch which violates by either not having github issue nor
>>> bug-id, or uses a bug-id to get the feature in etc."
>>>
>>> Who are they? What are their responsibilities?
>>>
>>
>> In our last reboot of the maintainers readme file, we expanded the
>> architects role:
>> https://github.com/gluster/glusterfs/blob/master/MAINTAINERS
>> General Project Architects
>> --
>> M: Jeff Darcy 
>> M: Vijay Bellur 
>> P: Amar Tumballi 
>> P: Pranith Karampuri 
>> P: Raghavendra Gowdappa 
>> P: Shyamsundar Ranganathan 
>> P: Niels de Vos 
>> P: Xavier Hernandez 
>> What should we work to make more clear about this?
>>
>
> Wow, embarrassing, I am an architect who doesn't know his
> responsibilities. Could you let me know where I could find them?
>

We had some email conversations at this thread: http://lists.gluster.
org/pipermail/gluster-devel/2017-March/052321.html

Final version of the discussion is captured here: https://hackmd.io/s/
SkwiZd4qe. and the patch for the changes was merged
with more than 20 votes (including yours) on it @
https://review.gluster.org/#/c/17583

Regards,
Amar




>
>
>> - amye
>>
>>
>>>
>>>


> The idea is, if the code is going to be released, it should have
> relevant documentation for users to use it, otherwise, it doesn't matter 
> if
> the feature is present or not. If the feature is 'default', and there is 
> no
> documentation required, just mention it, so the flags can be given. Also,
> if there is no general agreement about the design, it doesn't make sense 
> to
> merge a feature and then someone has to redo things.
>
> For any experimental code, which we want to publish for other
> developers to test, who doesn't need documentation, we have 'experimental'
> branch, which should be used for validation.
>

>  [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-Dece
> mber/054070.html
>



 --
 Pranith

>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Amye Scavarda | a...@redhat.com | Gluster Community Lead
>>
>
>
>
> --
> Pranith
>



-- 
Amar Tumballi (amarts)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Raghavendra Gowdappa]

Proposing efforts of adding metrics to various perf xlators. Following are
links to github issues:

https://github.com/gluster/glusterfs/issues/422
https://github.com/gluster/glusterfs/issues/423
https://github.com/gluster/glusterfs/issues/424
https://github.com/gluster/glusterfs/issues/425
https://github.com/gluster/glusterfs/issues/426
https://github.com/gluster/glusterfs/issues/427
https://github.com/gluster/glusterfs/issues/428
https://github.com/gluster/glusterfs/issues/429

regards,
Raghavendra

On Wed, Mar 21, 2018 at 10:29 AM, Jiffin Tony Thottan 
wrote:

> Hi,
>
> I would like to (rep)propose lease support https://github.com/gluster/glu
> sterfs/issues/350
>
> Current status
>
> Following patches posted :
>
> https://review.gluster.org/#/c/19568/ -- gfapi recall lease
>
> https://review.gluster.org/#/c/12496/ -- test case
>
> https://review.gluster.org/#/c/11721/ -- add lease fop for afr
>
> need to sent a patch for adding lease fop in ec
>
> + I have patch for bug fixes in current lease implementation
>
> Regards,
>
> Jiffin
>
>
> On Tuesday 13 March 2018 07:07 AM, Shyam Ranganathan 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.
>>
>> Current 4.1 project release lane is empty! I cleaned it up, because I
>> want to hear from all as to what content to add, than add things marked
>> with the 4.1 milestone by default.
>>
>> Thanks,
>> Shyam
>> P.S: Also any volunteers to shadow/participate/run 4.1 as a release owner?
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Shyam Ranganathan]

On 03/14/2018 12:05 PM, Aravinda wrote:
> On 03/14/2018 05:38 PM, Shyam Ranganathan wrote:
>> On 03/14/2018 02:40 AM, Aravinda wrote:
>>> I have following suggestion for managing release notes. Let me know
>>> if this can be included in automation document.
>> Aravinda, I assume this is an additional suggestion, orthogonal to the
>> current discussion around spec and docs, right?
> Yes. Sorry about that.

No worries, setting the context was important (to me).

>>
>>>
>>> If a Github issue used in Commit message as "Fixes: #" then Smoke
>>> test should fail if patch does not contain
>>> `$SRC/release-notes/.md`
>>> (if `$SRC/release-notes/.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.
>> Most of the above is fine and we can thrash out specifics, but...
>>
>> I am thinking differently, if spec and doc are provided writing a short
>> 1-5 line summary in the release notes is not a problem.
> 
> I think developer who developed the feature is the best person to write
> the release notes. Release notes are easy to write while developing the
> feature or just after finishing the feature. Once developer starts working
> on other features/bug fixes it is very difficult to get interest in writing
> release-note for an already merged feature.
> 
> I think extracting summary from the documentation is also difficult, if the
> release maintainer not aware of all the features then it will be more
> time-consuming to write summary.

I agree to a lot of the points, if the author provided the required
release note it would be perfect (edits for style and other such will
still happen, but are far less technical in nature).

I am all for a bot that reminds folks that release notes are pending and
hence cannot merge the code.

The nature of implementing this, a separate release-notes.md file update
in the commit, or a separate section in the design document/text is
something we can debate about.

We are instating a process of requiring the design doc and getting a
"DocApproved" flag. Now, this doc and its approval flag can be granted
once appropriate release notes are also present, that way we have one
place to do this and one flag to worry about, thoughts?

> 
>>
>> The issue at present is that, to get contents into the release notes, at
>> times even the code has to be read to understand options, defaults and
>> what not. This being done by one person has been a challenge.
>>
>> So if we address spec and doc, I/we can check how easy it is to write
>> release notes from these (over the next couple of releases say) and then
>> decide if we want authors to provide the release notes as well.
>>
>> Thoughts?
>>
>> Shyam
> 
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Raghavendra Gowdappa]

I would like to turn features.sdfs on by default starting from 4.1. Details
can be found in issue:
https://github.com/gluster/glusterfs/issues/421

On Fri, Mar 16, 2018 at 1:00 PM, Xavi Hernandez  wrote:

> On Tue, Mar 13, 2018 at 2:37 AM, Shyam Ranganathan 
> 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.
>>
>
> I would like to propose the transaction framework [1] as an experimental
> feature for 4.1. The design [2] is done and I'm currently developing it.
>
> Xavi
>
> [1] https://github.com/gluster/glusterfs/issues/342
> [2] https://docs.google.com/document/d/1Zp99bsfLsB51tPen_
> zC8enANvOhX3o451pd5LyEdRSM/edit?usp=sharing
>
>
>> 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.
>>
>> Current 4.1 project release lane is empty! I cleaned it up, because I
>> want to hear from all as to what content to add, than add things marked
>> with the 4.1 milestone by default.
>>
>> Thanks,
>> Shyam
>> P.S: Also any volunteers to shadow/participate/run 4.1 as a release owner?
>> ___
>> maintainers mailing list
>> maintain...@gluster.org
>> http://lists.gluster.org/mailman/listinfo/maintainers
>>
>
>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Xavi Hernandez]

On Tue, Mar 13, 2018 at 2:37 AM, Shyam Ranganathan 
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.
>

I would like to propose the transaction framework [1] as an experimental
feature for 4.1. The design [2] is done and I'm currently developing it.

Xavi

[1] https://github.com/gluster/glusterfs/issues/342
[2]
https://docs.google.com/document/d/1Zp99bsfLsB51tPen_zC8enANvOhX3o451pd5LyEdRSM/edit?usp=sharing


> 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.
>
> Current 4.1 project release lane is empty! I cleaned it up, because I
> want to hear from all as to what content to add, than add things marked
> with the 4.1 milestone by default.
>
> Thanks,
> Shyam
> P.S: Also any volunteers to shadow/participate/run 4.1 as a release owner?
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Pranith Kumar Karampuri]

On Wed, Mar 14, 2018 at 8:27 PM, Amye Scavarda  wrote:

> Responding on the architects question:
>
> On Tue, Mar 13, 2018 at 9:57 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>>
>>
>> On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi 
>>> wrote:
>>>
 >>
> >> 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.
>
>
 I believe this has originated from maintainers meeting agreements [1] .
 The proposal to make a spec and documentation mandatory was submitted 3
 months back and is documented, and submitted for comment @
 https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieI
 yiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing


>>> Thanks! This clears almost all the doubts I had :).
>>>
>>
>> The document above refers to Architects - "Now Architects are approved
>> to revert a patch which violates by either not having github issue nor
>> bug-id, or uses a bug-id to get the feature in etc."
>>
>> Who are they? What are their responsibilities?
>>
>
> In our last reboot of the maintainers readme file, we expanded the
> architects role:
> https://github.com/gluster/glusterfs/blob/master/MAINTAINERS
> General Project Architects
> --
> M: Jeff Darcy 
> M: Vijay Bellur 
> P: Amar Tumballi 
> P: Pranith Karampuri 
> P: Raghavendra Gowdappa 
> P: Shyamsundar Ranganathan 
> P: Niels de Vos 
> P: Xavier Hernandez 
> What should we work to make more clear about this?
>

Wow, embarrassing, I am an architect who doesn't know his responsibilities.
Could you let me know where I could find them?


> - amye
>
>
>>
>>
>>>
>>>
 The idea is, if the code is going to be released, it should have
 relevant documentation for users to use it, otherwise, it doesn't matter if
 the feature is present or not. If the feature is 'default', and there is no
 documentation required, just mention it, so the flags can be given. Also,
 if there is no general agreement about the design, it doesn't make sense to
 merge a feature and then someone has to redo things.

 For any experimental code, which we want to publish for other
 developers to test, who doesn't need documentation, we have 'experimental'
 branch, which should be used for validation.

>>>
  [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-Dece
 mber/054070.html

>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>
>>
>>
>> --
>> Pranith
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Amye Scavarda | a...@redhat.com | Gluster Community Lead
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Aravinda]

On 03/14/2018 05:38 PM, Shyam Ranganathan wrote:

On 03/14/2018 02:40 AM, Aravinda wrote:

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

Aravinda, I assume this is an additional suggestion, orthogonal to the
current discussion around spec and docs, right?

Yes. Sorry about that.




If a Github issue used in Commit message as "Fixes: #" then Smoke
test should fail if patch does not contain `$SRC/release-notes/.md`
(if `$SRC/release-notes/.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.

Most of the above is fine and we can thrash out specifics, but...

I am thinking differently, if spec and doc are provided writing a short
1-5 line summary in the release notes is not a problem.


I think developer who developed the feature is the best person to write
the release notes. Release notes are easy to write while developing the
feature or just after finishing the feature. Once developer starts working
on other features/bug fixes it is very difficult to get interest in writing
release-note for an already merged feature.

I think extracting summary from the documentation is also difficult, if the
release maintainer not aware of all the features then it will be more
time-consuming to write summary.



The issue at present is that, to get contents into the release notes, at
times even the code has to be read to understand options, defaults and
what not. This being done by one person has been a challenge.

So if we address spec and doc, I/we can check how easy it is to write
release notes from these (over the next couple of releases say) and then
decide if we want authors to provide the release notes as well.

Thoughts?

Shyam



--
regards
Aravinda VK

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Amye Scavarda]

We could stand to use our words better on this stuff. Even though we've
thought about it a lot, it's not always clear about what we mean in the
roles and responsibilities.
I'll put a ticket into the Community Working Group to use more words about
this.
- amye

On Wed, Mar 14, 2018 at 8:29 AM, Raghavendra Gowdappa 
wrote:

>
>
> On Wed, Mar 14, 2018 at 8:27 PM, Amye Scavarda  wrote:
>
>> Responding on the architects question:
>>
>> On Tue, Mar 13, 2018 at 9:57 PM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>


 On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi 
 wrote:

> >>
>> >> 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.
>>
>>
> I believe this has originated from maintainers meeting agreements [1]
> . The proposal to make a spec and documentation mandatory was submitted 3
> months back and is documented, and submitted for comment @
> https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieI
> yiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing
>
>
 Thanks! This clears almost all the doubts I had :).

>>>
>>> The document above refers to Architects - "Now Architects are approved
>>> to revert a patch which violates by either not having github issue nor
>>> bug-id, or uses a bug-id to get the feature in etc."
>>>
>>> Who are they? What are their responsibilities?
>>>
>>
>> In our last reboot of the maintainers readme file, we expanded the
>> architects role:
>> https://github.com/gluster/glusterfs/blob/master/MAINTAINERS
>> General Project Architects
>> --
>> M: Jeff Darcy 
>> M: Vijay Bellur 
>> P: Amar Tumballi 
>> P: Pranith Karampuri 
>> P: Raghavendra Gowdappa 
>> P: Shyamsundar Ranganathan 
>> P: Niels de Vos 
>> P: Xavier Hernandez 
>> What should we work to make more clear about this?
>> - amye
>>
>
> Thanks for that clarification amye. I had a confusion whether the
> terminology was referring to roles listed in MAINTAINERS file. Now that
> you've clarified, my confusion is cleared.
>
>
>>
>>>
>>>


> The idea is, if the code is going to be released, it should have
> relevant documentation for users to use it, otherwise, it doesn't matter 
> if
> the feature is present or not. If the feature is 'default', and there is 
> no
> documentation required, just mention it, so the flags can be given. Also,
> if there is no general agreement about the design, it doesn't make sense 
> to
> merge a feature and then someone has to redo things.
>
> For any experimental code, which we want to publish for other
> developers to test, who doesn't need documentation, we have 'experimental'
> branch, which should be used for validation.
>

>  [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-Dece
> mber/054070.html
>



 --
 Pranith

>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Amye Scavarda | a...@redhat.com | Gluster Community Lead
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>


-- 
Amye Scavarda | a...@redhat.com | Gluster Community Lead
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Raghavendra Gowdappa]

On Wed, Mar 14, 2018 at 8:27 PM, Amye Scavarda  wrote:

> Responding on the architects question:
>
> On Tue, Mar 13, 2018 at 9:57 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>>
>>
>> On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi 
>>> wrote:
>>>
 >>
> >> 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.
>
>
 I believe this has originated from maintainers meeting agreements [1] .
 The proposal to make a spec and documentation mandatory was submitted 3
 months back and is documented, and submitted for comment @
 https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieI
 yiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing


>>> Thanks! This clears almost all the doubts I had :).
>>>
>>
>> The document above refers to Architects - "Now Architects are approved
>> to revert a patch which violates by either not having github issue nor
>> bug-id, or uses a bug-id to get the feature in etc."
>>
>> Who are they? What are their responsibilities?
>>
>
> In our last reboot of the maintainers readme file, we expanded the
> architects role:
> https://github.com/gluster/glusterfs/blob/master/MAINTAINERS
> General Project Architects
> --
> M: Jeff Darcy 
> M: Vijay Bellur 
> P: Amar Tumballi 
> P: Pranith Karampuri 
> P: Raghavendra Gowdappa 
> P: Shyamsundar Ranganathan 
> P: Niels de Vos 
> P: Xavier Hernandez 
> What should we work to make more clear about this?
> - amye
>

Thanks for that clarification amye. I had a confusion whether the
terminology was referring to roles listed in MAINTAINERS file. Now that
you've clarified, my confusion is cleared.


>
>>
>>
>>>
>>>
 The idea is, if the code is going to be released, it should have
 relevant documentation for users to use it, otherwise, it doesn't matter if
 the feature is present or not. If the feature is 'default', and there is no
 documentation required, just mention it, so the flags can be given. Also,
 if there is no general agreement about the design, it doesn't make sense to
 merge a feature and then someone has to redo things.

 For any experimental code, which we want to publish for other
 developers to test, who doesn't need documentation, we have 'experimental'
 branch, which should be used for validation.

>>>
  [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-Dece
 mber/054070.html

>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>
>>
>>
>> --
>> Pranith
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Amye Scavarda | a...@redhat.com | Gluster Community Lead
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Amye Scavarda]

Responding on the architects question:

On Tue, Mar 13, 2018 at 9:57 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>>
>>
>> On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi 
>> wrote:
>>
>>> >>
 >> 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.


>>> I believe this has originated from maintainers meeting agreements [1] .
>>> The proposal to make a spec and documentation mandatory was submitted 3
>>> months back and is documented, and submitted for comment @
>>> https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieI
>>> yiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing
>>>
>>>
>> Thanks! This clears almost all the doubts I had :).
>>
>
> The document above refers to Architects - "Now Architects are approved to
> revert a patch which violates by either not having github issue nor bug-id,
> or uses a bug-id to get the feature in etc."
>
> Who are they? What are their responsibilities?
>

In our last reboot of the maintainers readme file, we expanded the
architects role:
https://github.com/gluster/glusterfs/blob/master/MAINTAINERS
General Project Architects
--
M: Jeff Darcy 
M: Vijay Bellur 
P: Amar Tumballi 
P: Pranith Karampuri 
P: Raghavendra Gowdappa 
P: Shyamsundar Ranganathan 
P: Niels de Vos 
P: Xavier Hernandez 
What should we work to make more clear about this?
- amye


>
>
>>
>>
>>> The idea is, if the code is going to be released, it should have
>>> relevant documentation for users to use it, otherwise, it doesn't matter if
>>> the feature is present or not. If the feature is 'default', and there is no
>>> documentation required, just mention it, so the flags can be given. Also,
>>> if there is no general agreement about the design, it doesn't make sense to
>>> merge a feature and then someone has to redo things.
>>>
>>> For any experimental code, which we want to publish for other developers
>>> to test, who doesn't need documentation, we have 'experimental' branch,
>>> which should be used for validation.
>>>
>>
>>>  [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-Dece
>>> mber/054070.html
>>>
>>
>>
>>
>> --
>> Pranith
>>
>
>
>
> --
> Pranith
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Amye Scavarda | a...@redhat.com | Gluster Community Lead
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Shyam Ranganathan]

On 03/14/2018 02:40 AM, Aravinda wrote:
> I have following suggestion for managing release notes. Let me know
> if this can be included in automation document.

Aravinda, I assume this is an additional suggestion, orthogonal to the
current discussion around spec and docs, right?

> 
> 
> If a Github issue used in Commit message as "Fixes: #" then Smoke
> test should fail if patch does not contain `$SRC/release-notes/.md`
> (if `$SRC/release-notes/.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.

Most of the above is fine and we can thrash out specifics, but...

I am thinking differently, if spec and doc are provided writing a short
1-5 line summary in the release notes is not a problem.

The issue at present is that, to get contents into the release notes, at
times even the code has to be read to understand options, defaults and
what not. This being done by one person has been a challenge.

So if we address spec and doc, I/we can check how easy it is to write
release notes from these (over the next couple of releases say) and then
decide if we want authors to provide the release notes as well.

Thoughts?

Shyam
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [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
 wrote:


On Tue, Mar 13, 2018 at 7:07 AM, Shyam Ranganathan 
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: #" then Smoke
test should fail if patch does not contain `$SRC/release-notes/.md`
(if `$SRC/release-notes/.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@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel



--
regards
Aravinda VK

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Raghavendra Gowdappa]

On Wed, Mar 14, 2018 at 10:27 AM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>>
>>
>> On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi 
>> wrote:
>>
>>> >>
 >> 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.


>>> I believe this has originated from maintainers meeting agreements [1] .
>>> The proposal to make a spec and documentation mandatory was submitted 3
>>> months back and is documented, and submitted for comment @
>>> https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieI
>>> yiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing
>>>
>>>
>> Thanks! This clears almost all the doubts I had :).
>>
>
> The document above refers to Architects - "Now Architects are approved to
> revert a patch which violates by either not having github issue nor bug-id,
> or uses a bug-id to get the feature in etc."
>
> Who are they? What are their responsibilities?
>

I had heard reference to this role in a Maintainer's meeting too. It was in
the context of People meeting up during FAST18 and discussing about the
future of Glusterfs. Clarifications on this role is much appreciated.
Specifically,

* Was there a process to decide on who are they?
* If yes, when did this happen?


>
>>
>>
>>> The idea is, if the code is going to be released, it should have
>>> relevant documentation for users to use it, otherwise, it doesn't matter if
>>> the feature is present or not. If the feature is 'default', and there is no
>>> documentation required, just mention it, so the flags can be given. Also,
>>> if there is no general agreement about the design, it doesn't make sense to
>>> merge a feature and then someone has to redo things.
>>>
>>> For any experimental code, which we want to publish for other developers
>>> to test, who doesn't need documentation, we have 'experimental' branch,
>>> which should be used for validation.
>>>
>>
>>>  [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-Dece
>>> mber/054070.html
>>>
>>
>>
>>
>> --
>> Pranith
>>
>
>
>
> --
> Pranith
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Pranith Kumar Karampuri]

On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi 
> wrote:
>
>> >>
>>> >> 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.
>>>
>>>
>> I believe this has originated from maintainers meeting agreements [1] .
>> The proposal to make a spec and documentation mandatory was submitted 3
>> months back and is documented, and submitted for comment @
>> https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieI
>> yiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing
>>
>>
> Thanks! This clears almost all the doubts I had :).
>

The document above refers to Architects - "Now Architects are approved to
revert a patch which violates by either not having github issue nor bug-id,
or uses a bug-id to get the feature in etc."

Who are they? What are their responsibilities?


>
>
>> The idea is, if the code is going to be released, it should have relevant
>> documentation for users to use it, otherwise, it doesn't matter if the
>> feature is present or not. If the feature is 'default', and there is no
>> documentation required, just mention it, so the flags can be given. Also,
>> if there is no general agreement about the design, it doesn't make sense to
>> merge a feature and then someone has to redo things.
>>
>> For any experimental code, which we want to publish for other developers
>> to test, who doesn't need documentation, we have 'experimental' branch,
>> which should be used for validation.
>>
>
>>  [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-Dece
>> mber/054070.html
>>
>
>
>
> --
> Pranith
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Shyam Ranganathan]

On 03/13/2018 03:53 AM, Sankarshan Mukhopadhyay wrote:
> On Tue, Mar 13, 2018 at 1:05 PM, Pranith Kumar Karampuri
>  wrote:
>>
>>
>> On Tue, Mar 13, 2018 at 7:07 AM, Shyam Ranganathan 
>> 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.

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

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

[Amar Tumballi]

>
> >>
> >> 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.
>
>
I believe this has originated from maintainers meeting agreements [1] . The
proposal to make a spec and documentation mandatory was submitted 3 months
back and is documented, and submitted for comment @
https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieIyiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing

The idea is, if the code is going to be released, it should have relevant
documentation for users to use it, otherwise, it doesn't matter if the
feature is present or not. If the feature is 'default', and there is no
documentation required, just mention it, so the flags can be given. Also,
if there is no general agreement about the design, it doesn't make sense to
merge a feature and then someone has to redo things.

For any experimental code, which we want to publish for other developers to
test, who doesn't need documentation, we have 'experimental' branch, which
should be used for validation.

 [1] -
http://lists.gluster.org/pipermail/gluster-devel/2017-December/054070.html
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Sankarshan Mukhopadhyay]

On Tue, Mar 13, 2018 at 1:05 PM, Pranith Kumar Karampuri
 wrote:
>
>
> On Tue, Mar 13, 2018 at 7:07 AM, Shyam Ranganathan 
> 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.

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

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

[Pranith Kumar Karampuri]

On Tue, Mar 13, 2018 at 7:07 AM, Shyam Ranganathan 
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?


>
> Current 4.1 project release lane is empty! I cleaned it up, because I
> want to hear from all as to what content to add, than add things marked
> with the 4.1 milestone by default.
>
> Thanks,
> Shyam
> P.S: Also any volunteers to shadow/participate/run 4.1 as a release owner?
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel