[pkg-go] Minutes for the DebConf17 BoF

[Michael Stapelberg]

I filed a wishlist bug for the remote configuration:
https://bugs.debian.org/888313

My tooling is now able to work with almost all repositories — there are
about 20 which still require some fixes, I’ll send out emails where I can’t
do the fix myself.

I have a beginner question regarding the git upstream workflow we’re
targeting:
How exactly would I import a new upstream version?

I looked at the golang-text repository (gbp clone vcsgit:golang-text),
removed the existing upstream branch, configured the correct remote and
tracked its master branch:
% git remote add upstream https://github.com/kr/text
% git fetch upstream
% git branch -D upstream
% git branch --track upstream upstream/master

The upstream branch indeed contains one commit which is not yet reflected
in the debian branch (“master”).

To import it, AIUI, I should tag the latest upstream branch commit
(7cafcd837844e784b526369c9bce262804aebc60) with tag
upstream/0.0_git20160503.7cafcd8, then merge the upstream branch into the
master branch with the merge strategy “theirs”.

However, I can’t find a git-buildpackage command to take care of this. How
do you do it? Manually?

On Tue, Jan 23, 2018 at 10:48 PM, Michael Stapelberg <stapelberg at debian.org>
wrote:

> 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.
>
> The VCS composition is:
> 889 git
> 3 hg
> 2 bzr
>
> I’ll need to look into how to use git-remote-{hg,bzr}.
>
> 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?
>
> On Thu, Nov 9, 2017 at 10:06 PM, Michael Stapelberg <stapelberg at debian.org
> > wrote:
>
>> Status update: I discovered (and documented) gbp’s postclone=origtargz
>> option. Also, I prepared (and documented/referenced) two git hooks.
>>
>> I’m still not entirely certain about how to approach the “upstream
>> branch contains upstream git history” change in the best way.
>> Suggestions/tips welcome.
>>
>> On Thu, Nov 9, 2017 at 3:57 PM, Michael Stapelberg
>> <stapelberg at debian.org> wrote:
>> > On Thu, Nov 9, 2017 at 6:44 AM, Martín Ferrari <tincho at tincho.org>
>> wrote:
>> >> On 09/11/17 04:24, Michael Stapelberg wrote:
>> >>
>> >>> At least for our transition period, we’ll have to use origtargz.
>> >>
>> >> Yes, but only for -2 and up releases. For -1, origtargz would do the
>> >> same as gbp (AFAIK).
>> >
>> > Yes, for -1 releases, users supply the orig tarball :)
>> >
>> >>
>> >>> I’m happy to pro-actively add compression algorithm/level options and
>> >>> evaluate at a later time whether that worked. I think just testing
>> >>> across different machines is a good start, but we should also pass the
>> >>> test of time — perhaps we can easily simulate that by testing on
>> >>> stable/oldstable.
>> >> Not sure if we need to devote a lot of time to this, after all, the
>> >> worst that can happen is a rejected upload because of checksum
>> mismatches.
>> >
>> > Personally, I find rejected uploads super frustrating, especially
>> > because of the large delay in between the action and the result (up to
>> > half an hour).
>> >
>> > I’d really like to define a workflow which makes them a thing of the
>> > past. For the time being, this is using origtargz.
>> >
>> > --
>> > Best regards,
>> > Michael
>>
>>
>>
>> --
>> Best regards,
>> Michael
>>
>
>
>
> --
> Best regards,
> Michael
>



-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20180124/fc1e5329/attachment.html>