Item for FPC consideration - changelogs
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. -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging |
Item for FPC consideration - changelogs
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 |
Item for FPC consideration - changelogs
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 -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging |
Item for FPC consideration - changelogs
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. -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging |
Item for FPC consideration - changelogs
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). -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging |
Item for FPC consideration - changelogs
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 -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging |
Item for FPC consideration - changelogs
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 -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging |
Item for FPC consideration - changelogs
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 [0] https://fedorahosted.org/fesco/ticket/298 -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging |
Item for FPC consideration - changelogs
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. -- Jesse Keating Fedora -- Freedomē is a feature! identi.ca: http://identi.ca/jkeating -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging |
| All times are GMT. The time now is 12:20 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.