On Thu, Sep 01, 2005 at 02:58:30PM -0400, Andres Salomon wrote: > On Thu, Sep 01, 2005 at 07:35:25AM +0200, Sven Luther wrote: > > On Thu, Sep 01, 2005 at 12:30:41AM -0400, Andres Salomon wrote: > [...] > > > > Well, we have not decided, the first [<author>] is thrown in by dch, and > > people are still using the same format as always, and maybe not always > > remove > > the [<author>] bit. > > > > Notice that the [<author>] part will probably become a standard all among > > debian as dch enforces it, so maybe it is worthwhile thinking about it. > > Yes, perhaps I should be attacking the root of the problem. See #326064. > Perhaps discussion of this is a bit premature until we hear back from the > devscripts people. Or perhaps we should avoid using dch, or provide our > own version of dch..
I think going against the dch flow would be difficult. > [...] > > > > > > Architecture-specific changes should have their description line start > > > with [<arch>]. The arch should be in all lowercase. > > > Security fixes should have their description line start > > > with [SECURITY] (reasoning: the fact that it's a security fix takes > > > precedence over what arch if affects; if it really is a fix that affects > > > only one arch, just mention that in the description somewhere). Security > > > fixes that have CVE entries/CAN numbers should have their description line > > > start with [SECURITY: <CAN>]. > > > > What about [SECURITY,<arch>] ? > > > > I wouldn't want to see that get too cluttered; and for security fixes, > I really don't think the arch is as important. Otherwise, we'll end up > w/ something like: > * [SECURITY, amd64: CAN-2005-1111,CAN-2005-1112] User could frobnicate > as another user. > > That's really not much easier to read, or pick out the important bits. > The following, on the other hand, makes the CAN and security tag much more > noticable: > * [SECURITY: CAN-2005-1111,CAN-2005-1112] User could frobnicate as > another user (amd64 only). > > IMHO, anyways. I think there's enough people scanning the kernel > changelogs for security bits and CAN numbers (the various teams, people > doing backports to older kernels, possibly other distributions, and so on) > that we want to emphasize that as much as possible. I'm all for more information than less. And I would really like to see the name of the patch or patches incoporated into the changelog entry, so there is a clear association between the description of a fix, and the code of a fix. Too many times I have hunted through packages and not had this, and been horribly frustrated. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
