I consider this to be common sense, but it's not in the guidelines right now - that changelog entries are immutable. To that end, I have a really simple draft up here for revision of the guidelines to explicitly state that.
https://fedoraproject.org/wiki/User:Jstanley/Changelog_Draft
On Mon, Jan 25, 2010 at 01:12:28 -0500, Jon Stanley jonstanley@gmail.com wrote:
I consider this to be common sense, but it's not in the guidelines right now - that changelog entries are immutable. To that end, I have a really simple draft up here for revision of the guidelines to explicitly state that.
What happens when you make a mistake? Say you enter an incorrect date in a changelog. There should be some way to fix this.
On Mon, Jan 25, 2010 at 1:10 AM, Bruno Wolff III bruno@wolff.to wrote:
What happens when you make a mistake? Say you enter an incorrect date in a changelog. There should be some way to fix this.
Changed the draft wording to be a little less harsh, allowing for these sorts of things.
On 01/25/2010 01:12 AM, Jon Stanley wrote:
I consider this to be common sense, but it's not in the guidelines right now - that changelog entries are immutable. To that end, I have a really simple draft up here for revision of the guidelines to explicitly state that.
https://fedoraproject.org/wiki/User:Jstanley/Changelog_Draft
I am against making this a steadfast requirement. This should be stated as a strong recommendation.
I often want to make corrections to previous changelog entries. I sometimes want to remove irrelevant changelog entries, usually only cases like "Rebuild for rawhide libfoo-1.2.3" when I have that spec in sync with previous Fedora/RHEL releases and that changelog entry is irrelevant/incorrect for other distros.
Warren Togami wtogami@redhat.com
On Mon, Jan 25, 2010 at 1:17 AM, Warren Togami wtogami@redhat.com wrote:
I often want to make corrections to previous changelog entries.
This is now allowed for in the draft, with the "obvious error" exception.
I sometimes want to remove irrelevant changelog entries, usually only cases like "Rebuild for rawhide libfoo-1.2.3" when I have that spec in sync with previous Fedora/RHEL releases and that changelog entry is irrelevant/incorrect for other distros.
But those are, as you state, "other distros". Each branch of Fedora (and arguably RHEL, but I have no influence in internal RHT guidelines obviously) should have a unique spec file. To do otherwise is to rewrite history. FESCo recently dealt with exactly this issue, and took a quite dismal view on it. (though in that case it was a script that was obliterating changelog entries).
On 01/25/2010 01:33 AM, Jon Stanley wrote:
But those are, as you state, "other distros". Each branch of Fedora (and arguably RHEL, but I have no influence in internal RHT guidelines obviously) should have a unique spec file. To do otherwise is to rewrite history. FESCo recently dealt with exactly this issue, and took a quite dismal view on it. (though in that case it was a script that was obliterating changelog entries).
I dispute the assertion that all branches of Fedora must necessarily have different spec files.
Warren
On Mon, Jan 25, 2010 at 01:33:57AM -0500, Jon Stanley wrote:
On Mon, Jan 25, 2010 at 1:17 AM, Warren Togami wtogami@redhat.com wrote:
I often want to make corrections to previous changelog entries.
This is now allowed for in the draft, with the "obvious error" exception.
I sometimes want to remove irrelevant changelog entries, usually only cases like "Rebuild for rawhide libfoo-1.2.3" when I have that spec in sync with previous Fedora/RHEL releases and that changelog entry is irrelevant/incorrect for other distros.
But those are, as you state, "other distros". Each branch of Fedora (and arguably RHEL, but I have no influence in internal RHT guidelines obviously) should have a unique spec file. To do otherwise is to rewrite history. FESCo recently dealt with exactly this issue, and took a quite dismal view on it. (though in that case it was a script that was obliterating changelog entries).
Please provide a pointer to this issue. The issue that comes to my mind[0] was mainly about reverting changes that other maintainers than the owner performed on spec files.
Imho it is valid for a maintainer to mainly develop the spec file in devel and use it for the other branches as well.
Regards Till
On 01/25/2010 07:12 AM, Jon Stanley wrote:
I consider this to be common sense, but it's not in the guidelines right now - that changelog entries are immutable. To that end, I have a really simple draft up here for revision of the guidelines to explicitly state that.
https://fedoraproject.org/wiki/User:Jstanley/Changelog_Draft
Firstly, I don't understand which issue your are trying to solve.
Secondly, I am opposed to that change, because besides the issues, others already mentioned ("mistakes" etc), we once had a discussion on this topic (IIRC, on @devel, several years ago), which had concluded into "maintainers are advised to trim changelogs/delete obsolete and irrelevant changelog entries" to keep changelogs readable.
Ralf
On Mon, 2010-01-25 at 01:12 -0500, Jon Stanley wrote:
I consider this to be common sense, but it's not in the guidelines right now - that changelog entries are immutable. To that end, I have a really simple draft up here for revision of the guidelines to explicitly state that.
https://fedoraproject.org/wiki/User:Jstanley/Changelog_Draft
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
I'd like to see another exception, trimming out an automated rebuild entry. These don't really add much to the history of the package, no change to the package was made, and it does cause inconsistencies across the Fedora releases when these specs are kept in sync.
And yet another exception, trimming the history for brevity. We don't really need rpm changelogs dating back to 1995 for some of these packages.
I think it would be worth stating the /reason/ why we discourage changing changelog entries, as opposed to just saying "YOU MUST NOT DO IT" and expecting the maintainer to reach a logical conclusion as to why. When you give them the why, you enable them to consider that why with what it is they desire to do and make a reasonable informed decision about their action.
packaging@lists.fedoraproject.org
-
Bruno Wolff III -
Jesse Keating -
Jon Stanley -
Ralf Corsepius -
Till Maas -
Warren Togami