Re: [gpsd-dev] Repo and web pages have been re-homed

[Fred Wright]

On Tue, 11 Jun 2019, Gary E. Miller wrote:
> On Mon, 10 Jun 2019 21:27:35 -0700 (PDT)
> Fred Wright <address@hidden> wrote:
>
> > On Mon, 10 Jun 2019, Gary E. Miller wrote:
> >
> > > Probably about time to do a new release to go with the new
> > > repository address and web page address.  Also the new NMEA 4.10,
> > > ZED, SiRFStar V, multi signal (L1/L2/L5), and Android support are
> > > cool new features.
> >
> > Also, if it hasn't already been done, it would be good to migrate all
> > the existing releases to wherever the new releases will be on GitLab,
> > so that one doesn't need "split horizon" release fetches.
>
> Good point.  Does GitLab have an noptions for arbitrary file hosting?
> Or should be consider some other file hosting?

I don't know how the GitLab release mechanism works, but I presume there's 
some sort of "make a release" feature that captures a release tarball. 
The question is whether it's possible to load preexisting release tarballs 
into that same area.  It *might* be possible to populate it by creating 
GitLab releases from all the release tags, but that would be rather 
tedious and almost certainly wouldn't result in bitwise identical 
tarballs.

> > > Ideas?
> >
> > There are a bunch of suspicious warnings in *BSD builds.  They're
> > probably not really release blockers, since 3.18.1 didn't build at
> > all on *BSD, but I'll see if I can fix them.  It may not be trivial,
> > though, since they may involve the ever-troublesome config flags.
>
> I don't run any BSD.  Can someone run point on that?

I have VMs for FreeBSD 10.3, OpenBSD 5.6, and NetBSD 6.1.5, which is how I 
know about the issue. :-)

> > Meanwhile, it would be good to hold off on any changes with a
> > significant risk of breakage until after the release.  Each of the
> > last three releases introduced at least one new bug; it would be nice
> > to break that habit. :-)
>
> Yeah, from here forward I'd prefer on doc changes and rifle shot
> bug fixes.

It occurred to me that, given the timing, it might make sense to wait for 
the July Bulletin C (probably out in the first week of July), in order to 
incorporate a December leap second, if applicable.  But then again, a 
December leap second looks pretty unlikely, given the current DUT1 
forecast.

Fred Wright