cvs commit: ports/graphics/netpbm Makefile

[Sahil Tandon]

On Sun, 2011-04-03 at 20:59:46 -0700, Doug Barton wrote:

> >>Meanwhile, given the way that our ports and packages work bumping
> >>PORTREVISION is a blunt tool, and has tradeoffs. IMO ports
> >>committers need to have some firm guidelines for the common cases,
> >>but also to use their discretion on the edges.
> >
> >That is all fine and well, but given the nature of these issues, threads
> >similar to this one are unavoidable.
> 
> I think you're right about that. What I'm not sure about is whether
> you think that's a problem.

It is not a problem in my opinion.

> >People will always have questions about why in case X, a bump wasn't
> >issued while it was in a strikingly similar case Y.  And unless there
> >is sufficient discussion of rationale in the commit logs, I think
> >that is OK.
> 
> I think it's Ok even if there IS adequate justification in the logs.
> :)  We have an influx of new committers, and those who wish to be, so
> periodically re-visiting these topics is useful.

I agree, but my feeling is that these threads are unlikely to be spawned
in cases where commit logs are clear.  But what is clear to one person
may be confusing to another, so I hear you 100%.

> >It is not about bright lines or other metaphors, but rather just a
> >desire to understand what motivated a bump in one circumstance but
> >not another.
> 
> So *now* it sounds like you're asking for better commit logs, which is
> something we definitely agree on. :)  What I learned was that commit
> logs should be about 1/3 "what" (since you can get the full picture
> from the diff if needed) and 2/3 "why." Keeping in mind that the logs
> need to be understood years from now when we're all long gone is
> always a good thing too.

Yes, and I myself could do a better job to that end.  Between your
comments and dinoex's reply, I am now clear on the what and why of this
commit.  Thanks.

-- 
Sahil Tandon <sahil at FreeBSD.org>