[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] Thrashing on master
From: |
Eric S. Raymond |
Subject: |
Re: [gpsd-dev] Thrashing on master |
Date: |
Fri, 13 Feb 2015 16:51:49 -0500 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Bernd Zeimetz <address@hidden>:
> >> In the current way it is just not possible to provide useful bug fixing
> >> support, not even for the last release, and that is a shame.
> >
> > Why do you believe that is so?
>
> Because it is - in most cases - impossible to figure out which commits were
> part of a fix for a bug (assuming its not one to be fixed with one commit) and
> which change other parts. Series of commits target various features and bugs
> at the same time. Some commits mix up different topics and not related
> changes.
> It might work if there would be stable branches maintained by somebody who
> actually knows the code base and works it it every day. But for people like me
> who would just like to figure out what the fix for a bug is and why, it is
> impossible to figure it out by looking at the list of commits, I have to dig
> into the code which is a waste of time.
>
> You should realize that it actually IS possible to fix bugs in Debian
> releases, and I guess in other distributions, too. So far I usually just
> ignore them and see that all bugs are fixed for the next release. Which
> doesn't make users really happy...
Thank you, that was a useful explanation. I think we can maybe do some things
to help you.
Would it be helpful if pure bug fix commits were textually marked in
some obvious way? I can try doing that, and noting when I think they
have no prerequisites back to the last stable release.
A recent example of such a commit would be 'Fix some untested cases in JSON AIS
dumping.'
That is one thing I can do. Another would be to release more frequently;
paradoxically, the reason I don't is that the defect frequency is so low
that I feel little pressure to do so. What I hear you telling me is that
I may not be weighting other peoples' reasons for wanting releases enough.
I will go review the Debian bugs database for GPSD bugs now.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
signature.asc
Description: Digital signature
- [gpsd-dev] Status driver_nmea2000.c, address@hidden, 2015/02/07
- Re: [gpsd-dev] Status driver_nmea2000.c, Eric S. Raymond, 2015/02/07
- Re: [gpsd-dev] Status driver_nmea2000.c, Greg Troxel, 2015/02/07
- [gpsd-dev] Thrashing on master, Eric S. Raymond, 2015/02/07
- Re: [gpsd-dev] Thrashing on master, Greg Troxel, 2015/02/07
- Re: [gpsd-dev] Thrashing on master, Bernd Zeimetz, 2015/02/13
- Re: [gpsd-dev] Thrashing on master, Eric S. Raymond, 2015/02/13
- Re: [gpsd-dev] Thrashing on master, Bernd Zeimetz, 2015/02/13
- Re: [gpsd-dev] Thrashing on master, Eric S. Raymond, 2015/02/13
- Re: [gpsd-dev] Thrashing on master, Bernd Zeimetz, 2015/02/13
- Re: [gpsd-dev] Thrashing on master,
Eric S. Raymond <=
- Re: [gpsd-dev] Thrashing on master, Greg Troxel, 2015/02/13
- Re: [gpsd-dev] Thrashing on master, Eric S. Raymond, 2015/02/13
- Re: [gpsd-dev] Thrashing on master, Bernd Zeimetz, 2015/02/22
- Re: [gpsd-dev] Thrashing on master, Gary E. Miller, 2015/02/22
- Re: [gpsd-dev] Thrashing on master, Bernd Zeimetz, 2015/02/22
- Re: [gpsd-dev] Thrashing on master, Eric S. Raymond, 2015/02/22
- Re: [gpsd-dev] Thrashing on master, Bernd Zeimetz, 2015/02/23
Re: [gpsd-dev] Status driver_nmea2000.c, Gary E. Miller, 2015/02/08