From owner-freebsd-arch@freebsd.org Fri Jun 15 18:31:48 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4353B101751C for ; Fri, 15 Jun 2018 18:31:48 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3D9C7CBA3 for ; Fri, 15 Jun 2018 18:31:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id E890D10AFAD; Fri, 15 Jun 2018 14:31:46 -0400 (EDT) Subject: Re: upstream for contrib/tzcode/stdtme? To: Eitan Adler References: Cc: "freebsd-arch@freebsd.org" From: John Baldwin Message-ID: <20a85a8f-29a7-0d8f-64d1-9ba005ffe79c@FreeBSD.org> Date: Fri, 15 Jun 2018 11:31:46 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 15 Jun 2018 14:31:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 18:31:48 -0000 On 6/15/18 10:46 AM, Eitan Adler wrote: > On 15 June 2018 at 09:03, John Baldwin wrote: >> On 6/15/18 7:28 AM, Philip Paeps wrote: >>> On 2018-06-10 21:40:21 (+0200), Eitan Adler wrote: >>>> What's the upstream for contrib/tzcode/stdtme? >>> >>> https://www.iana.org/time-zones (and https://github.com/eggert/tz). >>> >>>> There are a couple of PRs for it and I'd like to either update, fix >>>> upstream, or move to non-contrib & fix. >>> >>> I've started updating it several times but the rather awkward layout of >>> the vendor tree makes doing just about anything else more attractive. :) >>> >>> More than happy to review an update if you actually manage to complete >>> one! > > I'll attempt one this weekend. :) > >>> I wonder if we should just make the "moving around files" in the vendor >>> tree go away... > > +1 > >> I do think we should perhaps import the vendor tree to contrib/stdtime or >> some such and then apply our local patches from libc to there. > > I'd like to do the following: > > - identify what local patches we have and divide them into two parts: > (a) issues already fixed upstream (b) issues not already fixed [or > local changes] > - import the latest stdtime into vendor > - copy from vendor into our contrib/stdtime without flattening the structure > - reapply all (b) patches manually > > This will make the mergeinfo correct and also make it clear what > patches are local and what are upstream > >> Alternatively, >> we could move the the files from libc into suitable locations in contrib/stdtime >> and then do an 'svn merge --record-only' to bootstrap the vendor mergeinfo >> for the current version and use that as a basis for updating? > > Exactly. I think this second approach is actually a better plan and is not quite what you were suggesting. That is, import the vendor bits corresponding to our existing code first into the vendor area, then svn cp our existing files from libc, zic, etc. into the contrib/stdtime tree in the correct layout and do a single 'svn merge --record-only' merge to initialize the vendor mergeinfo. At that point you should be able to svn diff contrib/stdtime against the vendor/stdtime/dist to determine what local changes we have and start to think about them. It also means that svn merge will consider them during your merge to the newer vendor sources without you have to manually apply patches in (b) while also preserving the commit history of those patches. -- John Baldwin