The kernel changelog gets long fairly quickly. We have almost daily updates to rawhide. Historically we have trimmed it every so often back to a year of history. I was looking for a better way. I propose that we trim the kernel changelog to the branch date for each release in rawhide, and put everything we cut into a "changelog.history" file. This would make the spec contain a changelog for an entire release cycle and nothing more, while the history is still there for anyone who needs it. We also have the git commit logs, but they are not always as detailed as the changelog.
Thoughts?
Thanks, Justin
On Thu, Jul 28, 2016 at 4:00 PM, Justin Forbes jforbes@redhat.com wrote:
The kernel changelog gets long fairly quickly. We have almost daily updates to rawhide. Historically we have trimmed it every so often back to a year of history. I was looking for a better way. I propose that we trim the kernel changelog to the branch date for each release in rawhide, and put everything we cut into a "changelog.history" file. This would make the spec contain a changelog for an entire release cycle and nothing more, while the history is still there for anyone who needs it. We also have the git commit logs, but they are not always as detailed as the changelog.
Thoughts?
Makes sense, I think it's a useful cut off point and for those that want ancient history there's always git logs.
Peter
On 07/28/2016 08:00 AM, Justin Forbes wrote:
The kernel changelog gets long fairly quickly. We have almost daily updates to rawhide. Historically we have trimmed it every so often back to a year of history. I was looking for a better way. I propose that we trim the kernel changelog to the branch date for each release in rawhide, and put everything we cut into a "changelog.history" file. This would make the spec contain a changelog for an entire release cycle and nothing more, while the history is still there for anyone who needs it. We also have the git commit logs, but they are not always as detailed as the changelog.
However, git will have the patch history of removing all those lines. If you mark these trimming commits in a consistent way, folks can even do something like: git log -p --grep=log-trim
On Thu, Jul 28, 2016 at 12:06 PM, Josh Stone jistone@redhat.com wrote:
On 07/28/2016 08:00 AM, Justin Forbes wrote:
The kernel changelog gets long fairly quickly. We have almost daily
updates
to rawhide. Historically we have trimmed it every so often back to a year of history. I was looking for a better way. I propose that we trim the kernel changelog to the branch date for each release in rawhide, and put everything we cut into a "changelog.history" file. This would make the
spec
contain a changelog for an entire release cycle and nothing more, while
the
history is still there for anyone who needs it. We also have the git commit logs, but they are not always as detailed as the changelog.
However, git will have the patch history of removing all those lines. If you mark these trimming commits in a consistent way, folks can even do something like: git log -p --grep=log-trim
We can certainly do that, though the "changelog.history" file sitting in the kernel would also hold all relevant information.
Justin
On 07/28/2016 11:54 AM, Justin Forbes wrote:
On Thu, Jul 28, 2016 at 12:06 PM, Josh Stone <jistone@redhat.com mailto:jistone@redhat.com> wrote:
On 07/28/2016 08:00 AM, Justin Forbes wrote: > The kernel changelog gets long fairly quickly. We have almost daily updates > to rawhide. Historically we have trimmed it every so often back to a year > of history. I was looking for a better way. I propose that we trim the > kernel changelog to the branch date for each release in rawhide, and put > everything we cut into a "changelog.history" file. This would make the spec > contain a changelog for an entire release cycle and nothing more, while the > history is still there for anyone who needs it. We also have the git > commit logs, but they are not always as detailed as the changelog. However, git will have the patch history of removing all those lines. If you mark these trimming commits in a consistent way, folks can even do something like: git log -p --grep=log-trim
We can certainly do that, though the "changelog.history" file sitting in the kernel would also hold all relevant information.
Sure, I meant it as an alternative plan. If you want to keep a file like that, then it's certainly a more direct source.
kernel@lists.fedoraproject.org