On 16 September 2014 08:39, Ian Booth wrote:
>
>
> On 16/09/14 00:50, Eric Snow wrote:
>
>
> > Step (0) is also pretty easy and I'll argue that people should be
> > doing it anyway.
> >
>
> Disagree :-)
> I never (or very, very rarely) had to do this with Launchpad and bzr and
> things
> Just Wor
>
> FWIW, I have the following in $GOPATH/src/github.com/juju/juju/.git/config
> :
>
> [remote "origin"]
> url = g...@github.com:ericsnowcurrently/juju.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [remote "upstream"]
> url = https://github.com/juju/juju.git
>
On 13/09/14 04:49, roger peppe wrote:
> On 12 September 2014 16:55, Eric Snow wrote:
>> In Go we put tests in *_test.go files that are only built when
>> testing. There are two conventions for what package to declare in
>> those files (relative to the corresponding non-test package):
>> "" and "_
On 12/09/14 01:35, Nate Finch wrote:
> Separation of logic is absolutely a good thing. Separation of data is
> not nearly so useful.
What I see as the real benefit of this work is based behind the
"interface segregation principle".
Effectively this boils down to "don't depend on things you don't
Is there a setting to make reviewboard show the diff in a review by
the default ? For some reason for me it always requires me to hit the
'view diff' link.
On Tue, Sep 16, 2014 at 6:39 AM, Ian Booth wrote:
>
>
> On 16/09/14 00:50, Eric Snow wrote:
>> On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow wr
On 12 September 2014 14:46, Katherine Cox-Buday
wrote:
> I have been trying to digest the following series of talks between Martin
> Fowler, Kent Beck, and David Heinemeier, called "Is TDD Dead?". The topic is
> a bit inflammatory, but there's some good stuff here.
Thank you very much for linking
On 16/09/14 00:50, Eric Snow wrote:
> On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow wrote:
>> Yeah, those steps are a lot, though keep in mind that effectively it's
>> only 2 steps more than before if you use the -p flag to rbt post and
>> were already keeping your local master up to date.
>
> Jus
On Mon, Sep 15, 2014 at 12:54 PM, Dimiter Naydenov
wrote:
> - From my meager experience with writing git plugins (any executable in
> $PATH with "git-" prefix), what are you describing can be easily
> achieved. If you write a git plugin, named e.g. "git-rbpropose", using
> the GitHub CLI (https://
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yeah, sorry I forgot the pastebin links to the scripts:
git-sync: http://paste.ubuntu.com/8352455/
git-propose: http://paste.ubuntu.com/8352460/
git config -l | grep alias: http://paste.ubuntu.com/8352470/
(useful aliases I use)
On 15.09.2014 21:54,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Eric,
On 15.09.2014 21:18, Eric Snow wrote:
> On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday
> wrote:
>> Let me preface this by saying I like the Reviewboard style of
>> reviewing changes.
>>
>> It's somewhat concerning to me that our rev
...
>
> There is the possibility of pushing info from ReviewBoard back to
> github (e.g. "ship-it" -> "LGTM" comment), but I don't think it buys
> us enough to make it worth it (it's notably trickier).
>
> -eric
>
> I would think it would be just as easy to change the bot to merge based on
comment
On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday
wrote:
> Let me preface this by saying I like the Reviewboard style of reviewing
> changes.
>
> It's somewhat concerning to me that our reviews are now disconnected from
> what will actually be landed into trunk. In Github, you were reviewing t
Let me preface this by saying I like the Reviewboard style of reviewing
changes.
It's somewhat concerning to me that our reviews are now disconnected from
what will actually be landed into trunk. In Github, you were reviewing the
actual diff which would be landed. In reviewboard, we're now reviewi
Here is a branch that addresses the concerns and bug. I've tested it
locally and with digitalocean. I would love for it to be tested under the
scaling scenario where you first encountered the issues.
https://github.com/wwitzel3/juju/tree/ww3-rsyslogd-logrotate
I've changed the size in logrota
On Sun, Sep 14, 2014 at 10:28 PM, Menno Smits wrote:
> It looks like the TRACKING_BRANCH option in .reviewboardrc could be helpful.
> It defaults to "origin/master" but if we changed it to "upstream/master" I
> suspect Reviewboard will then generate diffs against the shared master
> branch instead
Really, rbt pull -p is the only new step. All the rest of that is stuff
you should already be doing as a normal part of writing code and making
pull requests. I guess adding the link on the PR to the review is also a
new step. If you really want to count that as a step.
On Mon, Sep 15, 2014 at
On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow wrote:
> Yeah, those steps are a lot, though keep in mind that effectively it's
> only 2 steps more than before if you use the -p flag to rbt post and
> were already keeping your local master up to date.
Just to be clear, here are the steps again, slight
tl;dr: rsyslog sees 512,000,000 bytes and tells logrotate "time to
rotate!" and logrotate sees less than 512MB and say "nah, not big enough"
and rsyslog never writes the logs anymore because the file is too big.
On Mon, Sep 15, 2014 at 10:07 AM, Wayne Witzel
wrote:
> When this was being imple
On Sun, Sep 14, 2014 at 10:28 PM, Menno Smits wrote:
> Eric,
>
> Thanks for setting this up.
>
> Firstly, in your email you mention "rbt pull" several times. I think you
> mean "rbt post" right? I don't see a pull command documented anywhere.
Correct. I meant "rbt post". :)
>
> I've run in to o
When this was being implemented and during the review process the actual
size of the rotated files got adjusted. I tested very thoroughly the actual
rotation script and also tested the triggering of the rotation script.
Enough that I was happy landing the changes.
When the sizes were adjusted the
So we are using rsyslog.conf to have it figure out when rotation needs to
be done with:
# Maximum size for the log on this outchannel is 512MB
# The command to execute when an outchannel as reached its size limit
cannot accept any arguments
# that is why we have created the helper script for execut
On 15 September 2014 12:38, John Meinel wrote:
> 7) "copytruncate" seems the wrong setting for interactive with rsyslog. I
> believe rsyslog is already aware that the file needs to be rotated, and thus
It is only aware if you sent it a HUP signal.
> it shouldn't be trying to write to the same f
I did try running "logrotate.run" directly, and seeing it do nothing, and
then doing "s/512/488/" and seeing that it did, indeed, create a .1.gz. So
my thought that the bug being the "rotate 1" may actually be wrong, and the
bug is just how "size 512M" interacts with the rsyslog confuguration.
Joh
Looking again, I wonder if this is a 1024 vs 1000 bug. Specifically
rsyslog's configurations says:
$outchannel
logRotation,{{logDir}}/all-machines.log,51200,{{logrotateHelperPath}}
and the logrotate configuration says:
/var/log/juju/all-machines.log {
size 512M
...
}
I'm wondering if logr
24 matches
Mail list logo
