charmhelpers migration to github

Alex Kavanagh alex.kavanagh at canonical.com
Wed Sep 20 20:10:11 UTC 2017 

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
cleaner git history, which is nice; as you say, it's a bit like gerrit.
Unfortunately, it's not gerrit, so it's difficult (as the bugs indicate) to
get it to work like gerrit, if you want to preserve the PR history, yet
keep clean commits.  Once it gets to a PR I think you're pretty much stuck
with the "GitHub way".

Cheers
Alex.

On Wed, Sep 20, 2017 at 8:33 PM, Dmitrii Shcherbakov <
dmitrii.shcherbakov at canonical.com> wrote:

> > 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 guess that the contributing guide will need updating (it talks
> about bzr).
>
> I would also suggest PR workflow-related updates to that doc given that
> one cannot
>
> git rebase -i HEAD~<n> # amend, squash, add new commits etc.
> and
> git push # to a forked repo
>
> without doing a force push to update a pull request. In my view, it's good
> to keep the commit history clean instead of adding several commits on top
> without squashing them. Otherwise it quickly turns into:
>
> "an original commit message to make charm-helpers great
> fixup commit to avoid a typo
> hotfix to the fixup
> final fix - will not happen again"
> * closed a PR as a huge rebase is needed
>
> I would propose the following:
>
>
>    - using "push -f" only for private branches used for pull requests
>    https://help.github.com/articles/using-git-rebase-on-
>    the-command-line/#pushing-rebased-code-to-github
>    <https://help.github.com/articles/using-git-rebase-on-the-command-line/#pushing-rebased-code-to-github>
>    - using git-pull-request: https://github.com/jd/git-pull-request which
>    updates PRs with push -f.
>    - following this workflow advice about branches: https://github.com/
>    jd/git-pull-request#workflow-advice
>    <https://github.com/jd/git-pull-request#workflow-advice>
>
> Rationale:
>
>    - https://blog.adamspiers.org/2015/03/24/why-and-how-to-
>    correctly-amend-github-pull-requests/
>    <https://blog.adamspiers.org/2015/03/24/why-and-how-to-correctly-amend-github-pull-requests/>
>    - https://softwareengineering.stackexchange.com/a/263172
>    - https://blog.adamspiers.org/2017/08/16/squash-merging-and-
>    other-problems-with-github/
>    - https://www.mail-archive.com/dri-devel@lists.sourceforge.
>    net/msg39091.html
>
>
> More info in a gist.
> https://gist.github.com/dshcherb/2c827ae945dc551da3681313294d6783
>
>
> Coming from the kernel-type patch-sending process (
> https://lwn.net/Articles/702177/, https://www.mail-archive.com/
> dri-devel at lists.sourceforge.net/msg39091.html) and gerrit (
> https://www.mediawiki.org/wiki/Gerrit/Tutorial#Comparing_patch_sets) I
> find github's approach with fixup commits a little strange but
> force-pushing with precautions even to a PR branch is not a silver bullet
> of course.
>
> https://github.com/isaacs/github/issues/997
> https://github.com/isaacs/github/issues/999
>
> It would be great to hear some feedback on this topic so that we are not
> doing anything random and have a common workflow.
>
> Thanks in advance!
>
> Best Regards,
> Dmitrii Shcherbakov
>
> Field Software Engineer
> IRC (freenode): Dmitrii-Sh
>
> On Wed, Sep 20, 2017 at 4:14 PM, Alex Kavanagh <
> alex.kavanagh at canonical.com> wrote:
>
>> 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
>> :)
>>
>> Cheers
>> Alex.
>>
>>
>> On Wed, Sep 20, 2017 at 12:59 PM, James Page <james.page at ubuntu.com>
>> wrote:
>>
>>> 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 <james.page at ubuntu.com> wrote:
>>>
>>>> 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
>>>> charmhelpers team - that should be completed today
>>>> Fixup charmhelpers sync tooling to work from github - this week (mainly
>>>> used by OpenStack Charms team)
>>>> Redirect lp:charm-helpers landings to github.com/juju/charm-helpers
>>>>
>>>> and the prize goes to Merlin for raising the first non-migration
>>>> related pull request :-)
>>>>
>>>>
>>>> On Tue, 19 Sep 2017 at 14:57 Bryan Quigley <bryan.quigley at canonical.com>
>>>> wrote:
>>>>
>>>>> From other projects I've seen moved, I'd much prefer if the Code
>>>>> section (and any other sections not planned on being using anymore) were
>>>>> cleared out on LP and then disabled.
>>>>>
>>>>> Thanks!
>>>>> Bryan
>>>>>
>>>>> On Tue, Sep 19, 2017 at 9:42 AM, Marco Ceppi <
>>>>> marco.ceppi at canonical.com> wrote:
>>>>>
>>>>>> I've updated the launchpad description to highlight the change. Since
>>>>>> there's bound to be processes still pointing at the lp branch, should we
>>>>>> set it up as a mirror from git?
>>>>>>
>>>>>> On Tue, Sep 19, 2017 at 9:37 AM James Page <james.page at ubuntu.com>
>>>>>> wrote:
>>>>>>
>>>>>>> OK - step 1 completed; I've pushed fresh bzr->git migrated code to
>>>>>>>
>>>>>>>    https://github.com/juju/charm-helpers
>>>>>>>
>>>>>>> Please don't land any further changes into the bzr branch as we'll
>>>>>>> need to diverge from this point forwards.
>>>>>>>
>>>>>>> I will land a commit in lp:charm-helpers to point lost souls to the
>>>>>>> new github.com location as part of the migration.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 18 Sep 2017 at 14:15 Alex Kavanagh <
>>>>>>> alex.kavanagh at canonical.com> wrote:
>>>>>>>
>>>>>>>> I'm a +1 on this too.  Let the good times roll.
>>>>>>>>
>>>>>>>> On Mon, Sep 18, 2017 at 11:22 AM, James Page <james.page at ubuntu.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Resurrecting this thread; I think its a good time to push on with
>>>>>>>>> this work - anyone have any objections to targeting this week to complete
>>>>>>>>> the migration?
>>>>>>>>>
>>>>>>>>> On Fri, 21 Jul 2017 at 19:55 David Ames <david.ames at canonical.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Fri, Jul 21, 2017 at 5:46 AM, James Page <
>>>>>>>>>> james.page at ubuntu.com> wrote:
>>>>>>>>>> > Hi All
>>>>>>>>>> >
>>>>>>>>>> > Managed to find some time to test the bzr->git migration more,
>>>>>>>>>> including
>>>>>>>>>> > some tidy of committers and other general hygiene.
>>>>>>>>>> >
>>>>>>>>>> >    https://github.com/juju/charm-helpers
>>>>>>>>>> >
>>>>>>>>>> > I think we're in a good position to plan for a switch - I
>>>>>>>>>> appreciate there
>>>>>>>>>> > are a number of open reviews against the bzr branch for
>>>>>>>>>> charmhelpers so it
>>>>>>>>>> > would be nice to get those landed where possible first.
>>>>>>>>>> >
>>>>>>>>>> > I can re-run the process at any time so we can pick when we
>>>>>>>>>> want to actually
>>>>>>>>>> > switch over.
>>>>>>>>>> >
>>>>>>>>>> > Once we have migrated, we can push forward on travis setup
>>>>>>>>>> etc... so that we
>>>>>>>>>> > can automatically test pull requests.
>>>>>>>>>> >
>>>>>>>>>> > Cheers
>>>>>>>>>> >
>>>>>>>>>> > James
>>>>>>>>>>
>>>>>>>>>> I landed two of Alex's MPs today which fix unit test failures that
>>>>>>>>>> would need to get pulled in. Other than that, the road is clear
>>>>>>>>>> from
>>>>>>>>>> the OpenStack Charm team.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> David Ames
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Juju mailing list
>>>>>>>>> Juju at lists.ubuntu.com
>>>>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>>>>>> an/listinfo/juju
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Alex Kavanagh - Software Engineer
>>>>>>>> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>>>>>>>>
>>>>>>> --
>>>>>>> Juju mailing list
>>>>>>> Juju at lists.ubuntu.com
>>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>>>> an/listinfo/juju
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Juju mailing list
>>>>>> Juju at lists.ubuntu.com
>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>>> an/listinfo/juju
>>>>>>
>>>>>>
>>>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>>
>> --
>> Alex Kavanagh - Software Engineer
>> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170920/ee0c7f85/attachment.html>

More information about the Juju mailing list