[Gluster-Maintainers] Fwd: Build failed in Jenkins: regression-test-burn-in #4710

2019-08-26 Thread Atin Mukherjee 
Since last few days I was trying to understand the nightly failures we were
seeing even after addressing the port already in use issue. So here's the
analysis:

>From console output of
https://build.gluster.org/job/regression-test-burn-in/4710/consoleFull



*19:51:56* Started by upstream project "nightly-master
" build number 843
*19:51:56*
originally caused by:*19:51:56*  Started by timer*19:51:56* Running as
SYSTEM*19:51:57* Building remotely on builder209.aws.gluster.org

(centos7) in workspace
/home/jenkins/root/workspace/regression-test-burn-in*19:51:58* No
credentials specified*19:51:58*  > git rev-parse --is-inside-work-tree
# timeout=10*19:51:58* Fetching changes from the remote Git
repository*19:51:58*  > git config remote.origin.url
git://review.gluster.org/glusterfs.git # timeout=10*19:51:58* Fetching
upstream changes from git://review.gluster.org/glusterfs.git*19:51:58*
 > git --version # timeout=10*19:51:58*  > git fetch --tags --progress
git://review.gluster.org/glusterfs.git refs/heads/master #
timeout=10*19:52:01*  > git rev-parse origin/master^{commit} #
timeout=10*19:52:01* Checking out Revision
a31fad885c30cbc1bea652349c7d52bac1414c08 (origin/master)*19:52:01*  >
git config core.sparsecheckout # timeout=10*19:52:01  > git checkout
-f a31fad885c30cbc1bea652349c7d52bac1414c08 # timeout=10
19:52:02 Commit message: "tests: heal-info add --xml option for more
coverage"**19:52:02*  > git rev-list --no-walk
a31fad885c30cbc1bea652349c7d52bac1414c08 # timeout=10*19:52:02*
[regression-test-burn-in] $ /bin/bash
/tmp/jenkins7274529097702336737.sh*19:52:02* Start time Mon Aug 26
14:22:02 UTC 2019




The latest commit which it picked up as part of git checkout is quite old
and hence we continue to see the similar failures in the latest nightly
runs which has been already addressed by commit c370c70

commit c370c70f77079339e2cfb7f284f3a2fb13fd2f97
Author: Mohit Agrawal 
Date:   Tue Aug 13 18:45:43 2019 +0530

rpc: glusterd start is failed and throwing an error Address already in
use

Problem: Some of the .t are failed due to bind is throwing
 an error EADDRINUSE

Solution: After killing all gluster processes .t is trying
  to start glusterd but somehow if kernel has not cleaned
  up resources(socket) then glusterd startup is failed due to
  bind system call failure.To avoid the issue retries to call
  bind 10 times to execute system call succesfully

Change-Id: Ia5fd6b788f7b211c1508c1b7304fc08a32266629
Fixes: bz#1743020
Signed-off-by: Mohit Agrawal 

So the (puzzling) question is - why are we picking up old commit?

In my local setup when I run the following command I do see the latest
commit id being picked up:

atin@dhcp35-96:~/codebase/upstream/glusterfs_master/glusterfs$ git
rev-parse origin/master^{commit} # timeout=10
7926992e65d0a07fdc784a6e45740306d9b4a9f2

atin@dhcp35-96:~/codebase/upstream/glusterfs_master/glusterfs$ git show
7926992e65d0a07fdc784a6e45740306d9b4a9f2
commit 7926992e65d0a07fdc784a6e45740306d9b4a9f2 (origin/master,
origin/HEAD, master)
Author: Sanju Rakonde 
Date:   Mon Aug 26 12:38:40 2019 +0530

glusterd: Unused value coverity fix

CID: 1288765
updates: bz#789278

Change-Id: Ie6b01f81339769f44d82fd7c32ad0ed1a697c69c
Signed-off-by: Sanju Rakonde 



-- Forwarded message -
From: 
Date: Mon, Aug 26, 2019 at 11:32 PM
Subject: [Gluster-Maintainers] Build failed in Jenkins:
regression-test-burn-in #4710
To: 


See <
https://build.gluster.org/job/regression-test-burn-in/4710/display/redirect>

--
[...truncated 4.18 MB...]
./tests/features/lock-migration/lkmigration-set-option.t  -  7 second
./tests/bugs/upcall/bug-1458127.t  -  7 second
./tests/bugs/transport/bug-873367.t  -  7 second
./tests/bugs/snapshot/bug-1260848.t  -  7 second
./tests/bugs/shard/shard-inode-refcount-test.t  -  7 second
./tests/bugs/replicate/bug-986905.t  -  7 second
./tests/bugs/replicate/bug-921231.t  -  7 second
./tests/bugs/replicate/bug-1132102.t  -  7 second
./tests/bugs/replicate/bug-1037501.t  -  7 second
./tests/bugs/posix/bug-1175711.t  -  7 second
./tests/bugs/posix/bug-1122028.t  -  7 second
./tests/bugs/glusterfs/bug-861015-log.t  -  7 second
./tests/bugs/fuse/bug-983477.t  -  7 second
./tests/bugs/ec/bug-1227869.t  -  7 second
./tests/bugs/distribute/bug-1086228.t  -  7 second
./tests/bugs/cli/bug-1087487.t  -  7 second
./tests/bitrot/br-stub.t  -  7 second
./tests/basic/ctime/ctime-noatime.t  -  7 second
./tests/basic/afr/ta-write-on-bad-brick.t  -  7 second
./tests/basic/afr/ta.t  -  7 second
./tests/basic/afr/ta-shd.t  -  7 second
./tests/basic/afr/root-squash-self-heal.t  -  7 second
./tests/basic/afr/granular-esh/add-brick.t  -  7 second
./tests/bugs/upcall/bug-1369430.t  -

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

[Gluster-Maintainers] Build failed in Jenkins: regression-test-burn-in #4710

2019-08-26 Thread jenkins 
See 


--
[...truncated 4.18 MB...]
./tests/features/lock-migration/lkmigration-set-option.t  -  7 second
./tests/bugs/upcall/bug-1458127.t  -  7 second
./tests/bugs/transport/bug-873367.t  -  7 second
./tests/bugs/snapshot/bug-1260848.t  -  7 second
./tests/bugs/shard/shard-inode-refcount-test.t  -  7 second
./tests/bugs/replicate/bug-986905.t  -  7 second
./tests/bugs/replicate/bug-921231.t  -  7 second
./tests/bugs/replicate/bug-1132102.t  -  7 second
./tests/bugs/replicate/bug-1037501.t  -  7 second
./tests/bugs/posix/bug-1175711.t  -  7 second
./tests/bugs/posix/bug-1122028.t  -  7 second
./tests/bugs/glusterfs/bug-861015-log.t  -  7 second
./tests/bugs/fuse/bug-983477.t  -  7 second
./tests/bugs/ec/bug-1227869.t  -  7 second
./tests/bugs/distribute/bug-1086228.t  -  7 second
./tests/bugs/cli/bug-1087487.t  -  7 second
./tests/bitrot/br-stub.t  -  7 second
./tests/basic/ctime/ctime-noatime.t  -  7 second
./tests/basic/afr/ta-write-on-bad-brick.t  -  7 second
./tests/basic/afr/ta.t  -  7 second
./tests/basic/afr/ta-shd.t  -  7 second
./tests/basic/afr/root-squash-self-heal.t  -  7 second
./tests/basic/afr/granular-esh/add-brick.t  -  7 second
./tests/bugs/upcall/bug-1369430.t  -  6 second
./tests/bugs/snapshot/bug-1064768.t  -  6 second
./tests/bugs/shard/bug-1258334.t  -  6 second
./tests/bugs/replicate/bug-1250170-fsync.t  -  6 second
./tests/bugs/quota/bug-1250582-volume-reset-should-not-remove-quota-quota-deem-statfs.t
  -  6 second
./tests/bugs/quota/bug-1243798.t  -  6 second
./tests/bugs/quota/bug-1104692.t  -  6 second
./tests/bugs/protocol/bug-1321578.t  -  6 second
./tests/bugs/nfs/bug-915280.t  -  6 second
./tests/bugs/io-cache/bug-858242.t  -  6 second
./tests/bugs/glusterfs-server/bug-877992.t  -  6 second
./tests/bugs/glusterfs/bug-902610.t  -  6 second
./tests/bugs/distribute/bug-884597.t  -  6 second
./tests/bugs/core/bug-1699025-brick-mux-detach-brick-fd-issue.t  -  6 second
./tests/bugs/core/bug-1168803-snapd-option-validation-fix.t  -  6 second
./tests/bugs/bug-1702299.t  -  6 second
./tests/bugs/bug-1371806_2.t  -  6 second
./tests/bugs/bug-1258069.t  -  6 second
./tests/bugs/bitrot/1209818-vol-info-show-scrub-process-properly.t  -  6 second
./tests/bugs/bitrot/1209751-bitrot-scrub-tunable-reset.t  -  6 second
./tests/basic/glusterd/thin-arbiter-volume-probe.t  -  6 second
./tests/basic/gfapi/libgfapi-fini-hang.t  -  6 second
./tests/basic/fencing/fencing-crash-conistency.t  -  6 second
./tests/basic/ec/statedump.t  -  6 second
./tests/basic/distribute/file-create.t  -  6 second
./tests/basic/afr/tarissue.t  -  6 second
./tests/basic/afr/gfid-heal.t  -  6 second
./tests/basic/afr/afr-read-hash-mode.t  -  6 second
./tests/basic/afr/add-brick-self-heal.t  -  6 second
./tests/gfid2path/gfid2path_fuse.t  -  5 second
./tests/bugs/shard/bug-1259651.t  -  5 second
./tests/bugs/replicate/bug-767585-gfid.t  -  5 second
./tests/bugs/replicate/bug-1686568-send-truncate-on-arbiter-from-shd.t  -  5 
second
./tests/bugs/replicate/bug-1626994-info-split-brain.t  -  5 second
./tests/bugs/replicate/bug-1365455.t  -  5 second
./tests/bugs/replicate/bug-1101647.t  -  5 second
./tests/bugs/nfs/bug-877885.t  -  5 second
./tests/bugs/nfs/bug-847622.t  -  5 second
./tests/bugs/nfs/bug-1116503.t  -  5 second
./tests/bugs/md-cache/setxattr-prepoststat.t  -  5 second
./tests/bugs/md-cache/bug-1211863_unlink.t  -  5 second
./tests/bugs/md-cache/afr-stale-read.t  -  5 second
./tests/bugs/io-stats/bug-1598548.t  -  5 second
./tests/bugs/glusterfs/bug-895235.t  -  5 second
./tests/bugs/glusterfs/bug-856455.t  -  5 second
./tests/bugs/glusterfs/bug-848251.t  -  5 second
./tests/bugs/glusterd/quorum-value-check.t  -  5 second
./tests/bugs/glusterd/bug-1242875-do-not-pass-volinfo-quota.t  -  5 second
./tests/bugs/ec/bug-1179050.t  -  5 second
./tests/bugs/distribute/bug-912564.t  -  5 second
./tests/bugs/distribute/bug-1368012.t  -  5 second
./tests/bugs/core/bug-986429.t  -  5 second
./tests/bugs/core/bug-908146.t  -  5 second
./tests/bugs/bug-1371806_1.t  -  5 second
./tests/bugs/bitrot/bug-1229134-bitd-not-support-vol-set.t  -  5 second
./tests/bugs/bitrot/1207029-bitrot-daemon-should-start-on-valid-node.t  -  5 
second
./tests/basic/playground/template-xlator-sanity.t  -  5 second
./tests/basic/hardlink-limit.t  -  5 second
./tests/basic/glusterd/arbiter-volume-probe.t  -  5 second
./tests/basic/ec/nfs.t  -  5 second
./tests/basic/ec/ec-read-policy.t  -  5 second
./tests/basic/ec/ec-anonymous-fd.t  -  5 second
./tests/basic/afr/arbiter-remove-brick.t  -  5 second
./tests/gfid2path/gfid2path_nfs.t  -  4 second
./tests/gfid2path/get-gfid-to-path.t  -  4 second
./tests/gfid2path/block-mount-access.t  -  4 second
./tests/bugs/upcall/bug-upcall-stat.t  -  4 second
./tests/bugs/trace/bug-797171.t  -  4 second
./tests/bugs/snapshot/bug-1178079.t  -  4 second
./tests/bugs/shard/bug-1342298.t  -  4

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

[Gluster-Maintainers] Build failed in Jenkins: regression-test-with-multiplex #1475

2019-08-26 Thread jenkins 
See 


--
[...truncated 67.47 KB...]
at jenkins.util.io.PathRemover.tryRemoveRecursive(PathRemover.java:212)
at 
jenkins.util.io.PathRemover.tryRemoveDirectoryContents(PathRemover.java:222)
at jenkins.util.io.PathRemover.tryRemoveRecursive(PathRemover.java:211)
at 
jenkins.util.io.PathRemover.tryRemoveDirectoryContents(PathRemover.java:222)
at jenkins.util.io.PathRemover.tryRemoveRecursive(PathRemover.java:211)
at 
jenkins.util.io.PathRemover.tryRemoveDirectoryContents(PathRemover.java:222)
at jenkins.util.io.PathRemover.tryRemoveRecursive(PathRemover.java:211)
at 
jenkins.util.io.PathRemover.tryRemoveDirectoryContents(PathRemover.java:222)
at 
jenkins.util.io.PathRemover.forceRemoveDirectoryContents(PathRemover.java:83)
at hudson.Util.deleteContentsRecursive(Util.java:259)
at hudson.Util.deleteContentsRecursive(Util.java:248)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:653)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:161)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:154)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
java.nio.file.FileSystemException: 
:/d/backends/patchy1:
 Operation not permitted
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:91)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at 
sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:238)
at 
sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:260)
at java.nio.file.Files.setPosixFilePermissions(Files.java:2045)
at jenkins.util.io.PathRemover.makeWritable(PathRemover.java:282)
at jenkins.util.io.PathRemover.makeRemovable(PathRemover.java:255)
at 
jenkins.util.io.PathRemover.removeOrMakeRemovableThenRemove(PathRemover.java:235)
at jenkins.util.io.PathRemover.tryRemoveFile(PathRemover.java:201)
at jenkins.util.io.PathRemover.tryRemoveRecursive(PathRemover.java:212)
at 
jenkins.util.io.PathRemover.tryRemoveDirectoryContents(PathRemover.java:222)
at jenkins.util.io.PathRemover.tryRemoveRecursive(PathRemover.java:211)
at 
jenkins.util.io.PathRemover.tryRemoveDirectoryContents(PathRemover.java:222)
at jenkins.util.io.PathRemover.tryRemoveRecursive(PathRemover.java:211)
at 
jenkins.util.io.PathRemover.tryRemoveDirectoryContents(PathRemover.java:222)
at jenkins.util.io.PathRemover.tryRemoveRecursive(PathRemover.java:211)
at 
jenkins.util.io.PathRemover.tryRemoveDirectoryContents(PathRemover.java:222)
at 
jenkins.util.io.PathRemover.forceRemoveDirectoryContents(PathRemover.java:83)
at hudson.Util.deleteContentsRecursive(Util.java:259)
at hudson.Util.deleteContentsRecursive(Util.java:248)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:653)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:161)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:154)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
java.nio.file.FileSystemException:

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] Proposal: move glusterfs development to github workflow, completely

2019-08-26 Thread Vijay Bellur 
On Fri, Aug 23, 2019 at 6:12 AM 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.
>
>
+1 to the idea.

While we are at this, any more thoughts about consolidating
IRC/Slack/gitter etc.?

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