Hi All
Heres a bit of a status update on migration activity:
Code history migration completed
Travis CI enabled for unit testing and linting with Py 2.7 and 3.4
Repo configured to not allow merges until Travis +1's
TODO
Make sure all members of the current team on launchpad are part of the
char
Thanks a lot for that, James!
Best Regards,
Dmitrii Shcherbakov
Field Software Engineer
IRC (freenode): Dmitrii-Sh
On Wed, Sep 20, 2017 at 1:57 PM, James Page wrote:
> Hi All
>
> Heres a bit of a status update on migration activity:
>
> Code history migration completed
> Travis CI enabled for
If you're a part of the charmers team on Launchpad you should now either
have access to approve pull requests + merge or you should have an invite
to join the team that can do this :-)
If you don't have one PM me on freenode IRC with your github username.
On Wed, 20 Sep 2017 at 11:57 James Page
Great stuff; I can confirm that I'm in. I'm guessing that the development
workflow will be to fork the repo, and do PRs from your own github version?
I also guess that the contributing guide will need updating (it talks about
bzr). I'm happy to do a PR for that if the workflow can be confirmed :
> I'm guessing that the development workflow will be to fork the repo, and
do PRs from your own github version?
In short, yes.
1. fork;
2. clone locally;
3. set up 2 remotes (1 for rebasing to upstream, 1 for pushing);
4. create a branch, commit and push to your fork;
5. create a PR.
> I also gu
There's some interesting ideas in there, Dmitrii. Whatever workflow we end
up with needs to be consistent with the other workflow on the juju
namespace on github.com, which I'm guessing is a simple fork to private +
PR.
I've used squashed commits on projects in the past, and they do lead to a
clea
