Re: changelog format
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
Reply to: