<div dir="ltr">Status update: I now have tooling to perform the “delete existing upstream branch, create a tracking upstream branch in correct version from Go import path” step. The tooling still fails on about 60 of 901 repositories. I’ll take a look at the failures and give another status update.<div><br></div><div>The VCS composition is:</div><div>889 git</div><div>3 hg</div><div>2 bzr</div><div><br></div><div>I’ll need to look into how to use git-remote-{hg,bzr}.</div><div><br></div><div>Also, I’m wondering how we can accomplish automated git remote configuration, i.e. how do people obtain an upstream branch which tracks the correct upstream remote branch? AFAICT, git-buildpackage has no solution for this (yet?). Does anyone know by chance?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 9, 2017 at 10:06 PM, Michael Stapelberg <span dir="ltr"><<a href="mailto:stapelberg@debian.org" target="_blank">stapelberg@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Status update: I discovered (and documented) gbp’s postclone=origtargz<br>
option. Also, I prepared (and documented/referenced) two git hooks.<br>
<br>
I’m still not entirely certain about how to approach the “upstream<br>
branch contains upstream git history” change in the best way.<br>
Suggestions/tips welcome.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Nov 9, 2017 at 3:57 PM, Michael Stapelberg<br>
<<a href="mailto:stapelberg@debian.org">stapelberg@debian.org</a>> wrote:<br>
> On Thu, Nov 9, 2017 at 6:44 AM, Martín Ferrari <<a href="mailto:tincho@tincho.org">tincho@tincho.org</a>> wrote:<br>
>> On 09/11/17 04:24, Michael Stapelberg wrote:<br>
>><br>
>>> At least for our transition period, we’ll have to use origtargz.<br>
>><br>
>> Yes, but only for -2 and up releases. For -1, origtargz would do the<br>
>> same as gbp (AFAIK).<br>
><br>
> Yes, for -1 releases, users supply the orig tarball :)<br>
><br>
>><br>
>>> I’m happy to pro-actively add compression algorithm/level options and<br>
>>> evaluate at a later time whether that worked. I think just testing<br>
>>> across different machines is a good start, but we should also pass the<br>
>>> test of time — perhaps we can easily simulate that by testing on<br>
>>> stable/oldstable.<br>
>> Not sure if we need to devote a lot of time to this, after all, the<br>
>> worst that can happen is a rejected upload because of checksum mismatches.<br>
><br>
> Personally, I find rejected uploads super frustrating, especially<br>
> because of the large delay in between the action and the result (up to<br>
> half an hour).<br>
><br>
> I’d really like to define a workflow which makes them a thing of the<br>
> past. For the time being, this is using origtargz.<br>
><br>
> --<br>
> Best regards,<br>
> Michael<br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Best regards,<br>
Michael<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
</div>