On Tue, May 27, 2003 at 12:15:37PM -0700, Brian Nelson wrote: > 1. To show others, especially NM's, what not to do. NM's mostly learn > by example, and I think it helps to ensure they don't follow bad > examples. > 2. It's something that should be obvious. Producing poor quality > changelogs shows a real neglect for the quality of Debian overall, > and they deserve to be publicly reprimanded. "Obvious" is a key word indicating that you need to check your assumptions at the door. While I will certainly concede that changelogs that spell out the nature of relevant upstream changes are more useful than those which do not, the only argument extended that persuades me it's worth extra effort on my part is that it impacts the work of our long-suffering Security Team. It disappoints me that anyone would consider this such a serious offense that it justifies prolonged flogging on a public mailing list. While using the changelog to close bugs without explaining what was done or to close bugs that were not fixed by the upload in question should not be tolerated, you're getting upset about bug closings that absolutely *do* include a description of what the maintainer changed in order to fix them: incorporating a "new upstream release". That this is too succinct for some applications does not make it "changelog abuse". Nor, BTW, is it changelog abuse to have forgotten to close a fixed bug in the changelog: your hard-line stance invites maintainers to simply close *all* bugs manually after upload, which makes the changelog a much less useful tool on many levels. > 3. It publicly shows which developers are not really involved in the > community. If they were involved, they would know how to write a > proper changelog. Developers who aren't involved in the community > don't belong in Debian, IMO. Mmm-hmm. > 4. I'd be willing to guarantee that any maintainer who can't handle > something as simple as a changelog is probably making many more > critical mistakes in their package. Therefore, I think it's > important to point out these maintainers in public so everyone is > aware of them. Some of us are a little more focused on those aspects of our packages that are actually mandated by policy. -- Steve Langasek postmodern programmer
Attachment:
pgpiCd1X2AEhv.pgp
Description: PGP signature