Not trying to hijack this thread, but a suggestion for reviewing and CI
testing. I have a hunch you guys already have something in place, but
there is TRAVIS CI which integrates nicely with github repos through a
yaml file.
When a pull request is submitted it performs a build and then on the pull
The comment was made with the understanding that this was your original
plan, and the point is to measure engagement before closing it down, or
you'll never know whether it makes any difference for juju specifically.
Also, isn't Launchpad able to track issues originally filed on other
trackers?
Hi all
There have been a few fixes landed by different people to address various
intermittent test failures. These were present before the cut over, but seem to
show up more when the tests are run on EC2 rather than Canonistack.
After a little experimentation, plus switching the EC2 instance
We looked at Travis CI, but it has a fundamental issue that Travis people
feel they don't want to fix. Which is that by default it only tests the
branch, without concern for what is on Trunk. Which you can fix in your own
hook, by merging trunk before running the test suite. However, it also
Thats a huge win, great to hear. Would we consider doing a static instance?
We could potentially isolate it in an LXC container so that we don't get a
lot of cross pollution, and being able to cut out 5min of overhead is 30%
of the time spent.
John
=:-
On Thu, Jun 5, 2014 at 10:59 AM, Ian Booth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I spent some time yesterday researching various ways to be productive
with git and GitHub. What you're talking about reminded me of this:
https://github.com/github/hub
It's a CLI for git that allows you to create pull requests on GitHub
and lots
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Right, my bad - so it's just a diff of the branch changes, and it can
be converted to a PR using the green button at the top, so you can add
comments. I guess for such cases we can use it and tag the PR as WIP
somehow (i.e. in the title or
We discussed this topic at the team meeting and Launchpad will remain the
primary issue tracker. We'll leave Github's issue tracker enabled for a bit and
see how many bugs are raised. Any legitimate bugs will need to be copied across
to Launchpad. Launchpad can import bugs on other trackers for
In regards to this feature. Why not write a hook for github to have it
interface with LP
One of the many things I miss now that we have moved to Github/git is the
ability to put up a merge proposal with in-progress work, allowing
collaboration
on the implementation as it evolves etc.
On 5 June 2014 05:07, Menno Smits menno.sm...@canonical.com wrote:
One nice feature is that old comments are hidden
if the area of the code they reference is changed by a later diff.
I consider this a serious shortcoming. I generally want to see all the
conversation for a given code review. Is
We're making a lot of standalone repos on github so that teams external to
core can reuse core's code.
I think we need to disambiguate between repos that are generally only of
use when working with juju, and repos that are more general purpose. For
example, errgo is a general use package that
On 5 June 2014 14:22, Andrew Wilkins andrew.wilk...@canonical.com wrote:
On Thu, Jun 5, 2014 at 9:02 PM, roger peppe rogpe...@gmail.com wrote:
On 5 June 2014 05:07, Menno Smits menno.sm...@canonical.com wrote:
One nice feature is that old comments are hidden
if the area of the code they
On 5 June 2014 14:20, Nate Finch nate.fi...@canonical.com wrote:
We're making a lot of standalone repos on github so that teams external to
core can reuse core's code.
I think we need to disambiguate between repos that are generally only of use
when working with juju, and repos that are more
Unfortunately that means that the import identifier isn't intuitive,
but perhaps that's ok.
On 5 June 2014 14:27, roger peppe rogpe...@gmail.com wrote:
On 5 June 2014 14:20, Nate Finch nate.fi...@canonical.com wrote:
We're making a lot of standalone repos on github so that teams external to
On Thu, Jun 5, 2014 at 8:22 AM, Nate Finch nate.fi...@canonical.com wrote:
commit several times to your feature branch.
rebase into a single commit
I don't see any problem with rebasing commits that you've already pushed to
your github personal fork, but that *could* be considered changing
I guess what I don't understand is, why does it matter which mongo DB you
back up? They should all be identical, right?
On Thu, Jun 5, 2014 at 12:58 PM, Curtis Hovey-Canonical
cur...@canonical.com wrote:
On Wed, Jun 4, 2014 at 4:36 PM, Nate Finch nate.fi...@canonical.com
wrote:
I'm not
FWIW, I pretty much never rebase in my usual development workflow. I'm
surprised to hear it became a norm somehow.
On Thu, Jun 5, 2014 at 2:06 PM, roger peppe rogpe...@gmail.com wrote:
I'd love to ditch rebasing if it was reasonable to do so.
It just adds overhead to an already tiresome
I have a branch proposed that displays extra environment information
when the --format flag is used with switch e.g:
$ juju switch local --format yaml
environ-name: local
previous-environ-name: ec2
state-servers:
- example.com
- kremvax.ru
username: joe
There is some debate over this.
+1
On Thu, Jun 5, 2014 at 6:16 PM, Tim Penhey tim.pen...@canonical.com wrote:
On 06/06/14 09:55, Jesse Meek wrote:
I have a branch proposed that displays extra environment information
when the --format flag is used with switch e.g:
$ juju switch local --format yaml
environ-name:
On 06/06/14 01:28, roger peppe wrote:
Unfortunately that means that the import identifier isn't intuitive,
but perhaps that's ok.
On 5 June 2014 14:27, roger peppe rogpe...@gmail.com wrote:
On 5 June 2014 14:20, Nate Finch nate.fi...@canonical.com wrote:
We're making a lot of standalone
This seems to be close to what you want
http://stackoverflow.com/questions/8371173/how-to-get-notified-when-someone-pushes-into-a-github-branch
On Thu, Jun 5, 2014 at 8:43 PM, Tim Penhey tim.pen...@canonical.com wrote:
Hi All,
When Juju was on launchpad, I had subscribed to the trunk branch
On Fri, Jun 6, 2014 at 1:22 AM, Casey Marshall casey.marsh...@canonical.com
wrote:
On 06/05/2014 10:22 AM, Nate Finch wrote:
This mashes all your pre-PR commits into one, so hides some commit spam
that way, but then keeps the post-PR commits, to preserve comments. It
sounds like we can
On 06/06/14 11:52, Andrew Wilkins wrote:
On Fri, Jun 6, 2014 at 1:22 AM, Casey Marshall
casey.marsh...@canonical.com mailto:casey.marsh...@canonical.com wrote:
On 06/05/2014 10:22 AM, Nate Finch wrote:
This mashes all your pre-PR commits into one, so hides some commit
spam
On Thu, Jun 5, 2014 at 9:28 PM, roger peppe rogpe...@gmail.com wrote:
Unfortunately that means that the import identifier isn't intuitive,
but perhaps that's ok.
It's not so different from the go-thing convention a lot of people use,
where the package name is actually just thing.
If we were
On Thu, Jun 5, 2014 at 9:26 PM, roger peppe rogpe...@gmail.com wrote:
On 5 June 2014 14:22, Andrew Wilkins andrew.wilk...@canonical.com wrote:
On Thu, Jun 5, 2014 at 9:02 PM, roger peppe rogpe...@gmail.com wrote:
On 5 June 2014 05:07, Menno Smits menno.sm...@canonical.com wrote:
One
25 matches
Mail list logo
