<div dir="ltr"><div>I think that following the clean history approach is generally good as it makes your life easier during debugging and commit message grepping.</div><div><br></div><div>Linus' point about</div><div><br></div><div><a href="https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html">https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html</a> "I want clean history, but that really means (a) clean and (b) history."</div><div><br></div><div>having both history and keeping it clean is something that we should consider but not enforce too much (subjectively) to avoid making it too hard to commit changes. In the end, this transition to github is about making it easier to contribute, not requiring a person to read a 100-page manual on how to annotate and prepare a commit to push a one-liner.</div><div><br></div><div>Given that charm-helpers changes are generally small, I think squashing is OK even using github's mechanism.</div><div><br></div><div>For large commits, on the other hand, it makes sense to recreate a pull request (close a PR, update and push to a fork, create a new PR) or update an existing PR by doing a complex rebase + force push. When there are several logical changes per commit it is quite important to keep them separate and squashing everything into a single change is essentially hiding history.</div><div><br></div><div>An analogy would be file compression: yes, you can squeeze files to a single compressed blob and make it a bit smaller but then you have to waste CPU cycles to decode it. In the same way, when you are trying to quickly grep through a git log you don't want to waste brain cycles on decoding unstructured information.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Best Regards,<div>Dmitrii Shcherbakov</div><div><br></div><div><div style="color:rgb(136,136,136);font-size:12.8px"><span style="color:rgb(68,68,68);font-size:12.8px">Field Software Engineer</span><br style="color:rgb(68,68,68);font-size:12.8px"><span style="font-size:12.8px">IRC (freenode): Dmitrii-Sh</span><br></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Sep 21, 2017 at 12:02 PM, Merlijn Sebrechts <span dir="ltr"><<a href="mailto:merlijn.sebrechts@gmail.com" target="_blank">merlijn.sebrechts@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It depends on what you want to optimize the development workflow for. I think we need to optimize for easiness because a lot of contributors will be ops people who generally have a lot less experience with git and github. I for example have rebased once in my life, and this was only possible with Alex walking me through the process.<div><div><br></div><div><i>"Fork to private + PR + dirty fix commits" </i>is an easy workflow that a lot of people are familiar with and that works well with Github. If you want a cleaner commit history, you can always rebase or squash the PR during merge using the Github UI: <a href="https://pasteboard.co/GLmTHnf.png" target="_blank">https://pasteboard.co/<wbr>GLmTHnf.png</a>.</div><div><br></div><div>It's not ideal but it's a small price to pay for more contributors..</div><div><br></div><div><br></div><div><br></div><div><div><br><br></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-09-20 22:10 GMT+02:00 Alex Kavanagh <span dir="ltr"><<a href="mailto:alex.kavanagh@canonical.com" target="_blank">alex.kavanagh@canonical.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 <a href="http://github.com" target="_blank">github.com</a>, which I'm guessing is a simple fork to private + PR.<div><br></div><div>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".</div><div><br></div><div>Cheers</div><span class="m_31264362631339555HOEnZb"><font color="#888888"><div>Alex.</div></font></span></div><div class="m_31264362631339555HOEnZb"><div class="m_31264362631339555h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 20, 2017 at 8:33 PM, Dmitrii Shcherbakov <span dir="ltr"><<a href="mailto:dmitrii.shcherbakov@canonical.com" target="_blank">dmitrii.shcherbakov@canonical<wbr>.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div>> I'm guessing that the development workflow will be to fork the repo, and do PRs from your own github version?</div><div><br></div></span><div>In short, yes.</div><div><br></div><div>1. fork;</div><div>2. clone locally;</div><div>3. set up 2 remotes (1 for rebasing to upstream, 1 for pushing);</div><div>4. create a branch, commit and push to your fork;</div><div>5. create a PR.</div><span><div><br></div><div>> I also guess that the contributing guide will need updating (it talks about bzr).</div><div><br></div></span><div>I would also suggest PR workflow-related updates to that doc given that one cannot</div><div><br></div><div>git rebase -i HEAD~<n> # amend, squash, add new commits etc.</div><div>and</div><div>git push # to a forked repo</div><div><br></div><div>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:</div><div><br></div><div>"an original commit message to make charm-helpers great</div><div>fixup commit to avoid a typo</div><div>hotfix to the fixup</div><div>final fix - will not happen again"</div><div>* closed a PR as a huge rebase is needed</div><div><br></div><div>I would propose the following:</div><div><br></div><div><ul><li>using "push -f" only for private branches used for pull requests <a href="https://help.github.com/articles/using-git-rebase-on-the-command-line/#pushing-rebased-code-to-github" target="_blank">https://help.github.com/articl<wbr>es/using-git-rebase-on-the-com<wbr>mand-line/#pushing-rebased-cod<wbr>e-to-github</a><br></li><li>using git-pull-request: <a href="https://github.com/jd/git-pull-request" target="_blank">https://github.com/jd/git-pull<wbr>-request</a> which updates PRs with push -f.<br></li><li>following this workflow advice about branches: <a href="https://github.com/jd/git-pull-request#workflow-advice" target="_blank">https://github.com/j<wbr>d/git-pull-request#workflow-ad<wbr>vice</a></li></ul><div>Rationale:</div><ul><li><a href="https://blog.adamspiers.org/2015/03/24/why-and-how-to-correctly-amend-github-pull-requests/" target="_blank">https://blog.adamspiers.org/20<wbr>15/03/24/why-and-how-to-correc<wbr>tly-amend-github-pull-requests<wbr>/</a><br></li><li><a href="https://softwareengineering.stackexchange.com/a/263172" target="_blank">https://softwareengineering.st<wbr>ackexchange.com/a/263172</a><br></li><li><a href="https://blog.adamspiers.org/2017/08/16/squash-merging-and-other-problems-with-github/" target="_blank">https://blog.adamspiers.org/20<wbr>17/08/16/squash-merging-and-ot<wbr>her-problems-with-github/</a><br></li><li><a href="https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html" target="_blank">https://www.mail-archive.com/d<wbr>ri-devel@lists.sourceforge.net<wbr>/msg39091.html</a><br></li></ul></div><div><br></div><div>More info in a gist.</div><a href="https://gist.github.com/dshcherb/2c827ae945dc551da3681313294d6783" target="_blank">https://gist.github.com/dshche<wbr>rb/2c827ae945dc551da3681313294<wbr>d6783</a><br><div><br></div><div><br></div><div>Coming from the kernel-type patch-sending process (<a href="https://lwn.net/Articles/702177/" target="_blank">https://lwn.net/Articles/7021<wbr>77/</a>, <a href="https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html" target="_blank">https://www.mail-archive.com/d<wbr>ri-devel@lists.sourceforge.net<wbr>/msg39091.html</a>) and gerrit (<a href="https://www.mediawiki.org/wiki/Gerrit/Tutorial#Comparing_patch_sets" target="_blank">https://www.mediawiki.org/wik<wbr>i/Gerrit/Tutorial#Comparing_pa<wbr>tch_sets</a>) 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.</div><div><br></div><div><a href="https://github.com/isaacs/github/issues/997" target="_blank">https://github.com/isaacs/gith<wbr>ub/issues/997</a><br></div><div><a href="https://github.com/isaacs/github/issues/999" target="_blank">https://github.com/isaacs/gith<wbr>ub/issues/999</a></div><div><br></div><div>It would be great to hear some feedback on this topic so that we are not doing anything random and have a common workflow.</div><div> </div><div>Thanks in advance!</div></div><div class="gmail_extra"><span><br clear="all"><div><div class="m_31264362631339555m_3183447747226740984m_-8449033906140139200gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Best Regards,<div>Dmitrii Shcherbakov</div><div><br></div><div><div style="color:rgb(136,136,136);font-size:12.8px"><span style="color:rgb(68,68,68);font-size:12.8px">Field Software Engineer</span><br style="color:rgb(68,68,68);font-size:12.8px"><span style="font-size:12.8px">IRC (freenode): Dmitrii-Sh</span><br></div></div></div></div></div></div></div></div></div></div>
<br></span><div><div class="m_31264362631339555m_3183447747226740984h5"><div class="gmail_quote">On Wed, Sep 20, 2017 at 4:14 PM, Alex Kavanagh <span dir="ltr"><<a href="mailto:alex.kavanagh@canonical.com" target="_blank">alex.kavanagh@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?<div><br></div><div>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 :)</div><div><br></div><div>Cheers</div><span class="m_31264362631339555m_3183447747226740984m_-8449033906140139200HOEnZb"><font color="#888888"><div>Alex.</div><div><br></div></font></span></div><div class="m_31264362631339555m_3183447747226740984m_-8449033906140139200HOEnZb"><div class="m_31264362631339555m_3183447747226740984m_-8449033906140139200h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 20, 2017 at 12:59 PM, James Page <span dir="ltr"><<a href="mailto:james.page@ubuntu.com" target="_blank">james.page@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 :-)<div><br></div><div>If you don't have one PM me on freenode IRC with your github username.</div><div><div class="m_31264362631339555m_3183447747226740984m_-8449033906140139200m_7247517429683827067h5"><div><br><div class="gmail_quote"><div dir="ltr">On Wed, 20 Sep 2017 at 11:57 James Page <<a href="mailto:james.page@ubuntu.com" target="_blank">james.page@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi All</div><div><br></div><div>Heres a bit of a status update on migration activity:</div><div><br></div><div>Code history migration completed</div><div>Travis CI enabled for unit testing and linting with Py 2.7 and 3.4</div><div>Repo configured to not allow merges until Travis +1's</div><div><br></div><div>TODO</div><div><br></div><div>Make sure all members of the current team on launchpad are part of the charmhelpers team - that should be completed today</div><div>Fixup charmhelpers sync tooling to work from github - this week (mainly used by OpenStack Charms team)</div><div>Redirect lp:charm-helpers landings to <a href="http://github.com/juju/charm-helpers" target="_blank">github.com/juju/charm-helpers</a></div><div><br></div><div>and the prize goes to Merlin for raising the first non-migration related pull request :-)</div></div><div dir="ltr"><div><br><div><br><div class="gmail_quote"><div dir="ltr">On Tue, 19 Sep 2017 at 14:57 Bryan Quigley <<a href="mailto:bryan.quigley@canonical.com" target="_blank">bryan.quigley@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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. <br></div><div><br></div><div>Thanks!</div></div><div dir="ltr"><div>Bryan<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 19, 2017 at 9:42 AM, Marco Ceppi <span dir="ltr"><<a href="mailto:marco.ceppi@canonical.com" target="_blank">marco.ceppi@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?</div><div class="m_31264362631339555m_3183447747226740984m_-8449033906140139200m_7247517429683827067m_-7367326102535224323m_-7188272370413279316m_6463882483433776663HOEnZb"><div class="m_31264362631339555m_3183447747226740984m_-8449033906140139200m_7247517429683827067m_-7367326102535224323m_-7188272370413279316m_6463882483433776663h5"><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 19, 2017 at 9:37 AM James Page <<a href="mailto:james.page@ubuntu.com" target="_blank">james.page@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">OK - step 1 completed; I've pushed fresh bzr->git migrated code to <div><br></div><div> <a href="https://github.com/juju/charm-helpers" target="_blank">https://github.com/juju/cha<wbr>rm-helpers</a></div><div><br></div><div>Please don't land any further changes into the bzr branch as we'll need to diverge from this point forwards.</div><div><br></div><div>I will land a commit in lp:charm-helpers to point lost souls to the new <a href="http://github.com" target="_blank">github.com</a> location as part of the migration.</div></div><div dir="ltr"><div><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 18 Sep 2017 at 14:15 Alex Kavanagh <<a href="mailto:alex.kavanagh@canonical.com" target="_blank">alex.kavanagh@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm a +1 on this too. Let the good times roll.</div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 18, 2017 at 11:22 AM, James Page <span dir="ltr"><<a href="mailto:james.page@ubuntu.com" target="_blank">james.page@ubuntu.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?<span><div><br><div class="gmail_quote"><div dir="ltr">On Fri, 21 Jul 2017 at 19:55 David Ames <<a href="mailto:david.ames@canonical.com" target="_blank">david.ames@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jul 21, 2017 at 5:46 AM, James Page <<a href="mailto:james.page@ubuntu.com" target="_blank">james.page@ubuntu.com</a>> wrote:<br>
> Hi All<br>
><br>
> Managed to find some time to test the bzr->git migration more, including<br>
> some tidy of committers and other general hygiene.<br>
><br>
> <a href="https://github.com/juju/charm-helpers" rel="noreferrer" target="_blank">https://github.com/juju/charm-<wbr>helpers</a><br>
><br>
> I think we're in a good position to plan for a switch - I appreciate there<br>
> are a number of open reviews against the bzr branch for charmhelpers so it<br>
> would be nice to get those landed where possible first.<br>
><br>
> I can re-run the process at any time so we can pick when we want to actually<br>
> switch over.<br>
><br>
> Once we have migrated, we can push forward on travis setup etc... so that we<br>
> can automatically test pull requests.<br>
><br>
> Cheers<br>
><br>
> James<br>
<br>
I landed two of Alex's MPs today which fix unit test failures that<br>
would need to get pulled in. Other than that, the road is clear from<br>
the OpenStack Charm team.<br>
<br>
--<br>
David Ames<br>
</blockquote></div></div></span></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/juju</a><br>
<br></blockquote></div></div><div class="gmail_extra"><br><br clear="all"><div><br></div>-- <br><div class="m_31264362631339555m_3183447747226740984m_-8449033906140139200m_7247517429683827067m_-7367326102535224323m_-7188272370413279316m_6463882483433776663m_269234600304340335m_-6257651069518732544m_-1219295509704424428gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Alex Kavanagh - Software Engineer<div>Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd</div></div></div>
</div></blockquote></div></div></div>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/juju</a><br>
</blockquote></div>
</div></div><br>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/juju</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div></div></blockquote></div></div></div></div></div>
<br>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/juju</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_31264362631339555m_3183447747226740984m_-8449033906140139200m_7247517429683827067gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Alex Kavanagh - Software Engineer<div>Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd</div></div></div>
</div>
</div></div><br>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/juju</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_31264362631339555m_3183447747226740984gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Alex Kavanagh - Software Engineer<div>Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd</div></div></div>
</div>
</div></div><br>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/juju</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>