On Wed, Jun 25, 2014 at 9:35 PM, Jeff Darcy wrote:
>> While I agree with everything you said. Complaining about tabs/spaces
>> should be done by a script. Something like
>> http://review.gluster.com/#/c/5404
>> Some one who knows perl should help us with rebasing it and getting it in
>
> Agreed.
On 26/06/2014, at 1:18 AM, Justin Clift wrote:
> On 25/06/2014, at 11:19 PM, Justin Clift wrote:
>> There's a new "rackspace-regression-2GB-triggered" in Jenkins on
>> build.gluster.org.
>>
>> Please ignore it for now. I'm just experimenting with having Gerrit
>> automatically trigger regression
> While I agree with everything you said. Complaining about tabs/spaces
> should be done by a script. Something like
> http://review.gluster.com/#/c/5404
> Some one who knows perl should help us with rebasing it and getting it in
Agreed. If there are standards that are going to be enforced even i
Can you chuck that on the wiki in a new page?
We can link to it from the Developers section. I have .vimrc
settings around somewhere that can be added too. :)
+ Justin
On 26/06/2014, at 1:54 AM, Harshavardhana wrote:
> Been thinking about rebasing it, let me think about a cleaner way.
>
> For
On 26/06/2014, at 2:12 AM, Pranith Kumar Karampuri wrote:
> On 06/26/2014 06:19 AM, Justin Clift wrote:
>> On 26/06/2014, at 1:40 AM, Pranith Kumar Karampuri wrote:
>>
>>> While I agree with everything you said. Complaining about tabs/spaces
>>> should be done by a script. Something like
>>> htt
On 06/26/2014 06:19 AM, Justin Clift wrote:
On 26/06/2014, at 1:40 AM, Pranith Kumar Karampuri wrote:
While I agree with everything you said. Complaining about tabs/spaces should be
done by a script. Something like http://review.gluster.com/#/c/5404
+1
And we can use a git trigger to reject
Been thinking about rebasing it, let me think about a cleaner way.
For emacs here you go!
~~~
(defun my-linux-c-mode ()
"C mode with adjusted defaults for use with the linux kernel."
(c-set-style "linux"))
(add-hook 'c-mode-hook 'my-linux-c-mode)
(setq indent-tabs-mode nil)
(add-hook 'python
On 26/06/2014, at 1:40 AM, Pranith Kumar Karampuri wrote:
> While I agree with everything you said. Complaining about tabs/spaces should
> be done by a script. Something like http://review.gluster.com/#/c/5404
+1
And we can use a git trigger to reject future patches that have tabs in
them.
For
On 06/25/2014 10:31 PM, Jeff Darcy wrote:
Justin asked me, as the group's official Grumpy Old Man, to send a note
reminding people about the importance of reviewing patches early. Here
it is. As I see it, we've historically had two problems with reviews.
(1) Patches that don't get reviewed at
On 25/06/2014, at 11:19 PM, Justin Clift wrote:
> There's a new "rackspace-regression-2GB-triggered" in Jenkins on
> build.gluster.org.
>
> Please ignore it for now. I'm just experimenting with having Gerrit
> automatically trigger regression tests.
This seems to be working ok, so I've enabled
There's a new "rackspace-regression-2GB-triggered" in Jenkins on
build.gluster.org.
Please ignore it for now. I'm just experimenting with having Gerrit
automatically trigger regression tests.
Failure/success status doesn't go into Gerrit.
+ Justin
--
GlusterFS - http://www.gluster.org
An ope
On 20/06/2014, at 2:32 PM, Matteo Checcucci wrote:
> On 06/20/2014 03:05 PM, Ravishankar N wrote:
>> Yes, just sent a patch for review on master
>> :http://review.gluster.org/#/c/8135/
>> Once it gets accepted, will back-port it to the 3.5 branch
> I am looking forward to seeing it back-ported and
Hi Anders,
There are multiple problems that I see in the test provided, here is answering
one of them and the reason why this occurs. It does get into the code and
functions a bit, but bottom line is that on a code path the setattr that DHT
does, misses setting the SGID bit causing the problem
SRC:
http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.4.5beta1.tar.gz
This release is made off jenkins-release-79
-- Gluster Build System
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/lis
SRC:
http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-release-3.4.tar.gz
This release is made off jenkins-release-78
-- Gluster Build System
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/li
On 25/06/2014, at 8:10 AM, Lalatendu Mohanty wrote:
> On 06/24/2014 03:45 PM, Gluster Build System wrote:
>>
>> SRC: http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.5.1.tar.gz
>>
>> This release is made off jenkins-release-73
>>
>> -- Gluster Build System
>> ___
Justin asked me, as the group's official Grumpy Old Man, to send a note
reminding people about the importance of reviewing patches early. Here
it is. As I see it, we've historically had two problems with reviews.
(1) Patches that don't get reviewed at all.
(2) Patches that have to be re-worked
Thanks to everyone who attended and participated in our
Weekly Community Meeting today. :)
The points which stand out as most important/interesting are:
* GlusterFS 3.4.5 beta1 tarball and rpms to be created
soon (next few days likely)
This is pretty much GlusterFS 3.4.4-2 with the
> If I understand correctly the proposed data-classification
> architecture, each server will have a number of bricks that will be
> dynamically modified as needed: as more data-classifying conditions
> are defined, a new layer of translators will be added (a new DHT or
> AFR, or something else) an
On Wednesday 25 June 2014 08:35:05 Jeff Darcy wrote:
> > For the short-term, wouldn't it be OK to disallow adding bricks that
> > is not a multiple of group-size?
>
> In the *very* short term, yes. However, I think that will quickly
> become an issue for users who try to deploy erasure coding bec
- Original Message -
> > For the short-term, wouldn't it be OK to disallow adding bricks that
> > is not a multiple of group-size?
>
> In the *very* short term, yes. However, I think that will quickly
> become an issue for users who try to deploy erasure coding because those
> group size
> For the short-term, wouldn't it be OK to disallow adding bricks that
> is not a multiple of group-size?
In the *very* short term, yes. However, I think that will quickly
become an issue for users who try to deploy erasure coding because those
group sizes will be quite large. As soon as we impl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-06-24 22:26, Shyamsundar Ranganathan wrote:
> - Original Message -
>> From: "Anders Blomdell"
>> To: "Niels de Vos"
>> Cc: "Shyamsundar Ranganathan" , "Gluster Devel"
>> , "Susant Palai"
>>
>> Sent: Tuesday, June 24, 2014 4:09:52 AM
Hi all,
while trying to get 3.5.1 released, I've noticed some difficulties and
inconsistencies on how patches for the stable 3.5.x release get posted.
Unfortunately I had to reject some last minute requests to include some
changes that were not trivial. Some of these patches were waiting
a wh
On 06/25/2014 11:52 AM, Raghavendra Bhat wrote:
On Tuesday 24 June 2014 08:17 PM, Pranith Kumar Karampuri wrote:
Does anyone know why inode_unref is no-op for root inode?
I see the following code in inode.c
static inode_t *
__inode_unref (inode_t *inode)
{
if (!inode)
On 06/24/2014 03:45 PM, Gluster Build System wrote:
SRC: http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.5.1.tar.gz
This release is made off jenkins-release-73
-- Gluster Build System
___
Gluster-users mailing list
gluster-us...@gluster
26 matches
Mail list logo
