Re: New 'experimental' branch created for validating your ideas

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, Jun 20, 2017 at 5:42 PM, Hari Gowtham <hgowtham@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxx
> http://lists.gluster.org/mailman/listinfo/gluster-devel



--
Regards,
Hari Gowtham.



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

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux