[Gluster-Maintainers] [Gluster-devel] New 'experimental' branch created for validating your ideas

[Amar Tumballi]

On Tue, Jun 20, 2017 at 5:42 PM, Hari Gowtham <hgowtham at redhat.com> wrote:

> What about the patches that are already posted against master and are
> yet to be reviewed?
>

If its not merged in master, it is fine to merge to experimental.


> Is it fine to post them here and continue with the work further here
> or wait for these patches to get in master
> and then come to the experimental branch.
>

If a patch lands in 'master' branch, I don't think there is any need to
send it to 'experimental'. The idea of 'experimental' branch is to push
features/changes which are not having enough confidence to make it to
master branch, and get it tested in regression suite over time.

If its not merged, send it to experimental branch, get it merged, and if
there is anything extra needs to be done, work on it, and once stable, send
the aggregated patch to 'master' branch.


> Asking this question because the patch is there for a very long time.
>
> Got it. And this is the very reason for getting 'experimental' branch done.


> And it would be better to know what is the frequency in rebasing the
> master and the experimental branch.
>

'master' branch rebase to experimental will be done once in 6 months,
officially. I will try rebasing once a month, and see if there are no
conflicts, I will force push the branch, but for now, thinking of 6 months
frequency. There has been suggestion to keep it 3 months window (similar to
that of release branch cut-off). Yet to finalize on that.


> And how has the permission to merge the patches in the experimental branch.
>
>
Assuming it is 'who' and not 'how', Currently I (@amarts) have the
permission to merge patches.

Regards,
Amar


>
> On Tue, Jun 20, 2017 at 4:05 PM, Amar Tumballi <atumball at redhat.com>
> wrote:
> > All,
> >
> > As proposed earlier [1], the 'experimental' branch is now created and
> > active. Any submission to this branch is going to be accepted without too
> > much detailed review, and the focus will be to make sure overall design
> is
> > fine. I have put a deadline of a week max for reviewing and merging a
> patch
> > if there are no significant problems with the patch.
> >
> > I welcome everyone to use this branch as an test bed to validate your
> ideas,
> > so your patch gets merged, and the nightly regressions would run on it
> for
> > some time. Also we are planning to give out RPMs from this branch every
> > week, so some features which gets completed in experimental can be
> tested by
> > wider user-base, and once validated, can land in master branch and
> > subsequently next release.
> >
> > A note of caution: Getting a patch merged in experimental is in no way
> > guarantee to get your patch in any of the upstream glusterfs releases.
> The
> > author needs to submit the changes to 'master' branch to get the feature
> in
> > releases.
> >
> > The branch already has some experimental features like:
> >
> > metrics on 'fops' in every xlator layer, instead of only getting it with
> > io-stats.
> > latency related information is default.
> > few more metrics added in memory allocation checks.
> > All the above can be seen with sending SIGUSR2 signal to GlusterFS
> process.
> > (@ /tmp/glusterfs.* )
> >
> >
> > Regards,
> > Amar
> >
> > [1] - http://lists.gluster.org/pipermail/maintainers/2017-
> May/002644.html
> >
> > --
> > Amar Tumballi (amarts)
> >
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>
> --
> Regards,
> Hari Gowtham.
>



-- 
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20170620/bf11324d/attachment.html>