Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-10-22 Thread Michael Scherer 
Le mardi 22 octobre 2019 à 13:17 +0530, Amar Tumballi a écrit :
> Thanks for the email Misc. My reasons inline.
> 
> On Mon, Oct 21, 2019 at 4:44 PM Michael Scherer 
> wrote:
> 
> > Le lundi 14 octobre 2019 à 20:30 +0530, Amar Tumballi a écrit :
> > > On Mon, 14 Oct, 2019, 5:37 PM Niels de Vos, 
> > > wrote:
> > > 
> > > > On Mon, Oct 14, 2019 at 03:52:30PM +0530, Amar Tumballi wrote:
> > > > > Any thoughts on this?
> > > > > 
> > > > > I tried a basic .travis.yml for the unified glusterfs repo I
> > > > > am
> > > > > maintaining, and it is good enough for getting most of the
> > > > > tests.
> > > > > Considering we are very close to glusterfs-7.0 release, it is
> > > > > good to
> > > > 
> > > > time
> > > > > this after 7.0 release.
> > > > 
> > > > Is there a reason to move to Travis? GitHub does offer
> > > > integration
> > > > with
> > > > Jenkins, so we should be able to keep using our existing CI, I
> > > > think?
> > > > 
> > > 
> > > Yes, that's true. I tried Travis because I don't have complete
> > > idea
> > > of
> > > Jenkins infra and trying Travis needed just basic permissions
> > > from me
> > > on
> > > repo (it was tried on my personal repo)
> > 
> > Travis is limited to 1 builder per project with the free version..
> > So since the regression test last 4h, I am not sure exactly what is
> > the
> > plan there.
> > 
> > 
> 
> We can't regress from our current testing coverage when we migrate.
> So, My take is, we should start with surely using existing Jenkins
> itself from github. And eventually see if there are any better
> options, or else at least remain with this CI.

Ansible did use travis first, and we did had a lot of issues after a
while. I think that if we want to have the same amount of CI than now,
we would need around 5 to 6 VM at minima for a average workload, and a
bit more for release time. Assuming we start to have more activity
(and/or more coverage), we would need to scale up to more VM too.

Plus, given glusterfs nature, I am not sure we should use a Ci where we
do not control the underlying kernel or infra. We still have some
issues with I/O on AWS that break test, so I can't imagine how it would
be with a random kernel :/


> > Now, on the whole migration stuff, I do have a few questions:
> > 
> > - what will happen to the history of the project (aka, the old
> > review.gluster.org server). I would be in favor of dropping it if
> > we
> > move out, but then, we would lose all informations there (the
> > review
> > content itself).
> > 
> > 
> 
> I would like to see it hosted somewhere (ie, in same URL preferably).
> But depending on sponsorship for the hosting charges, if we had to
> decide to shutting the service down, my take is, we can make the DB
> content made available for public download. Happy to provide a 'how
> to view patches' guide so one can setup Gerrit locally and see the
> details.

Wouldn't it be a problem to drop emails, etc in a DB like this ? RGPD
compliance come to mind. (I do not think that's a problem, but I would
really prefer to have a lawyer opinion first, since I would be legally
responsible in my country based on my memories of law courses in
university).

Plus, let's be honest with ourself, nobody is going to go to the hassle
of setting a old version of gerrit just to read a review. 

We could try to do a html mirror using wget, but I have no idea how
long it would take, nor how complete it would be in practice.

And yes, same URL is doable.

Then what about other gerrit using projects, shouldn't they be moved
before glusterfs ?

> - what happen to existing proposed patches, do they need to be
> migrated
> > one by one (and if so, who is going to script that part)
> > 
> > 
> 
> I checked that we have < 50 patches active on master branch, and
> other than Yaniv, no one has more than 5 patches active in review
> queue. So, I propose people can take up their own patches and post it
> to GitHub. For those who are not willing to do that extra work, or
> not active in project now,  I am happy to help them migrate the patch
> to PR.

How hard would it be to have github/gerrit side by side for a time ?
I am wary of any huge move and prefer incremental steps.

> 
> 
> > - can we, while we are on it, force 2FA for the whole org on github
> > ?
> > before, I didn't push too hard because this wasn't critical, but if
> > there is a migration, that would be much more important.
> > 
> > 
> 
> Yes. I believe that is totally fine, specifically for those who are
> admins of the org, and those who can merge.

I think we can't force per team, just the whole org (I may be wrong, it
happen, but not that often).

> 
> > - what is the plan to force to enforce the various policies ?
> > (like the fact that commit need to be sign, in a DCO like fashion,
> > or
> > to decide who can merge, who can give +2, and how we trigger build
> > only
> > when someone has said "this is verified")
> > 
> > 
> 
> About people, two options IMO:
> 1. Provide access to same set

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-10-22 Thread Amar Tumballi 
Thanks for the email Misc. My reasons inline.

On Mon, Oct 21, 2019 at 4:44 PM Michael Scherer  wrote:

> Le lundi 14 octobre 2019 à 20:30 +0530, Amar Tumballi a écrit :
> > On Mon, 14 Oct, 2019, 5:37 PM Niels de Vos, 
> > wrote:
> >
> > > On Mon, Oct 14, 2019 at 03:52:30PM +0530, Amar Tumballi wrote:
> > > > Any thoughts on this?
> > > >
> > > > I tried a basic .travis.yml for the unified glusterfs repo I am
> > > > maintaining, and it is good enough for getting most of the tests.
> > > > Considering we are very close to glusterfs-7.0 release, it is
> > > > good to
> > >
> > > time
> > > > this after 7.0 release.
> > >
> > > Is there a reason to move to Travis? GitHub does offer integration
> > > with
> > > Jenkins, so we should be able to keep using our existing CI, I
> > > think?
> > >
> >
> > Yes, that's true. I tried Travis because I don't have complete idea
> > of
> > Jenkins infra and trying Travis needed just basic permissions from me
> > on
> > repo (it was tried on my personal repo)
>
> Travis is limited to 1 builder per project with the free version..
> So since the regression test last 4h, I am not sure exactly what is the
> plan there.
>
>
We can't regress from our current testing coverage when we migrate. So, My
take is, we should start with surely using existing Jenkins itself from
github. And eventually see if there are any better options, or else at
least remain with this CI.


> Now, on the whole migration stuff, I do have a few questions:
>
> - what will happen to the history of the project (aka, the old
> review.gluster.org server). I would be in favor of dropping it if we
> move out, but then, we would lose all informations there (the review
> content itself).
>
>
I would like to see it hosted somewhere (ie, in same URL preferably).

But depending on sponsorship for the hosting charges, if we had to decide
to shutting the service down, my take is, we can make the DB content made
available for public download. Happy to provide a 'how to view patches'
guide so one can setup Gerrit locally and see the details.

- what happen to existing proposed patches, do they need to be migrated
> one by one (and if so, who is going to script that part)
>
>
I checked that we have < 50 patches active on master branch, and other than
Yaniv, no one has more than 5 patches active in review queue. So, I propose
people can take up their own patches and post it to GitHub. For those who
are not willing to do that extra work, or not active in project now,  I am
happy to help them migrate the patch to PR.



> - can we, while we are on it, force 2FA for the whole org on github ?
> before, I didn't push too hard because this wasn't critical, but if
> there is a migration, that would be much more important.
>
>
Yes. I believe that is totally fine, specifically for those who are admins
of the org, and those who can merge.


> - what is the plan to force to enforce the various policies ?
> (like the fact that commit need to be sign, in a DCO like fashion, or
> to decide who can merge, who can give +2, and how we trigger build only
> when someone has said "this is verified")
>
>
About people, two options IMO:
1. Provide access to same set of people who have access in Gerrit.
or 2. Look at the activity list in last 1 year, and see who has actually
reviewed AND merged any patch from the above list to have access.

About policies on how to trigger build, and merge I prefer to use tools
like mergify.io which is also used by many open source projects, and also
friends @ Ceph project use the same. That way, there would be no human
pressing merge, but policy based patches would be merged.

About what strings, commands to use for triggering builds (/run smoke, /run
regression etc), I am happy to work with someone to get this done.


> - can we define also some goals on why to migrate ?
>

Sure, will list below.


> the thread do not really explain why, except "that's what everybody is
> doing". Based on previous migrations for different contexts, that's
> usually not sufficient, and we get the exact same amount of
> contribution no matter what (like static blog vs wordpress vs static
> blog), except that someone (usually me) has to do lots of work.
>
>
I agree, and sorry about causing lot of work for you :-/ None of this
intentional. We all thrive and look for better way as they (and we) evolve.
It is good to recheck whether we are using right tools, right processes or
not every 2 yrs at least.


> So could someone give some estimate that can be measured on what is
> going to be improved, along a timeframe for the estimated improvement ?
> (so like in 6 months, this will be bring new developpers, or this will
> make patch being merged 10% faster). And just to be clear, if the goals
> are not reached in the timeframe, I am gonna make people accountable
> and complain next time someone propose a migration.
>
>
This part of the email is very critical, for everyone. Because if we don't
measure it, we didn't achieve anything.

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-10-15 Thread Deepshikha Khandelwal 
On Tue, Oct 15, 2019 at 10:57 AM Aravinda Vishwanathapura Krishna Murthy <
avish...@redhat.com> wrote:

> Centos CI was voting Glusterd2 repo's pull requests.
>
> https://github.com/gluster/centosci/blob/master/jobs/glusterd2.yml
>
> On Mon, Oct 14, 2019 at 8:31 PM Amar Tumballi  wrote:
>
>>
>>
>> On Mon, 14 Oct, 2019, 5:37 PM Niels de Vos,  wrote:
>>
>>> On Mon, Oct 14, 2019 at 03:52:30PM +0530, Amar Tumballi wrote:
>>> > Any thoughts on this?
>>> >
>>> > I tried a basic .travis.yml for the unified glusterfs repo I am
>>> > maintaining, and it is good enough for getting most of the tests.
>>> > Considering we are very close to glusterfs-7.0 release, it is good to
>>> time
>>> > this after 7.0 release.
>>>
>>> Is there a reason to move to Travis? GitHub does offer integration with
>>> Jenkins, so we should be able to keep using our existing CI, I think?
>>>
>>
Yes, we can make use of existing jenkins jobs for GitHub. It needs some
config changes in the JJB to get triggered for GitHub pull requests.

I can start off with basic smoke testing.

>
>> Yes, that's true. I tried Travis because I don't have complete idea of
>> Jenkins infra and trying Travis needed just basic permissions from me on
>> repo (it was tried on my personal repo)
>>
>> Happy to get some help here.
>>
>> Regards,
>> Amar
>>
>>
>>> Niels
>>>
>>>
>>> >
>>> > -Amar
>>> >
>>> > On Thu, Sep 5, 2019 at 5:13 PM Amar Tumballi  wrote:
>>> >
>>> > > Going through the thread, I see in general positive responses for the
>>> > > same, with few points on review system, and not loosing information
>>> when
>>> > > merging the patches.
>>> > >
>>> > > While we are working on that, we need to see and understand how our
>>> CI/CD
>>> > > looks like with github migration. We surely need suggestion and
>>> volunteers
>>> > > here to get this going.
>>> > >
>>> > > Regards,
>>> > > Amar
>>> > >
>>> > >
>>> > > On Wed, Aug 28, 2019 at 12:38 PM Niels de Vos 
>>> wrote:
>>> > >
>>> > >> On Tue, Aug 27, 2019 at 06:57:14AM +0530, Amar Tumballi Suryanarayan
>>> > >> wrote:
>>> > >> > On Tue, Aug 27, 2019 at 12:10 AM Niels de Vos 
>>> > >> wrote:
>>> > >> >
>>> > >> > > On Mon, Aug 26, 2019 at 08:36:30PM +0530, Aravinda
>>> Vishwanathapura
>>> > >> Krishna
>>> > >> > > Murthy wrote:
>>> > >> > > > On Mon, Aug 26, 2019 at 7:49 PM Joe Julian <
>>> j...@julianfamily.org>
>>> > >> wrote:
>>> > >> > > >
>>> > >> > > > > > Comparing the changes between revisions is something
>>> > >> > > > > that GitHub does not support...
>>> > >> > > > >
>>> > >> > > > > It does support that,
>>> > >> > > > > actually.___
>>> > >> > > > >
>>> > >> > > >
>>> > >> > > > Yes, it does support. We need to use Squash merge after all
>>> review
>>> > >> is
>>> > >> > > done.
>>> > >> > >
>>> > >> > > Squash merge would also combine multiple commits that are
>>> intended to
>>> > >> > > stay separate. This is really bad :-(
>>> > >> > >
>>> > >> > >
>>> > >> > We should treat 1 patch in gerrit as 1 PR in github, then squash
>>> merge
>>> > >> > works same as how reviews in gerrit are done.  Or we can come up
>>> with
>>> > >> > label, upon which we can actually do 'rebase and merge' option,
>>> which
>>> > >> can
>>> > >> > preserve the commits as is.
>>> > >>
>>> > >> Something like that would be good. For many things, including commit
>>> > >> message update squashing patches is just loosing details. We dont do
>>> > >> that with Gerrit now, and we should not do that when using GitHub
>>> PRs.
>>> > >> Proper documenting changes is still very important to me, the
>>> details of
>>> > >> patches should be explained in commit messages. This only works well
>>> > >> when developers 'force push' to the branch holding the PR.
>>> > >>
>>> > >> Niels
>>> > >> ___
>>> > >>
>>> > >> Community Meeting Calendar:
>>> > >>
>>> > >> APAC Schedule -
>>> > >> Every 2nd and 4th Tuesday at 11:30 AM IST
>>> > >> Bridge: https://bluejeans.com/836554017
>>> > >>
>>> > >> NA/EMEA Schedule -
>>> > >> Every 1st and 3rd Tuesday at 01:00 PM EDT
>>> > >> Bridge: https://bluejeans.com/486278655
>>> > >>
>>> > >> Gluster-devel mailing list
>>> > >> gluster-de...@gluster.org
>>> > >> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>> > >>
>>> > >>
>>>
>>> > ___
>>> >
>>> > Community Meeting Calendar:
>>> >
>>> > APAC Schedule -
>>> > Every 2nd and 4th Tuesday at 11:30 AM IST
>>> > Bridge: https://bluejeans.com/118564314
>>> >
>>> > NA/EMEA Schedule -
>>> > Every 1st and 3rd Tuesday at 01:00 PM EDT
>>> > Bridge: https://bluejeans.com/118564314
>>> >
>>> > Gluster-devel mailing list
>>> > gluster-de...@gluster.org
>>> > https://lists.gluster.org/mailman/listinfo/gluster-devel
>>> >
>>>
>>> ___
>> maintainers mailing list
>> maintainers@gluster.org
>> https://lists.gluster.org/mailman/listinfo/maintainers
>>
>
>
> --
> regards
> Aravinda

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-10-14 Thread Aravinda Vishwanathapura Krishna Murthy 
Centos CI was voting Glusterd2 repo's pull requests.

https://github.com/gluster/centosci/blob/master/jobs/glusterd2.yml

On Mon, Oct 14, 2019 at 8:31 PM Amar Tumballi  wrote:

>
>
> On Mon, 14 Oct, 2019, 5:37 PM Niels de Vos,  wrote:
>
>> On Mon, Oct 14, 2019 at 03:52:30PM +0530, Amar Tumballi wrote:
>> > Any thoughts on this?
>> >
>> > I tried a basic .travis.yml for the unified glusterfs repo I am
>> > maintaining, and it is good enough for getting most of the tests.
>> > Considering we are very close to glusterfs-7.0 release, it is good to
>> time
>> > this after 7.0 release.
>>
>> Is there a reason to move to Travis? GitHub does offer integration with
>> Jenkins, so we should be able to keep using our existing CI, I think?
>>
>
> Yes, that's true. I tried Travis because I don't have complete idea of
> Jenkins infra and trying Travis needed just basic permissions from me on
> repo (it was tried on my personal repo)
>
> Happy to get some help here.
>
> Regards,
> Amar
>
>
>> Niels
>>
>>
>> >
>> > -Amar
>> >
>> > On Thu, Sep 5, 2019 at 5:13 PM Amar Tumballi  wrote:
>> >
>> > > Going through the thread, I see in general positive responses for the
>> > > same, with few points on review system, and not loosing information
>> when
>> > > merging the patches.
>> > >
>> > > While we are working on that, we need to see and understand how our
>> CI/CD
>> > > looks like with github migration. We surely need suggestion and
>> volunteers
>> > > here to get this going.
>> > >
>> > > Regards,
>> > > Amar
>> > >
>> > >
>> > > On Wed, Aug 28, 2019 at 12:38 PM Niels de Vos 
>> wrote:
>> > >
>> > >> On Tue, Aug 27, 2019 at 06:57:14AM +0530, Amar Tumballi Suryanarayan
>> > >> wrote:
>> > >> > On Tue, Aug 27, 2019 at 12:10 AM Niels de Vos 
>> > >> wrote:
>> > >> >
>> > >> > > On Mon, Aug 26, 2019 at 08:36:30PM +0530, Aravinda
>> Vishwanathapura
>> > >> Krishna
>> > >> > > Murthy wrote:
>> > >> > > > On Mon, Aug 26, 2019 at 7:49 PM Joe Julian <
>> j...@julianfamily.org>
>> > >> wrote:
>> > >> > > >
>> > >> > > > > > Comparing the changes between revisions is something
>> > >> > > > > that GitHub does not support...
>> > >> > > > >
>> > >> > > > > It does support that,
>> > >> > > > > actually.___
>> > >> > > > >
>> > >> > > >
>> > >> > > > Yes, it does support. We need to use Squash merge after all
>> review
>> > >> is
>> > >> > > done.
>> > >> > >
>> > >> > > Squash merge would also combine multiple commits that are
>> intended to
>> > >> > > stay separate. This is really bad :-(
>> > >> > >
>> > >> > >
>> > >> > We should treat 1 patch in gerrit as 1 PR in github, then squash
>> merge
>> > >> > works same as how reviews in gerrit are done.  Or we can come up
>> with
>> > >> > label, upon which we can actually do 'rebase and merge' option,
>> which
>> > >> can
>> > >> > preserve the commits as is.
>> > >>
>> > >> Something like that would be good. For many things, including commit
>> > >> message update squashing patches is just loosing details. We dont do
>> > >> that with Gerrit now, and we should not do that when using GitHub
>> PRs.
>> > >> Proper documenting changes is still very important to me, the
>> details of
>> > >> patches should be explained in commit messages. This only works well
>> > >> when developers 'force push' to the branch holding the PR.
>> > >>
>> > >> Niels
>> > >> ___
>> > >>
>> > >> Community Meeting Calendar:
>> > >>
>> > >> APAC Schedule -
>> > >> Every 2nd and 4th Tuesday at 11:30 AM IST
>> > >> Bridge: https://bluejeans.com/836554017
>> > >>
>> > >> NA/EMEA Schedule -
>> > >> Every 1st and 3rd Tuesday at 01:00 PM EDT
>> > >> Bridge: https://bluejeans.com/486278655
>> > >>
>> > >> Gluster-devel mailing list
>> > >> gluster-de...@gluster.org
>> > >> https://lists.gluster.org/mailman/listinfo/gluster-devel
>> > >>
>> > >>
>>
>> > ___
>> >
>> > Community Meeting Calendar:
>> >
>> > APAC Schedule -
>> > Every 2nd and 4th Tuesday at 11:30 AM IST
>> > Bridge: https://bluejeans.com/118564314
>> >
>> > NA/EMEA Schedule -
>> > Every 1st and 3rd Tuesday at 01:00 PM EDT
>> > Bridge: https://bluejeans.com/118564314
>> >
>> > Gluster-devel mailing list
>> > gluster-de...@gluster.org
>> > https://lists.gluster.org/mailman/listinfo/gluster-devel
>> >
>>
>> ___
> maintainers mailing list
> maintainers@gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>


-- 
regards
Aravinda VK
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-10-14 Thread Yaniv Kaul 
On Mon, 14 Oct 2019, 17:01 Amar Tumballi  wrote:

>
>
> On Mon, 14 Oct, 2019, 5:37 PM Niels de Vos,  wrote:
>
>> On Mon, Oct 14, 2019 at 03:52:30PM +0530, Amar Tumballi wrote:
>> > Any thoughts on this?
>> >
>> > I tried a basic .travis.yml for the unified glusterfs repo I am
>> > maintaining, and it is good enough for getting most of the tests.
>> > Considering we are very close to glusterfs-7.0 release, it is good to
>> time
>> > this after 7.0 release.
>>
>> Is there a reason to move to Travis? GitHub does offer integration with
>> Jenkins, so we should be able to keep using our existing CI, I think?
>>
>
> Yes, that's true. I tried Travis because I don't have complete idea of
> Jenkins infra and trying Travis needed just basic permissions from me on
> repo (it was tried on my personal repo)
>

Travis would be great when we can move to fully utilizing containers for
testing. Until then, what's the support level for VMs?
Y.


> Happy to get some help here.
>
> Regards,
> Amar
>
>
>> Niels
>>
>>
>> >
>> > -Amar
>> >
>> > On Thu, Sep 5, 2019 at 5:13 PM Amar Tumballi  wrote:
>> >
>> > > Going through the thread, I see in general positive responses for the
>> > > same, with few points on review system, and not loosing information
>> when
>> > > merging the patches.
>> > >
>> > > While we are working on that, we need to see and understand how our
>> CI/CD
>> > > looks like with github migration. We surely need suggestion and
>> volunteers
>> > > here to get this going.
>> > >
>> > > Regards,
>> > > Amar
>> > >
>> > >
>> > > On Wed, Aug 28, 2019 at 12:38 PM Niels de Vos 
>> wrote:
>> > >
>> > >> On Tue, Aug 27, 2019 at 06:57:14AM +0530, Amar Tumballi Suryanarayan
>> > >> wrote:
>> > >> > On Tue, Aug 27, 2019 at 12:10 AM Niels de Vos 
>> > >> wrote:
>> > >> >
>> > >> > > On Mon, Aug 26, 2019 at 08:36:30PM +0530, Aravinda
>> Vishwanathapura
>> > >> Krishna
>> > >> > > Murthy wrote:
>> > >> > > > On Mon, Aug 26, 2019 at 7:49 PM Joe Julian <
>> j...@julianfamily.org>
>> > >> wrote:
>> > >> > > >
>> > >> > > > > > Comparing the changes between revisions is something
>> > >> > > > > that GitHub does not support...
>> > >> > > > >
>> > >> > > > > It does support that,
>> > >> > > > > actually.___
>> > >> > > > >
>> > >> > > >
>> > >> > > > Yes, it does support. We need to use Squash merge after all
>> review
>> > >> is
>> > >> > > done.
>> > >> > >
>> > >> > > Squash merge would also combine multiple commits that are
>> intended to
>> > >> > > stay separate. This is really bad :-(
>> > >> > >
>> > >> > >
>> > >> > We should treat 1 patch in gerrit as 1 PR in github, then squash
>> merge
>> > >> > works same as how reviews in gerrit are done.  Or we can come up
>> with
>> > >> > label, upon which we can actually do 'rebase and merge' option,
>> which
>> > >> can
>> > >> > preserve the commits as is.
>> > >>
>> > >> Something like that would be good. For many things, including commit
>> > >> message update squashing patches is just loosing details. We dont do
>> > >> that with Gerrit now, and we should not do that when using GitHub
>> PRs.
>> > >> Proper documenting changes is still very important to me, the
>> details of
>> > >> patches should be explained in commit messages. This only works well
>> > >> when developers 'force push' to the branch holding the PR.
>> > >>
>> > >> Niels
>> > >> ___
>> > >>
>> > >> Community Meeting Calendar:
>> > >>
>> > >> APAC Schedule -
>> > >> Every 2nd and 4th Tuesday at 11:30 AM IST
>> > >> Bridge: https://bluejeans.com/836554017
>> > >>
>> > >> NA/EMEA Schedule -
>> > >> Every 1st and 3rd Tuesday at 01:00 PM EDT
>> > >> Bridge: https://bluejeans.com/486278655
>> > >>
>> > >> Gluster-devel mailing list
>> > >> gluster-de...@gluster.org
>> > >> https://lists.gluster.org/mailman/listinfo/gluster-devel
>> > >>
>> > >>
>>
>> > ___
>> >
>> > Community Meeting Calendar:
>> >
>> > APAC Schedule -
>> > Every 2nd and 4th Tuesday at 11:30 AM IST
>> > Bridge: https://bluejeans.com/118564314
>> >
>> > NA/EMEA Schedule -
>> > Every 1st and 3rd Tuesday at 01:00 PM EDT
>> > Bridge: https://bluejeans.com/118564314
>> >
>> > Gluster-devel mailing list
>> > gluster-de...@gluster.org
>> > https://lists.gluster.org/mailman/listinfo/gluster-devel
>> >
>>
>> ___
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/118564314
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/118564314
>
> Gluster-devel mailing list
> gluster-de...@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-10-14 Thread Amar Tumballi 
On Mon, 14 Oct, 2019, 5:37 PM Niels de Vos,  wrote:

> On Mon, Oct 14, 2019 at 03:52:30PM +0530, Amar Tumballi wrote:
> > Any thoughts on this?
> >
> > I tried a basic .travis.yml for the unified glusterfs repo I am
> > maintaining, and it is good enough for getting most of the tests.
> > Considering we are very close to glusterfs-7.0 release, it is good to
> time
> > this after 7.0 release.
>
> Is there a reason to move to Travis? GitHub does offer integration with
> Jenkins, so we should be able to keep using our existing CI, I think?
>

Yes, that's true. I tried Travis because I don't have complete idea of
Jenkins infra and trying Travis needed just basic permissions from me on
repo (it was tried on my personal repo)

Happy to get some help here.

Regards,
Amar


> Niels
>
>
> >
> > -Amar
> >
> > On Thu, Sep 5, 2019 at 5:13 PM Amar Tumballi  wrote:
> >
> > > Going through the thread, I see in general positive responses for the
> > > same, with few points on review system, and not loosing information
> when
> > > merging the patches.
> > >
> > > While we are working on that, we need to see and understand how our
> CI/CD
> > > looks like with github migration. We surely need suggestion and
> volunteers
> > > here to get this going.
> > >
> > > Regards,
> > > Amar
> > >
> > >
> > > On Wed, Aug 28, 2019 at 12:38 PM Niels de Vos 
> wrote:
> > >
> > >> On Tue, Aug 27, 2019 at 06:57:14AM +0530, Amar Tumballi Suryanarayan
> > >> wrote:
> > >> > On Tue, Aug 27, 2019 at 12:10 AM Niels de Vos 
> > >> wrote:
> > >> >
> > >> > > On Mon, Aug 26, 2019 at 08:36:30PM +0530, Aravinda Vishwanathapura
> > >> Krishna
> > >> > > Murthy wrote:
> > >> > > > On Mon, Aug 26, 2019 at 7:49 PM Joe Julian <
> j...@julianfamily.org>
> > >> wrote:
> > >> > > >
> > >> > > > > > Comparing the changes between revisions is something
> > >> > > > > that GitHub does not support...
> > >> > > > >
> > >> > > > > It does support that,
> > >> > > > > actually.___
> > >> > > > >
> > >> > > >
> > >> > > > Yes, it does support. We need to use Squash merge after all
> review
> > >> is
> > >> > > done.
> > >> > >
> > >> > > Squash merge would also combine multiple commits that are
> intended to
> > >> > > stay separate. This is really bad :-(
> > >> > >
> > >> > >
> > >> > We should treat 1 patch in gerrit as 1 PR in github, then squash
> merge
> > >> > works same as how reviews in gerrit are done.  Or we can come up
> with
> > >> > label, upon which we can actually do 'rebase and merge' option,
> which
> > >> can
> > >> > preserve the commits as is.
> > >>
> > >> Something like that would be good. For many things, including commit
> > >> message update squashing patches is just loosing details. We dont do
> > >> that with Gerrit now, and we should not do that when using GitHub PRs.
> > >> Proper documenting changes is still very important to me, the details
> of
> > >> patches should be explained in commit messages. This only works well
> > >> when developers 'force push' to the branch holding the PR.
> > >>
> > >> Niels
> > >> ___
> > >>
> > >> Community Meeting Calendar:
> > >>
> > >> APAC Schedule -
> > >> Every 2nd and 4th Tuesday at 11:30 AM IST
> > >> Bridge: https://bluejeans.com/836554017
> > >>
> > >> NA/EMEA Schedule -
> > >> Every 1st and 3rd Tuesday at 01:00 PM EDT
> > >> Bridge: https://bluejeans.com/486278655
> > >>
> > >> Gluster-devel mailing list
> > >> gluster-de...@gluster.org
> > >> https://lists.gluster.org/mailman/listinfo/gluster-devel
> > >>
> > >>
>
> > ___
> >
> > Community Meeting Calendar:
> >
> > APAC Schedule -
> > Every 2nd and 4th Tuesday at 11:30 AM IST
> > Bridge: https://bluejeans.com/118564314
> >
> > NA/EMEA Schedule -
> > Every 1st and 3rd Tuesday at 01:00 PM EDT
> > Bridge: https://bluejeans.com/118564314
> >
> > Gluster-devel mailing list
> > gluster-de...@gluster.org
> > https://lists.gluster.org/mailman/listinfo/gluster-devel
> >
>
>
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-10-14 Thread Niels de Vos 
On Mon, Oct 14, 2019 at 03:52:30PM +0530, Amar Tumballi wrote:
> Any thoughts on this?
> 
> I tried a basic .travis.yml for the unified glusterfs repo I am
> maintaining, and it is good enough for getting most of the tests.
> Considering we are very close to glusterfs-7.0 release, it is good to time
> this after 7.0 release.

Is there a reason to move to Travis? GitHub does offer integration with
Jenkins, so we should be able to keep using our existing CI, I think?

Niels


> 
> -Amar
> 
> On Thu, Sep 5, 2019 at 5:13 PM Amar Tumballi  wrote:
> 
> > Going through the thread, I see in general positive responses for the
> > same, with few points on review system, and not loosing information when
> > merging the patches.
> >
> > While we are working on that, we need to see and understand how our CI/CD
> > looks like with github migration. We surely need suggestion and volunteers
> > here to get this going.
> >
> > Regards,
> > Amar
> >
> >
> > On Wed, Aug 28, 2019 at 12:38 PM Niels de Vos  wrote:
> >
> >> On Tue, Aug 27, 2019 at 06:57:14AM +0530, Amar Tumballi Suryanarayan
> >> wrote:
> >> > On Tue, Aug 27, 2019 at 12:10 AM Niels de Vos 
> >> wrote:
> >> >
> >> > > On Mon, Aug 26, 2019 at 08:36:30PM +0530, Aravinda Vishwanathapura
> >> Krishna
> >> > > Murthy wrote:
> >> > > > On Mon, Aug 26, 2019 at 7:49 PM Joe Julian 
> >> wrote:
> >> > > >
> >> > > > > > Comparing the changes between revisions is something
> >> > > > > that GitHub does not support...
> >> > > > >
> >> > > > > It does support that,
> >> > > > > actually.___
> >> > > > >
> >> > > >
> >> > > > Yes, it does support. We need to use Squash merge after all review
> >> is
> >> > > done.
> >> > >
> >> > > Squash merge would also combine multiple commits that are intended to
> >> > > stay separate. This is really bad :-(
> >> > >
> >> > >
> >> > We should treat 1 patch in gerrit as 1 PR in github, then squash merge
> >> > works same as how reviews in gerrit are done.  Or we can come up with
> >> > label, upon which we can actually do 'rebase and merge' option, which
> >> can
> >> > preserve the commits as is.
> >>
> >> Something like that would be good. For many things, including commit
> >> message update squashing patches is just loosing details. We dont do
> >> that with Gerrit now, and we should not do that when using GitHub PRs.
> >> Proper documenting changes is still very important to me, the details of
> >> patches should be explained in commit messages. This only works well
> >> when developers 'force push' to the branch holding the PR.
> >>
> >> Niels
> >> ___
> >>
> >> Community Meeting Calendar:
> >>
> >> APAC Schedule -
> >> Every 2nd and 4th Tuesday at 11:30 AM IST
> >> Bridge: https://bluejeans.com/836554017
> >>
> >> NA/EMEA Schedule -
> >> Every 1st and 3rd Tuesday at 01:00 PM EDT
> >> Bridge: https://bluejeans.com/486278655
> >>
> >> Gluster-devel mailing list
> >> gluster-de...@gluster.org
> >> https://lists.gluster.org/mailman/listinfo/gluster-devel
> >>
> >>

> ___
> 
> Community Meeting Calendar:
> 
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/118564314
> 
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/118564314
> 
> Gluster-devel mailing list
> gluster-de...@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
> 

___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-10-14 Thread Amar Tumballi 
Any thoughts on this?

I tried a basic .travis.yml for the unified glusterfs repo I am
maintaining, and it is good enough for getting most of the tests.
Considering we are very close to glusterfs-7.0 release, it is good to time
this after 7.0 release.

-Amar

On Thu, Sep 5, 2019 at 5:13 PM Amar Tumballi  wrote:

> Going through the thread, I see in general positive responses for the
> same, with few points on review system, and not loosing information when
> merging the patches.
>
> While we are working on that, we need to see and understand how our CI/CD
> looks like with github migration. We surely need suggestion and volunteers
> here to get this going.
>
> Regards,
> Amar
>
>
> On Wed, Aug 28, 2019 at 12:38 PM Niels de Vos  wrote:
>
>> On Tue, Aug 27, 2019 at 06:57:14AM +0530, Amar Tumballi Suryanarayan
>> wrote:
>> > On Tue, Aug 27, 2019 at 12:10 AM Niels de Vos 
>> wrote:
>> >
>> > > On Mon, Aug 26, 2019 at 08:36:30PM +0530, Aravinda Vishwanathapura
>> Krishna
>> > > Murthy wrote:
>> > > > On Mon, Aug 26, 2019 at 7:49 PM Joe Julian 
>> wrote:
>> > > >
>> > > > > > Comparing the changes between revisions is something
>> > > > > that GitHub does not support...
>> > > > >
>> > > > > It does support that,
>> > > > > actually.___
>> > > > >
>> > > >
>> > > > Yes, it does support. We need to use Squash merge after all review
>> is
>> > > done.
>> > >
>> > > Squash merge would also combine multiple commits that are intended to
>> > > stay separate. This is really bad :-(
>> > >
>> > >
>> > We should treat 1 patch in gerrit as 1 PR in github, then squash merge
>> > works same as how reviews in gerrit are done.  Or we can come up with
>> > label, upon which we can actually do 'rebase and merge' option, which
>> can
>> > preserve the commits as is.
>>
>> Something like that would be good. For many things, including commit
>> message update squashing patches is just loosing details. We dont do
>> that with Gerrit now, and we should not do that when using GitHub PRs.
>> Proper documenting changes is still very important to me, the details of
>> patches should be explained in commit messages. This only works well
>> when developers 'force push' to the branch holding the PR.
>>
>> Niels
>> ___
>>
>> Community Meeting Calendar:
>>
>> APAC Schedule -
>> Every 2nd and 4th Tuesday at 11:30 AM IST
>> Bridge: https://bluejeans.com/836554017
>>
>> NA/EMEA Schedule -
>> Every 1st and 3rd Tuesday at 01:00 PM EDT
>> Bridge: https://bluejeans.com/486278655
>>
>> Gluster-devel mailing list
>> gluster-de...@gluster.org
>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>>
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-09-24 Thread Barak Sason Rofman 
Greetings all,

As a new developer on the project, I might add a fresh look on the matter.

Before I can here I was familiar with Github and unfamiliar with Gerrit.
Understanding Gerrit itself wasn't too troublesome, but also not needed as
I see no benefit of using that system, because as others suggested,
solutions like Gerrithub exist.
In general centralized workflow is always welcomed and personally I'd be
happy to make the switch.
+1 for me.

On Mon, Aug 26, 2019 at 10:06 AM Ravishankar N 
wrote:

>
> On 24/08/19 9:26 AM, Yaniv Kaul wrote:
> > I don't like mixed mode, but I also dislike Github's code review
> > tools, so I'd like to remind the option of using http://gerrithub.io/
> > for code review.
> > Other than that, I'm in favor of moving over.
> > Y.
> +1 for using gerrithub for code review when we move to github.
> ___
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/836554017
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/486278655
>
> Gluster-devel mailing list
> gluster-de...@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>

-- 
*Barak Sason Rofman*

Gluster Storage Development

Red Hat Israel 

34 Jerusalem rd. Ra'anana, 43501

bsaso...@redhat.com T: *+972-9-7692304*
M: *+972-52-4326355*

___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-09-05 Thread Amar Tumballi 
Going through the thread, I see in general positive responses for the same,
with few points on review system, and not loosing information when merging
the patches.

While we are working on that, we need to see and understand how our CI/CD
looks like with github migration. We surely need suggestion and volunteers
here to get this going.

Regards,
Amar


On Wed, Aug 28, 2019 at 12:38 PM Niels de Vos  wrote:

> On Tue, Aug 27, 2019 at 06:57:14AM +0530, Amar Tumballi Suryanarayan wrote:
> > On Tue, Aug 27, 2019 at 12:10 AM Niels de Vos  wrote:
> >
> > > On Mon, Aug 26, 2019 at 08:36:30PM +0530, Aravinda Vishwanathapura
> Krishna
> > > Murthy wrote:
> > > > On Mon, Aug 26, 2019 at 7:49 PM Joe Julian 
> wrote:
> > > >
> > > > > > Comparing the changes between revisions is something
> > > > > that GitHub does not support...
> > > > >
> > > > > It does support that,
> > > > > actually.___
> > > > >
> > > >
> > > > Yes, it does support. We need to use Squash merge after all review is
> > > done.
> > >
> > > Squash merge would also combine multiple commits that are intended to
> > > stay separate. This is really bad :-(
> > >
> > >
> > We should treat 1 patch in gerrit as 1 PR in github, then squash merge
> > works same as how reviews in gerrit are done.  Or we can come up with
> > label, upon which we can actually do 'rebase and merge' option, which can
> > preserve the commits as is.
>
> Something like that would be good. For many things, including commit
> message update squashing patches is just loosing details. We dont do
> that with Gerrit now, and we should not do that when using GitHub PRs.
> Proper documenting changes is still very important to me, the details of
> patches should be explained in commit messages. This only works well
> when developers 'force push' to the branch holding the PR.
>
> Niels
> ___
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/836554017
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/486278655
>
> Gluster-devel mailing list
> gluster-de...@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-08-28 Thread Niels de Vos 
On Tue, Aug 27, 2019 at 06:57:14AM +0530, Amar Tumballi Suryanarayan wrote:
> On Tue, Aug 27, 2019 at 12:10 AM Niels de Vos  wrote:
> 
> > On Mon, Aug 26, 2019 at 08:36:30PM +0530, Aravinda Vishwanathapura Krishna
> > Murthy wrote:
> > > On Mon, Aug 26, 2019 at 7:49 PM Joe Julian  wrote:
> > >
> > > > > Comparing the changes between revisions is something
> > > > that GitHub does not support...
> > > >
> > > > It does support that,
> > > > actually.___
> > > >
> > >
> > > Yes, it does support. We need to use Squash merge after all review is
> > done.
> >
> > Squash merge would also combine multiple commits that are intended to
> > stay separate. This is really bad :-(
> >
> >
> We should treat 1 patch in gerrit as 1 PR in github, then squash merge
> works same as how reviews in gerrit are done.  Or we can come up with
> label, upon which we can actually do 'rebase and merge' option, which can
> preserve the commits as is.

Something like that would be good. For many things, including commit
message update squashing patches is just loosing details. We dont do
that with Gerrit now, and we should not do that when using GitHub PRs.
Proper documenting changes is still very important to me, the details of
patches should be explained in commit messages. This only works well
when developers 'force push' to the branch holding the PR.

Niels
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-08-26 Thread Amar Tumballi Suryanarayan 
On Tue, Aug 27, 2019 at 12:10 AM Niels de Vos  wrote:

> On Mon, Aug 26, 2019 at 08:36:30PM +0530, Aravinda Vishwanathapura Krishna
> Murthy wrote:
> > On Mon, Aug 26, 2019 at 7:49 PM Joe Julian  wrote:
> >
> > > > Comparing the changes between revisions is something
> > > that GitHub does not support...
> > >
> > > It does support that,
> > > actually.___
> > >
> >
> > Yes, it does support. We need to use Squash merge after all review is
> done.
>
> Squash merge would also combine multiple commits that are intended to
> stay separate. This is really bad :-(
>
>
We should treat 1 patch in gerrit as 1 PR in github, then squash merge
works same as how reviews in gerrit are done.  Or we can come up with
label, upon which we can actually do 'rebase and merge' option, which can
preserve the commits as is.

-Amar


> Niels
> ___
> maintainers mailing list
> maintainers@gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>


-- 
Amar Tumballi (amarts)
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-08-26 Thread FNU Raghavendra Manjunath 
+1 to the idea.

On Mon, Aug 26, 2019 at 2:41 PM Niels de Vos  wrote:

> On Mon, Aug 26, 2019 at 08:08:36AM -0700, Joe Julian wrote:
> > You can also see diffs between force pushes now.
>
> That is great! It is the feature that I was looking for. I have not
> noticed it yet, will pay attention to it while working on other
> projects.
>
> Thanks,
> Niels
> ___
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/836554017
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/486278655
>
> Gluster-devel mailing list
> gluster-de...@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-08-26 Thread Niels de Vos 
On Mon, Aug 26, 2019 at 08:08:36AM -0700, Joe Julian wrote:
> You can also see diffs between force pushes now.

That is great! It is the feature that I was looking for. I have not
noticed it yet, will pay attention to it while working on other
projects.

Thanks,
Niels
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-08-26 Thread Niels de Vos 
On Mon, Aug 26, 2019 at 08:36:30PM +0530, Aravinda Vishwanathapura Krishna 
Murthy wrote:
> On Mon, Aug 26, 2019 at 7:49 PM Joe Julian  wrote:
> 
> > > Comparing the changes between revisions is something
> > that GitHub does not support...
> >
> > It does support that,
> > actually.___
> >
> 
> Yes, it does support. We need to use Squash merge after all review is done.

Squash merge would also combine multiple commits that are intended to
stay separate. This is really bad :-(

Niels
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-08-26 Thread Aravinda Vishwanathapura Krishna Murthy 
On Mon, Aug 26, 2019 at 8:44 PM Joe Julian  wrote:

> You can also see diffs between force pushes now.
>

Nice.


> On August 26, 2019 8:06:30 AM PDT, Aravinda Vishwanathapura Krishna Murthy
>  wrote:
>>
>>
>>
>> On Mon, Aug 26, 2019 at 7:49 PM Joe Julian  wrote:
>>
>>> > Comparing the changes between revisions is something
>>> that GitHub does not support...
>>>
>>> It does support that,
>>> actually.___
>>>
>>
>> Yes, it does support. We need to use Squash merge after all review is
>> done.
>> A sample pull request is here to see reviews with multiple revisions.
>>
>> https://github.com/aravindavk/reviewdemo/pull/1
>>
>>
>>
>>
>>> maintainers mailing list
>>> maintainers@gluster.org
>>> https://lists.gluster.org/mailman/listinfo/maintainers
>>>
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>


-- 
regards
Aravinda VK
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-08-26 Thread Joe Julian 
You can also see diffs between force pushes now.

On August 26, 2019 8:06:30 AM PDT, Aravinda Vishwanathapura Krishna Murthy 
 wrote:
>On Mon, Aug 26, 2019 at 7:49 PM Joe Julian 
>wrote:
>
>> > Comparing the changes between revisions is something
>> that GitHub does not support...
>>
>> It does support that,
>> actually.___
>>
>
>Yes, it does support. We need to use Squash merge after all review is
>done.
>A sample pull request is here to see reviews with multiple revisions.
>
>https://github.com/aravindavk/reviewdemo/pull/1
>
>
>
>
>> maintainers mailing list
>> maintainers@gluster.org
>> https://lists.gluster.org/mailman/listinfo/maintainers
>>
>
>
>-- 
>regards
>Aravinda VK

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-08-26 Thread Aravinda Vishwanathapura Krishna Murthy 
On Mon, Aug 26, 2019 at 7:49 PM Joe Julian  wrote:

> > Comparing the changes between revisions is something
> that GitHub does not support...
>
> It does support that,
> actually.___
>

Yes, it does support. We need to use Squash merge after all review is done.
A sample pull request is here to see reviews with multiple revisions.

https://github.com/aravindavk/reviewdemo/pull/1




> maintainers mailing list
> maintainers@gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>


-- 
regards
Aravinda VK
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-08-26 Thread Joe Julian 
> Comparing the changes between revisions is something
that GitHub does not support...

It does support that, actually.___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-08-26 Thread Niels de Vos 
On Fri, Aug 23, 2019 at 11:56:53PM -0400, Yaniv Kaul wrote:
> On Fri, 23 Aug 2019, 9:13 Amar Tumballi  wrote:
> 
> > Hi developers,
> >
> > With this email, I want to understand what is the general feeling around
> > this topic.
> >
> > We from gluster org (in github.com/gluster) have many projects which
> > follow complete github workflow, where as there are few, specially the main
> > one 'glusterfs', which uses 'Gerrit'.
> >
> > While this has worked all these years, currently, there is a huge set of
> > brain-share on github workflow as many other top projects, and similar
> > projects use only github as the place to develop, track and run tests etc.
> > As it is possible to have all of the tools required for this project in
> > github itself (code, PR, issues, CI/CD, docs), lets look at how we are
> > structured today:
> >
> > Gerrit - glusterfs code + Review system
> > Bugzilla - For bugs
> > Github - For feature requests
> > Trello - (not very much used) for tracking project development.
> > CI/CD - CentOS-ci / Jenkins, etc but maintained from different repo.
> > Docs - glusterdocs - different repo.
> > Metrics - Nothing (other than github itself tracking contributors).
> >
> > While it may cause a minor glitch for many long time developers who are
> > used to the flow, moving to github would bring all these in single place,
> > makes getting new users easy, and uniform development practices for all
> > gluster org repositories.
> >
> > As it is just the proposal, I would like to hear people's thought on this,
> > and conclude on this another month, so by glusterfs-8 development time, we
> > are clear about this.
> >
> 
> I don't like mixed mode, but I also dislike Github's code review tools, so
> I'd like to remind the option of using http://gerrithub.io/ for code
> review.
> Other than that, I'm in favor of moving over.
> Y.

I agree that using GitHub for code review is not optimal. We have many
patches for the GlusterFS project that need multiple rounds of review
and corrections. Comparing the changes between revisions is something
that GitHub does not support, but Gerrit/GerritHub does.

Before switching over, there also needs to be documentation how to
structure the issues in GitHubs tracker (which labels to use, what they
mean etc,). Also, what about migration of bugs from Bugzilla to GitHub?

Except for those topics, I don't have a problem with moving to GitHub.

Niels
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

2019-08-23 Thread Yaniv Kaul 
On Fri, 23 Aug 2019, 9:13 Amar Tumballi  wrote:

> Hi developers,
>
> With this email, I want to understand what is the general feeling around
> this topic.
>
> We from gluster org (in github.com/gluster) have many projects which
> follow complete github workflow, where as there are few, specially the main
> one 'glusterfs', which uses 'Gerrit'.
>
> While this has worked all these years, currently, there is a huge set of
> brain-share on github workflow as many other top projects, and similar
> projects use only github as the place to develop, track and run tests etc.
> As it is possible to have all of the tools required for this project in
> github itself (code, PR, issues, CI/CD, docs), lets look at how we are
> structured today:
>
> Gerrit - glusterfs code + Review system
> Bugzilla - For bugs
> Github - For feature requests
> Trello - (not very much used) for tracking project development.
> CI/CD - CentOS-ci / Jenkins, etc but maintained from different repo.
> Docs - glusterdocs - different repo.
> Metrics - Nothing (other than github itself tracking contributors).
>
> While it may cause a minor glitch for many long time developers who are
> used to the flow, moving to github would bring all these in single place,
> makes getting new users easy, and uniform development practices for all
> gluster org repositories.
>
> As it is just the proposal, I would like to hear people's thought on this,
> and conclude on this another month, so by glusterfs-8 development time, we
> are clear about this.
>

I don't like mixed mode, but I also dislike Github's code review tools, so
I'd like to remind the option of using http://gerrithub.io/ for code
review.
Other than that, I'm in favor of moving over.
Y.


> Can we decide on this before September 30th? Please voice your concerns.
>
> Regards,
> Amar
>
>
>
> ___
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/836554017
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/486278655
>
> Gluster-devel mailing list
> gluster-de...@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers