Date: Fri, 15 Jun 2018 11:31:46 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Eitan Adler <lists@eitanadler.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: upstream for contrib/tzcode/stdtme? Message-ID: <20a85a8f-29a7-0d8f-64d1-9ba005ffe79c@FreeBSD.org> In-Reply-To: <CAF6rxgkOgBatF17%2Bak=8SqTVO9UrNr8qA6YSYQoZsRDnKAgUtA@mail.gmail.com> References: <CAF6rxg=rYVizBPFxxEr4M6uUymhAUq6qHgj-3N6uTubsTBO6pg@mail.gmail.com> <C8E09003-E15D-4D68-B783-B0FD435454D0@freebsd.org> <abce970e-af0b-3f7b-3fcd-a77b5e7a1b50@FreeBSD.org> <CAF6rxgkOgBatF17%2Bak=8SqTVO9UrNr8qA6YSYQoZsRDnKAgUtA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/15/18 10:46 AM, Eitan Adler wrote: > On 15 June 2018 at 09:03, John Baldwin <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20a85a8f-29a7-0d8f-64d1-9ba005ffe79c>