Re: [gpsd-dev] Thrashing on master

[Bernd Zeimetz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Gary!

On 02/22/2015 10:45 PM, Gary E. Miller wrote:
> Nice info to know, but are you really going to backport some bug fixes and
> not others?  Untangling that dependency would be a PITA.

yes, indeed, if necessary.
I've done so for wheezy, for example:
http://git.recluse.de/?p=debian/pkg-gpsd.git;a=tree;f=debian/patches;h=e7c874975d5b6b1e3d4c96ef65bb1391fb915c88;hb=refs/heads/wheezy;js=1

>> Still it would be easier if it would be obvious to see how many commits
>> are part of a bug fix or to look at a merged topic branch.
> 
> Focusing on specific bugs is like studying for a test you already know the
> questions on.  In real life a bug report is just the top of the iceburg
> that tells us where a real mess is.  You can't just chop off the top of the
> iceburg, you need to destroy the hole thing.

Yeah, sometimes its the large icy thing, but for example
32c2c9caae5672c1b29d8458a74bbc7ab0e2720e was a rather easy thing to pick.


>> I think more releases are not necessary, better would be some kind of 
>> stable release with point releases like the kernel and postgresql do it.
>> For example 3.11 will be part of jessie - which means it should be bug
>> free for at least 2 years, longer would be even better. Introducing
>> completely new releases is a no-go, but fixing bugs is not a problem at
>> all.
> 
> So if we have named 3.12 to instead be 3.11.1 it would go into jessie?

no :)

> I'm all for that.

I can imagine...

> It is not like gpsd changes a lot between releases.  95% of gpsd releases
> are bug fixes, with the occasional upgrades like AIS messages. And very few
> things get removed, so 3.12 is a drop in replacement for 3.11.
> 
> Worse, when AIS gets improved it sometimes shows up bugs in the core logic.
> A commit for a new AIS feature often is also a hidden bug fix.


For Debian stable updates (and updates during the freeze of the upcoming
release) there are some strict requirements on changes, like
- - bugfixes only, not 95%, but 100%. no new features, no behavior changes...
- - no abi/api breakages (security related issues might be an exception here, if
there is no other way to fix them)
- - and for the gpsd project the biggest problem: every change must be well
documented and reviewable and understandable by somebody who knows c but not
the internal funky parts of the code. So if you do some cryptic changes, even
more documentation is necessary for review.
- - updating the regression test suite is another critical thing, if you change
the regression test output it needs to be explained that the new outputs are
correct and the old ones were wrong. For pure bugfixing, changes should be
rather minimal I'd say.


With
git diff-tree --shortstat release3.11..release-3.12
 275 files changed, 35262 insertions(+), 49610 deletions(-)

somebody would shoot my head if I'd want to upload 3.12 as a replacement for
3.11 in jessie.

What I can do is to provide backports after jessie was released. That is
rather easy, but in case of 3.11 -> 3.12 we have a new library soname, so
there will be a transition. Another thing which won't make gpsd users in a
stable release happy. Even with a backport, and if you use the new gpsd with
the old libgps, you might be rather unhappy.

So at the end this is one of the reasons why I'd like to see stable point
releases with properly backported bugfixes, at least for those bugs where
fixes are possible. And maybe symbol versioning to avoid soname bumps.


>>> I will go review the Debian bugs database for GPSD bugs now.
>> 
>> I don't think there is something interesting in there right now.
> 
> Yeah, mostly because we encourage people to ditch the pretty old 3.09 that
> wheezy ships with for a new gpsd built from source.
> 
> 3.09 on RasPi is flagrantly broken and anyone that tries it knows it. 3.11
> is a bit flakey and 3.12 works nicely.  But we will be hearing about the
> 3.11 problems for years to come because there is no way you can backport
> all the bug fixes in 3.12 to 3.11 without essentially receating a slightly
> broken 3.12.
> 
> And all that effort comes at a huge cost of maintainer time.  Much more 
> efficent to just validate that 3.12 works for jessie as a drop in 
> replacement and ship it.

That won't happen, see above. Freeze time for jessie was announce a longish
time ago and 3.11 was in time for that. Neither building gpsd nor possible
bugs in gpsd would be a the problem (aside from violating release policy), but
a libgps transition rebuilds kde-workspace and various other packages, which
need testing again after being rebuilt... Nothing you want to have a few weeks
before a release which is supposed to be stable for the next years.


- -- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJU6liNAAoJEOs2Fxpv+UNfySkP/2qqjAPPn0DoaCNxyJBSbHIW
h2Rx9612+uGrfCtQuCeJ+JM64tJKGFQzNbRfjxoJJDt1rAA6ROlvYTdrYKzqKFDj
j2D6gf5L44YqlCRyWaPI/ywd17tahgpKdDfIxjNbIrkLDl8Hc7IpbolL7Ofl7wW7
+KS64O9EJBe6/n3aDQdQmdXK7NCFiX5mvZitwqHKxB7eYMxLwkI6rk27BnHY/zVq
1agJsvXLZXW5LUvjgYFO0sTc9BLJEHZyq7RMuDzrrIncum5aBOWFOv3RcGd+jD8U
g9IOz38SaaEkMWQBOyRhi3uEDKyy0pKd9wo4daawQIl6gqm3kF5JdKzKNSvKa0+A
LR9ph3Af94GlShp6pMDjKU1opeC8vLlWFk3OXQ1t1tUn46VhrExTZZyq+JPH/sR2
hZ24tlS8RzvLOJlmgeCLhDV3ybM0PltCc3aT0s/S9Sqas+HIqhXL6GMCC/uz5rtu
zRggkcppYibW86/YB5I578iV9nUWVRv98j0X6uxu0gC9TpAYjk2JEAo7PY12hp89
SXGQTbRDNk/VrE0udnM7Ax+4rGVZ46ZJk2uC8KsBeKaS+sI8BK5/p7qnIqTHu8xs
VtKvJROyUTCyUO72I/y7EpccoJig1hv+4U2CqWHilXiVi492dRDmEb2IaR58E2hi
1lxAt8NYDNnpwzVu7rMK
=XUny
-----END PGP SIGNATURE-----