gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-dev] Planning a 3.11 snap release


From: Eric S. Raymond
Subject: [gpsd-dev] Planning a 3.11 snap release
Date: Sun, 24 Nov 2013 06:19:00 -0500 (EST)

For several reasons, I think I want to ship a snap 3.11 before Christmas.

The main reason is that the 3.10 build recipe got stepped on in a
subtle way by a bad commit back in April. Most users won't be 
affected; I never was, and it took six months and a release to
flush the bug out into the light of day. But I'm not happy with the
thought of leaving that breakage out there for several months.

So I'm declaring a partial refreeze.  This is easier because we've
had little enough activity since release - only two commits to C code,
both low-impact bug fixes - that I'm confident the code is still in
a good state.

There are two more patches to core code pending resubmission from
Pavel Kirilenko and Michael Tatarinov.  I've already reviewed those
and will take them (that is provided Pavel fixes his static-variable
mistake and Michael's applies cleanly and tests well).  I also have a
pending to-do about enabling the TIMING report object to include PPS
time if it's available.  Otherwise, core code should be considered
frozen - bug fixes only.

There's some work to be done on gpsctl and gpsmon; I'm willing to
leave commits on those relatively open to new features, as they're not
core-critical.

I'd like us to focus mainly on the build recipe and test stuff,
though.  Here are the things I'm concerned about and would like
help with:

* I'm worried by one of Miroslav Lichvar's post-3.10 commits -
  "Allow multiple options in LINKFLAGS'. While I believe it works in
  his environment, a nagging little voice warns me that this change
  may have been made before and required to be reverted.  Would
  people in unusual environments please beat on this?

* Bernd Zeimetz has an FR in for a way to run regression tests from outside
  the build directory.  He says this would speed up getting new
  releases through the Debian packaging workflow.  I'll do this of
  nobody else does, but it would be better for the project if someone
  else got to know SConstruct well enough to take it on.

* The set of issues around chrpath, final linkage, and installation is
  still a bit messy.  A late pre-3.10 commit by Mike Frysinger
  apparently fixed one big one (DESTDIR pollution) but I'll be happier
  when I know that's had more testing. There's been discussion going
  on about getting rid of the need for chrpath; it would be nice if
  someone got creative here.

* We need to make a final design-level decision about the leapfetch code.
  Presently it's enabled by default, but it has a clash with 
  parallel builds. Keep it this way?  Default to leapfetch=no?
  Remove it entirely?  

* We haven't tested on the weird-architecture Debian porterboxes in a
  while - not since 3.7, actually.  devtools/flocktest needs dusting
  off and adapting for the chrooted environments on those things. It
  would be altogether wonderful if someone stepped up to this.

* The present release machinery is ad-hoc; it should be replaced with
  a shipper (http://www.catb.org/esr/shipper/) invocation so we get
  automated notifications to freecode.com, #gpsd, and the
  gpsd-announce list.  (This one is mine, if only because I wrote 
  shipper and it's still in alpha; I'm just being informative). 
  
Let's shoot for release on Monday, December 2, eight days from
now.  Schedule your hacking accordingly.
--
                                                        >>esr>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]