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

Re: changelog format



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



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



Reply to: