So Bogdan Teleaga was kind enough to put in the effort to move all of our
source trees to start importing from gopkg.in/check.v1 rather than
depending on labix.org/gocheck.
However, this means that if we land those changes, code that depends on the
testing infrastructure provided by those
That's an interesting observation and I think I agree.
The general rule is probably something like this:
- If a type is part of the exported API of a versioned package and the
package is changed to import that type from somewhere
else, the package's version must be incremented.
Given that
John, Roger,
This situation right here is why I am strongly opposed to the gopkg.in
versioning model. I recommend reverting to the original launchpad
location.
Dave
On Mon, Sep 22, 2014 at 9:56 PM, roger peppe roger.pe...@canonical.com wrote:
That's an interesting observation and I think I
On 22 September 2014 12:59, David Cheney david.che...@canonical.com wrote:
John, Roger,
This situation right here is why I am strongly opposed to the gopkg.in
versioning model. I recommend reverting to the original launchpad
location.
Dave
I understand your concern - having multiple
On Sat, Sep 20, 2014 at 12:01 AM, Jesse Meek jesse.m...@canonical.com wrote:
On 20/09/14 02:34, Eric Snow wrote:
I was not seriously suggesting we return to lp. Using ReviewBoard
reintroduces what we gave up with lp: both the good (tooling that addresses
pain points) and the bad (not a well
So, the automation between github and reviewboard seems necessary, so we
should do that. It shouldn't be hard at all. Then the steps for submitting
code will be:
1.) Submit a PR
2.) Get it reviewed on the automatically-created review.
3.) With a LGTM on the review, mark as $$merge$$ and the bot
Just in case we're counting, another pro:
You are able to seperate pushing branches to github and creating a new
version of code for review
Matty
On Fri, Sep 19, 2014 at 4:37 PM, Eric Snow eric.s...@canonical.com wrote:
Given that I've in some part driven the switch to ReviewBoard, I want
to
