> 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 - 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 Rationale: - 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@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.kavan...@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.p...@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.p...@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.quig...@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.ce...@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.p...@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.kavan...@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.p...@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.a...@canonical.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Fri, Jul 21, 2017 at 5:46 AM, James Page <james.p...@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@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@lists.ubuntu.com >>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>>> an/listinfo/juju >>>>>> >>>>> >>>>> -- >>>>> Juju mailing list >>>>> Juju@lists.ubuntu.com >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/juju >>>>> >>>>> >>>> >> -- >> Juju mailing list >> Juju@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@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju