gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Thrashing on master


From: Bernd Zeimetz
Subject: Re: [gpsd-dev] Thrashing on master
Date: Fri, 13 Feb 2015 22:29:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Icedove/34.0

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

On 02/13/2015 09:57 PM, Eric S. Raymond wrote:
> Bernd Zeimetz <address@hidden>:
>> What your engineering is targeted for has nothing to to with the way
>> branches, merges and stable releases are handled.
> 
> They have *everything* to do with each other.  I almost never branch
> because I don't want the attention either of myself or other developers to
> be divided. This policy is rough on everyone, including me, but it achieves
> the intended result, which is lots of scrutiny and a low defect rate.

If you focus on one bug and don't look on the name of the branch, your
attention is not divided. On the other hand your rough policy is forcing
everybody else to work outside of the master branch or not to push changes
early. Testing your own changes while following your commits and wondering
who-broke-what is not helpful.

This works only for a small number of developers who are able to follow the
changes of those who commit often, but for others it is really hard to figure
out whats going on. And almost impossible to review. And it works because the
codebase is (was?) small enough.


>> 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...





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

iQIcBAEBCAAGBQJU3mzBAAoJEOs2Fxpv+UNfTREP+wXGzC+nretI3PJiQ1CBrz2E
VHazEuBDWiudFgrdrrGk18XQhWYqsK2lWPUiGdNm++T1ORISv69o9S7G3tYnuEVe
qiLgSbj42LPPvHfyZoBLN2trAnSXcqk5HLRyo6Q/oW0fpX8kWw7Xt/78Ck++RmHj
lf3zu8YUu3KFskvXsl3QKfWNgvbCg3agDE/TdlkrFcoADwvwvJggwsdpXFIkaBWe
a1AgWbF/Go+8YM1BCRbxs4QQ0mZbGVix5FhcTj1Q18vRAqCRZIju8G0mZ7Y4aPc3
TXFJZrj/pyNAtfU4zyp+I/DRQbp8zhohyheBD16UJURf4Ws3qA/xQhbWVNeLc32A
CeshDTHiwcq7qJbO7ZQ84G2MS8HE/bu0J4MthxvNZZuXHTCJFRqr7SK9Nizr6MLf
bIAy0vpkZ+oiGrmqNioMwKRSnT9pztylh24tgS1l9AT6ejlap6VtAu0nisGbYaqt
NS8aeU0UlEtVLmHrf9PqCQi5f2oN+Zjm/pJJQmEoBo4NnXNBlLBXqJrHSUmPaRqs
qScdVzwmFT2qT6KpjHVBE+5u429a4zzcS3cWYZH8KlWl7OQwmKdf3x5HV2gWfbdc
xBjsZ8XOzfMbwzRg96s94x2AwNzzA7ZX2IxoINuX8lqxsctAAWFmjvuqoA5+yiNM
JQCWXHOI094/vBtJ7nLN
=jA2P
-----END PGP SIGNATURE-----



reply via email to

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