Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Fri, 29 Feb 2008, Mike Bird wrote:
> On Fri February 29 2008 09:26:32 Henrique de Moraes Holschuh wrote:
> > On Fri, 29 Feb 2008, Mike Bird wrote:
> > > I'm not a DD but I've been programming since 1963 when I was 7.
> > > Based on decades of software engineering experience, I would
> > > just like to remind you to USE THE FSCKING SOURCE!!!
> >
> > I am not sure this applies to dpkg, but in kernel land, the full reasoning
> > behind even one-line trivial patches to some deep-magic areas are just
> > plain impossible to understand without a ton of explanations in the log.
>
> Irrelevant. The size and complexity of dpkg are not in the same ballpark,
> county, state, country, or hemisphere as the kernel.
So, every change in dpkg code is *always* completely obvious, and you never
need any extra information that is not in a comment?
Really?
I am prepared to accept that as truth for a seasoned dpkg developer, but
only if I hear it from all current active dpkg developers. Because even if
a single one of them has found a (good) commit log to be valuable to
understand something, that means you are wrong.
And I am completely *sure* it would not be irrelevant for me were I
debugging dpkg without a full, complete, dpkg-regular-developer level of
understanding of the code. Or if I were trying to understand how dpkg
works, so as to start working on dpkg, for that matter.
> > > Logs are not the source. No matter how much time you waste
> > > fiddling with them, they are really unimportant. Programmers
> >
> > Sorry, I don't agree with you. Logs are important. Especially if one
> > member of the team quits, and another has to join in and find out exactly
> > what was happening to the code at that point in time (as opposed to reading
> > the code at that point in time, to know how it looked like).
>
> A log by this measure has temporary value during development of a new
> feature. Thereafter the value is negligable. Therefore by this measure
Oh, not at all. Don't you at least look at the commit log comments for any
line of code that just plain doesn't make sense to you should you find
yourself in need to change that line of code or the code surrounding it?
Properly written commit logs tell you what the programmer INTENDED TO DO
when he commited a set of changes, and often also WHY he wanted to do it in
a specific way. That in itself can be very valuable information if either
some of it is not obvious, or if (surprise!) the programmer made a mistake
in the code he commited, and it doesn't actually do what he intended it to!
Of course, the commit log might be erroneous. In which case someone will
end up wasting time making sure the code is correct even if it doesn't do
what the commit logs says it should. That happens, too. And if it happens
too often on your team, then yes, you would be better of without any commit
logs at all.
In other words, good commit logs aid debugging and maintainance when it is
not being done by the one who wrote the code in the first place (and
depending on how good his memory is, even for the one who wrote the code).
> it is not worth spending time prettifying logs for git merges of completed
> features.
That is not for you to decide, that's for whomever will do the merge to
decide.
You can refuse to do any such prettifying (if anyone asks you to in the
first place), but upstream is also in its right to do the prettifying
themselves (since they clearly think it is that important!) or to just
ignore your contributions, then.
> > > should be documented in a design document or noted in a comment.
> >
> > Comments have this very bad property of getting stale, which really is a
> > damn pity, as comments are in the code and therefore extremely more likely
> > to be read by someone trying to modify that area of the code.
> >
> > Logs are never stale, as they are only valid at one exact point in time and
> > they are tied to a specific set of changes anyway. But they don't have the
> > extreme advantage of locality that comments do. You need *both*, and you
> > need to take good care of *both*.
>
> You may wish to have both logs and comments but you have not demonstrated
> any value to logs other than for WIP, nor any return on the investment of
> Ian's time to prettify logs for you.
There is more than writing code, there is *maintaining* it. Which is far
more important than writing code in the first place for every long-lived and
important piece of infrastructure (like dpkg, like the kernel). If good
commit logs and history are usefull for debugging and maintaining the code
down the road, then they ARE important.
And that has nothing to do with work-in-progress.
Now, I am currently not going to bother to explain right now why commit logs
are important when debugging code one is not intimately familiar with.
Maybe later, if I have nothing better to do. But it has to do with it
speeding up the debugging a great deal if you know what the code author
wanted to do in the first place, and also helping you locate where the bug
might be faster (such as finding good bissect test points, if you are into
bissecting).
> > > Time spent prettifying logs is time that could be better spent
> > > programming or packaging or playing with the grandkids.
> >
> > That does not work well in large development teams.
>
> I confess I've only worked on development teams ranging from one to a
> few hundred developers. dpkg has how many thousand developers?
You worked in a complex project with a non-trivial ammount of developers in
a team, where the VCS commit logs were regarded as useless? I am quite
surprised (unless it was based on CVS or something else that tosses away
commit logs and history at merges). Which project?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: