Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 12:17 -0400, Dan Winship wrote: But that's just a gut feeling and maybe it's wrong. The point is, ChangeLogs were invented back when RCS-files-on-an-NFS-server was the pinnacle of version control technology, and maybe what was most useful then isn't what's most useful now. Coming in a bit too late, I'd point out that having the ChangeLog files is good for when all you have is a tarball - think being offline. I otherwise agree with you completely. See you, -- Gustavo Noronha g...@gnome.org GNOME contributor ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Sun, May 10, 2009 at 3:16 PM, Gustavo Noronha g...@gnome.org wrote: On Mon, 2009-04-20 at 12:17 -0400, Dan Winship wrote: But that's just a gut feeling and maybe it's wrong. The point is, ChangeLogs were invented back when RCS-files-on-an-NFS-server was the pinnacle of version control technology, and maybe what was most useful then isn't what's most useful now. Coming in a bit too late, I'd point out that having the ChangeLog files is good for when all you have is a tarball - think being offline. I otherwise agree with you completely. That's why it should be generated automatically when creating tarballs. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, Apr 21, 2009 at 8:26 PM, Tristan Van Berkom t...@gnome.org wrote: On Tue, Apr 21, 2009 at 12:19 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: [...] Dude, we have moved to git and you are still talking of versioned ChangeLog and favoring large patches? With a tool like git, you should be at least able to generate a single reviewable patch, large or small, and thats reviewable, yes. Versioned ChangeLog is a matter of trust, Id personally rather take care of it and revision it by hand, I didnt ask other people to do so, this is what I will do though (also, merging changes in a ChangeLog cannot be difficlult, definitly not more difficult than merging sources). Sending patches along with the modified ChangeLog would be a complete nightmare. Essentially they'll never apply cleanly and you would always need to resolve the conflicts. This would also make incredibly difficult powerful tasks such as rebasing. Please generate the ChangeLog on 'make dist'. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Thu, Apr 23, 2009 at 9:57 AM, Stefan Kost enso...@hora-obscura.de wrote: Tristan Van Berkom schrieb: You always post ChangeLogs diffs with large patches, large patches generally come to the maintainer in the form of a patch, with a single changelog entry, the maintainer reviewing a branch doesnt want to see the revision history of what happened on the branch, or why you reverted that peice of code thats not actually in the patch (and never made it into the baseline/trunk). A git patch has metadata. That is if you use git format-patch then the commit messages go into the patch and if you use git apply they will be applied along with the patch. If it was generated with 'git format-patch', then yes, but AFAIK 'git apply' will not use it, you need 'git am' for that. Also, 'git am' can generate commits out of patch series 'git am *.patch'. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Wed, Apr 22, 2009 at 1:35 AM, Sam Thursfield sss...@gmail.com wrote: Hello! On Tue, Apr 21, 2009 at 6:36 PM, Cody Russell brats...@gnome.org wrote: No, but the point is that if you edit some code and someone else has made changes to some code elsewhere in the repo, and you merge their work into yours.. then maybe you have to fix some conflicts, but maybe not. If you have already added ChangeLog entries and someone else commits something before you commit then you have to resolve conflicts in your ChangeLog 100% of the time. This problem was solved by Bruno Haible, who presents a git merge driver designed specifically for ChangeLog files, in a thread similar to this one: http://www.mail-archive.com/bug-gnu...@gnu.org/msg09183.html It's summed more succinctly in this blog post: http://i-nz.net/2009/03/19/git-automatic-smart-changelog-merging/ That applies only for 'git merge', not for other commands such as 'git am' or 'git rebase'. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Tristan Van Berkom schrieb: On Mon, Apr 20, 2009 at 10:20 PM, Cody Russell brats...@gnome.org wrote: [] Yeah, but the thing that sucks about versioned ChangeLogs is merging/rebasing your code. Typically you always leave writing a ChangeLog last for this reason, but it just makes so much more sense to be able to write your entry when you do your commit. If you're posting a branch for review or something, people can read your commit logs as well as the code.. but if you post patches for review, you probably don't post the ChangeLog with it because it'll get clobbered when you have to merge it into the tree. You always post ChangeLogs diffs with large patches, large patches generally come to the maintainer in the form of a patch, with a single changelog entry, the maintainer reviewing a branch doesnt want to see the revision history of what happened on the branch, or why you reverted that peice of code thats not actually in the patch (and never made it into the baseline/trunk). A git patch has metadata. That is if you use git format-patch then the commit messages go into the patch and if you use git apply they will be applied along with the patch. Stefan Now if I can demand that a patch submitter provide the base minimum: - A patch that applies to trunk - A rich ChangeLog entry that describes what happens in the change Then why would I waste my time flipping through individual commit logs ? Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, 2009-04-21 at 23:13 +0200, Garrett LeSage wrote: In fact, you probably should have a file which would be updated as developers churn along (distributing the effort over time), where each big notable feature/bugfix/etc. is recorded as a line in the file whenever it officially lands. This is basically what I do. I put the file at the top-level and called it ChangeLog. Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Wed, 2009-04-22 at 09:36 +0100, Scott James Remnant wrote: On Tue, 2009-04-21 at 23:13 +0200, Garrett LeSage wrote: In fact, you probably should have a file which would be updated as developers churn along (distributing the effort over time), where each big notable feature/bugfix/etc. is recorded as a line in the file whenever it officially lands. This is basically what I do. I put the file at the top-level and called it ChangeLog. That's generally what NEWS is for. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Le samedi 18 avril 2009, à 21:54 -0400, Behdad Esfahbod a écrit : Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: Can we also agree that for modules dropping ChangeLog, we move the old ChangeLog file to ChangeLog.pre-git? (and if we can put the commit messages guidelines in ChangeLog instead as done in some modules like seahorse) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Wed, 2009-04-22 at 16:47 +0200, Vincent Untz wrote: Le samedi 18 avril 2009, à 21:54 -0400, Behdad Esfahbod a écrit : Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: Can we also agree that for modules dropping ChangeLog, we move the old ChangeLog file to ChangeLog.pre-git? (and if we can put the commit messages guidelines in ChangeLog instead as done in some modules like seahorse) That's a good way to make ChangeLog messages appear along with your instructions, some people use scripts... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Le mercredi 22 avril 2009, à 15:56 +0100, Bastien Nocera a écrit : On Wed, 2009-04-22 at 16:47 +0200, Vincent Untz wrote: Le samedi 18 avril 2009, à 21:54 -0400, Behdad Esfahbod a écrit : Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: Can we also agree that for modules dropping ChangeLog, we move the old ChangeLog file to ChangeLog.pre-git? (and if we can put the commit messages guidelines in ChangeLog instead as done in some modules like seahorse) That's a good way to make ChangeLog messages appear along with your instructions, some people use scripts... I'm just suggesting to do what some modules have adopted (and some have been doing this for quite some time). What kind of scripts can this break? Maybe it's possible to do something so that the scripts can see it's not a ChangeLog entry. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, Apr 20, 2009 at 10:20 PM, Cody Russell brats...@gnome.org wrote: [] Yeah, but the thing that sucks about versioned ChangeLogs is merging/rebasing your code. Typically you always leave writing a ChangeLog last for this reason, but it just makes so much more sense to be able to write your entry when you do your commit. If you're posting a branch for review or something, people can read your commit logs as well as the code.. but if you post patches for review, you probably don't post the ChangeLog with it because it'll get clobbered when you have to merge it into the tree. You always post ChangeLogs diffs with large patches, large patches generally come to the maintainer in the form of a patch, with a single changelog entry, the maintainer reviewing a branch doesnt want to see the revision history of what happened on the branch, or why you reverted that peice of code thats not actually in the patch (and never made it into the baseline/trunk). Now if I can demand that a patch submitter provide the base minimum: - A patch that applies to trunk - A rich ChangeLog entry that describes what happens in the change Then why would I waste my time flipping through individual commit logs ? Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, Apr 21, 2009 at 6:51 PM, Tristan Van Berkom t...@gnome.org wrote: On Mon, Apr 20, 2009 at 10:20 PM, Cody Russell brats...@gnome.org wrote: [] Yeah, but the thing that sucks about versioned ChangeLogs is merging/rebasing your code. Typically you always leave writing a ChangeLog last for this reason, but it just makes so much more sense to be able to write your entry when you do your commit. If you're posting a branch for review or something, people can read your commit logs as well as the code.. but if you post patches for review, you probably don't post the ChangeLog with it because it'll get clobbered when you have to merge it into the tree. You always post ChangeLogs diffs with large patches, large patches generally come to the maintainer in the form of a patch, with a single changelog entry, the maintainer reviewing a branch doesnt want to see the revision history of what happened on the branch, or why you reverted that peice of code thats not actually in the patch (and never made it into the baseline/trunk). Now if I can demand that a patch submitter provide the base minimum: - A patch that applies to trunk - A rich ChangeLog entry that describes what happens in the change Then why would I waste my time flipping through individual commit logs ? Dude, we have moved to git and you are still talking of versioned ChangeLog and favoring large patches? -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, Apr 21, 2009 at 12:19 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: [...] Dude, we have moved to git and you are still talking of versioned ChangeLog and favoring large patches? With a tool like git, you should be at least able to generate a single reviewable patch, large or small, and thats reviewable, yes. Versioned ChangeLog is a matter of trust, Id personally rather take care of it and revision it by hand, I didnt ask other people to do so, this is what I will do though (also, merging changes in a ChangeLog cannot be difficlult, definitly not more difficult than merging sources). Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, 2009-04-21 at 13:26 -0400, Tristan Van Berkom wrote: Versioned ChangeLog is a matter of trust, Id personally rather take care of it and revision it by hand, I didnt ask other people to do so, this is what I will do though (also, merging changes in a ChangeLog cannot be difficlult, definitly not more difficult than merging sources). No, but the point is that if you edit some code and someone else has made changes to some code elsewhere in the repo, and you merge their work into yours.. then maybe you have to fix some conflicts, but maybe not. If you have already added ChangeLog entries and someone else commits something before you commit then you have to resolve conflicts in your ChangeLog 100% of the time. If it's not a big deal to you, cool. I was just pointing out that this is something sucky about dealing with ChangeLog files that exist in your repo instead of being generated by your VCS. / Cody ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 09:01 -0500, Jonathon Jongsma wrote: Same thing with the dates. The old ChangeLog only had dates, not time, so there is imho no loss in just using dates in the autogenerated file. I agree with alex. The changelog should be easily readable. big strings of +++-- make it harder to scan. If we want that detailed level of information, we can always extract it from git on demand anyway. If anybody eventually thinks they have a decent way to generate ChangeLogs then please do add it here so we can have some consistency: http://live.gnome.org/Git/ChangeLog I'm interested to see the result, though I'm frankly resigned to the entropy increase. I personally have never seen a generated ChangeLog that was anywhere near as useful as a separate ChangeLog, regardless of what other tools are available to do commits archeology, so my projects will not change that practice just because of a VCS change. No, I'm not interested in discussing it. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, Apr 21, 2009 at 4:23 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: [...] Reminds me of my friend who insists that evolution is nothing more than hoax and when I try to educate him, he doesn't want to discuss it. :) There are simply two facts to be kept in mind here: 1. All information in the ChangeLog is redundant. 2. Maintaining a ChangeLog only and only realizes otherwise inexistent conflicts. It is as simple as that. Sure, on the other hand projects with ChangeLogs that are hand-tended to are, in my personal experience richer than logs of arbitrary commits, if only by the simple virtue of forcing you to spend time caring for it. Anyway, lets see what some experiments yield ;-) Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Tristan Van Berkom wrote: Sure, on the other hand projects with ChangeLogs that are hand-tended to are, in my personal experience richer than logs of arbitrary commits, if only by the simple virtue of forcing you to spend time caring for it. I use ChangeLogs a lot. My preference for hand-made ChangeLogs is that the author involuntarily tends to order things by priority. The fact that he bumped the solib version is much more important than that he cleaned up whitespace, fixed an include flag that breaks on some obscure platform, etc. The latter of examples of the kind of entries frequently seen in auto-generated logs. As Murray says, increased entropy. I'll take a weak wine to a high-powered beer any day. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, Apr 21, 2009 at 3:32 PM, Tristan Van Berkom t...@gnome.org wrote: Sure, on the other hand projects with ChangeLogs that are hand-tended to are, in my personal experience richer than logs of arbitrary commits, if only by the simple virtue of forcing you to spend time caring for it. Anyway, lets see what some experiments yield ;-) Anyone submitting patches to our module without a proper commit log message will likely have their patch gently rejected until it's fixed. That certainly is the case with the vast majority of FOSS projects out there using git. See git format-patch. Likewise, at some point, translators making a commit log message that reads Updated a file. will have their commit reverted with an explanation in the commit log as to why it was reverted. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On 04/21/2009 10:23 PM, Zeeshan Ali (Khattak) wrote: 1. All information in the ChangeLog is redundant. 2. Maintaining a ChangeLog only and only realizes otherwise inexistent conflicts. Agreed. You could do what we've been doing in a project of mine: Auto-generating the changelogs on release, and publishing a hand-picked friendly changelog too. In fact, you probably should have a file which would be updated as developers churn along (distributing the effort over time), where each big notable feature/bugfix/etc. is recorded as a line in the file whenever it officially lands. When you make a release, create a tag in git (using git tag -a of course). When you diff the file between tags (this can be done easily if you have a release branch which always points at the most current release) and extract only the new lines, you have a changelog of well-written, user-friendly features — perfect for posting to your project's website, sending out to a mailing list, etc. Then, for those who want a more traditional here's-everything changelog, just generate a changelog based on your git commit messages. This should also be done also automatically on release. The nice thing about a process like this is that it minimizes the effort needed (since it's all done automatically using git, at release time) and should make everyone happy. Garrett ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Hello! On Tue, Apr 21, 2009 at 6:36 PM, Cody Russell brats...@gnome.org wrote: No, but the point is that if you edit some code and someone else has made changes to some code elsewhere in the repo, and you merge their work into yours.. then maybe you have to fix some conflicts, but maybe not. If you have already added ChangeLog entries and someone else commits something before you commit then you have to resolve conflicts in your ChangeLog 100% of the time. This problem was solved by Bruno Haible, who presents a git merge driver designed specifically for ChangeLog files, in a thread similar to this one: http://www.mail-archive.com/bug-gnu...@gnu.org/msg09183.html It's summed more succinctly in this blog post: http://i-nz.net/2009/03/19/git-automatic-smart-changelog-merging/ Sam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Sat, 2009-04-18 at 21:54 -0400, Behdad Esfahbod wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: I tweaked this macro a bit for gvfs and nautilus: Here is what I use: git log --stat -M -C --name-status --date=short --no-color | fmt --split-only Its uses less space and is imho just as useful for causual offline use. And if you want more there is git anyway. Example: - snip - commit 6fa515051dc7f082896151545a41a29853f4a3bc Author: Alexander Larsson al...@redhat.com Date: 2009-04-17 Add README.commits and dist it Add file explaining how we want commits to look. Also dist gvfs.doap and the ChangeLog.pre-1-2 M Makefile.am A README.commits commit 8cd532cf7715a4791d8156a711ecb7344b27cb46 Author: Alexander Larsson al...@redhat.com Date: 2009-04-17 Move ChangeLog to ChangeLog.pre-1-2 We're not using manual ChangeLogs anymore. R099ChangeLog ChangeLog.pre-1-2 - snip - Versus: - snip - commit 6fa515051dc7f082896151545a41a29853f4a3bc Author: Alexander Larsson al...@redhat.com Date: Fri Apr 17 10:24:37 2009 +0200 Add README.commits and dist it Add file explaining how we want commits to look. Also dist gvfs.doap and the ChangeLog.pre-1-2 Makefile.am|3 ++ README.commits | 63 2 files changed, 66 insertions(+), 0 deletions(-) commit 8cd532cf7715a4791d8156a711ecb7344b27cb46 Author: Alexander Larsson al...@redhat.com Date: Fri Apr 17 10:23:28 2009 +0200 Move ChangeLog to ChangeLog.pre-1-2 We're not using manual ChangeLogs anymore. ChangeLog | 6816 ChangeLog.pre-1-2 | 6822 + 2 files changed, 6822 insertions(+), 6816 deletions(-) - snip - ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 12:48 +0200, Alexander Larsson wrote: On Sat, 2009-04-18 at 21:54 -0400, Behdad Esfahbod wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: I tweaked this macro a bit for gvfs and nautilus: Here is what I use: git log --stat -M -C --name-status --date=short --no-color | fmt --split-only Its uses less space and is imho just as useful for causual offline use. And if you want more there is git anyway. Could we get the ChangeLog generation added as a macro to gnome-common? That would make it easier, and more consistent. We should also use --since or --after so as to avoid duplicating data that's in the other ChangeLogs. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On 04/20/2009 09:02 AM, Bastien Nocera wrote: On Mon, 2009-04-20 at 12:48 +0200, Alexander Larsson wrote: On Sat, 2009-04-18 at 21:54 -0400, Behdad Esfahbod wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: I tweaked this macro a bit for gvfs and nautilus: Here is what I use: git log --stat -M -C --name-status --date=short --no-color | fmt --split-only Its uses less space and is imho just as useful for causual offline use. And if you want more there is git anyway. I like the more verbose format clearly showing which changes are big and which are small. Could we get the ChangeLog generation added as a macro to gnome-common? That would make it easier, and more consistent. We should also use --since or --after so as to avoid duplicating data that's in the other ChangeLogs. That's basically why I'm trying to figure out how we want it to work. behdad Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 09:06 -0400, Behdad Esfahbod wrote: On 04/20/2009 09:02 AM, Bastien Nocera wrote: On Mon, 2009-04-20 at 12:48 +0200, Alexander Larsson wrote: On Sat, 2009-04-18 at 21:54 -0400, Behdad Esfahbod wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: I tweaked this macro a bit for gvfs and nautilus: Here is what I use: git log --stat -M -C --name-status --date=short --no-color | fmt --split-only Its uses less space and is imho just as useful for causual offline use. And if you want more there is git anyway. I like the more verbose format clearly showing which changes are big and which are small. Well, I don't really disagree that its nice to know. However, all such info is readily availible in git, and can be posted in e.g. a release mail for all the recent changes. However, the autogenerated ChangeLog file will contain *all* post-git conversion changes, and especially with micro-commits this will be a lot, so it will eventually be quite large. So, it would be nice to do whatever we can to make our tarballs smaller that doesn't have a major impact on the usability, and while there is some loss of functionallity its not large, and we don't lose anything compared to the old ChangeLog entries. Same thing with the dates. The old ChangeLog only had dates, not time, so there is imho no loss in just using dates in the autogenerated file. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Alexander Larsson wrote: On Mon, 2009-04-20 at 09:06 -0400, Behdad Esfahbod wrote: On 04/20/2009 09:02 AM, Bastien Nocera wrote: On Mon, 2009-04-20 at 12:48 +0200, Alexander Larsson wrote: On Sat, 2009-04-18 at 21:54 -0400, Behdad Esfahbod wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: I tweaked this macro a bit for gvfs and nautilus: Here is what I use: git log --stat -M -C --name-status --date=short --no-color | fmt --split-only Its uses less space and is imho just as useful for causual offline use. And if you want more there is git anyway. I like the more verbose format clearly showing which changes are big and which are small. Well, I don't really disagree that its nice to know. However, all such info is readily availible in git, and can be posted in e.g. a release mail for all the recent changes. However, the autogenerated ChangeLog file will contain *all* post-git conversion changes, and especially with micro-commits this will be a lot, so it will eventually be quite large. So, it would be nice to do whatever we can to make our tarballs smaller that doesn't have a major impact on the usability, and while there is some loss of functionallity its not large, and we don't lose anything compared to the old ChangeLog entries. Same thing with the dates. The old ChangeLog only had dates, not time, so there is imho no loss in just using dates in the autogenerated file. I agree with alex. The changelog should be easily readable. big strings of +++-- make it harder to scan. If we want that detailed level of information, we can always extract it from git on demand anyway. -- jonner ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On 04/20/2009 10:00 AM, Dan Winship wrote:
Alexander Larsson wrote:
On Mon, 2009-04-20 at 09:06 -0400, Behdad Esfahbod wrote:
I like the more verbose format clearly showing which changes are big and which
are small.
Well, I don't really disagree that its nice to know. However, all such
info is readily availible in git
Right. People who want the full git history are also going to want to
have a full checkout handy, and they can just use git log with
whatever flags they like.
Here's something to generate a fairly traditional-looking ChangeLog
(though working on the assumption that you're doing the subject vs body
split in your git commit messages):
git log --date=short --pretty=format:%cd %an%ae%n%n%s%n%n%b |
perl -ne 'if (/^\s*$/) { if (!$blank) { print; $blank=1; } } else
{$blank=0; if (!s/^// !/^\t/) { print \t; } print; }'
I'd rather use awk. Listing of files is also desired, since old ChangeLog
files contained those.
behdad
%cd is commit date, %an is Author name and %ae is Author email. The perl
part indents every commit description line that doesn't already start
with a tab, and removes duplicate blank lines. Assuming the lines were
wrapped to 72 columns to start with, this will make them look too long,
but won't actually cause anything new to wrap.
-- Dan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Alexander Larsson wrote:
On Mon, 2009-04-20 at 09:06 -0400, Behdad Esfahbod wrote:
I like the more verbose format clearly showing which changes are big and
which
are small.
Well, I don't really disagree that its nice to know. However, all such
info is readily availible in git
Right. People who want the full git history are also going to want to
have a full checkout handy, and they can just use git log with
whatever flags they like.
Here's something to generate a fairly traditional-looking ChangeLog
(though working on the assumption that you're doing the subject vs body
split in your git commit messages):
git log --date=short --pretty=format:%cd %an %ae%n%n%s%n%n%b |
perl -ne 'if (/^\s*$/) { if (!$blank) { print; $blank=1; } } else
{$blank=0; if (!s/^// !/^\t/) { print \t; } print; }'
%cd is commit date, %an is Author name and %ae is Author email. The perl
part indents every commit description line that doesn't already start
with a tab, and removes duplicate blank lines. Assuming the lines were
wrapped to 72 columns to start with, this will make them look too long,
but won't actually cause anything new to wrap.
-- Dan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 10:00 -0400, Dan Winship wrote:
Alexander Larsson wrote:
On Mon, 2009-04-20 at 09:06 -0400, Behdad Esfahbod wrote:
I like the more verbose format clearly showing which changes are big and
which
are small.
Well, I don't really disagree that its nice to know. However, all such
info is readily availible in git
Right. People who want the full git history are also going to want to
have a full checkout handy, and they can just use git log with
whatever flags they like.
Here's something to generate a fairly traditional-looking ChangeLog
(though working on the assumption that you're doing the subject vs body
split in your git commit messages):
git log --date=short --pretty=format:%cd %an %ae%n%n%s%n%n%b |
perl -ne 'if (/^\s*$/) { if (!$blank) { print; $blank=1; } } else
{$blank=0; if (!s/^// !/^\t/) { print \t; } print; }'
%cd is commit date, %an is Author name and %ae is Author email. The perl
part indents every commit description line that doesn't already start
with a tab, and removes duplicate blank lines. Assuming the lines were
wrapped to 72 columns to start with, this will make them look too long,
but won't actually cause anything new to wrap.
You can rewrap with fmt --split-only.
That looks good though, but would be nice to have some reference to what
files changed. Makes it easy to search for that.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Alexander Larsson wrote:
On Mon, 2009-04-20 at 10:00 -0400, Dan Winship wrote:
Here's something to generate a fairly traditional-looking ChangeLog
(though working on the assumption that you're doing the subject vs body
split in your git commit messages):
git log --date=short --pretty=format:%cd %an %ae%n%n%s%n%n%b |
perl -ne 'if (/^\s*$/) { if (!$blank) { print; $blank=1; } } else
{$blank=0; if (!s/^// !/^\t/) { print \t; } print; }'
%cd is commit date, %an is Author name and %ae is Author email. The perl
part indents every commit description line that doesn't already start
with a tab, and removes duplicate blank lines. Assuming the lines were
wrapped to 72 columns to start with, this will make them look too long,
but won't actually cause anything new to wrap.
You can rewrap with fmt --split-only.
Yeah, but that ends up looking bad if the lines were already wrapped
reasonably. (Also, that's a GNU-only option, so we'd probably want to
just reimplement it in the perl script if we did want.)
That looks good though, but would be nice to have some reference to what
files changed. Makes it easy to search for that.
You can do that in a slightly lame way by adding --name-only to the
git log command line. Doing something clearer than that would only take
a little more work.
But I've been including filenames or function names in most of my commit
messages, so I feel like adding them explicitly to the ChangeLog as well
would end up being redundant...
So, actually, what exactly IS the use case of ChangeLog if there is git
history on one end and NEWS on the other? Who are the people who need
more information than NEWS gives, but who would not want to actually
check out the source tree, and what information, exactly, do they need?
-- Dan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote: [...] So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Generally its the tarball that is published and trusted, not the git repository. The ChangeLog comes with the published tarball like an exported history, for the use of anyone who receives the tarball (the NEWS is just a quick resume of what happened in a release). Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 11:20 -0400, Tristan Van Berkom wrote: On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote: [...] So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Generally its the tarball that is published and trusted, not the git repository. Given that tags can be signed in Git, shouldn't it be about time that we move to a more modern way of trust, one that maintains a 1:1 mapping between changelog and changes? Kind regards, Ruben -- Ruben Vermeersch (rubenv) http://www.savanne.be/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 14:02 +0100, Bastien Nocera wrote: Could we get the ChangeLog generation added as a macro to gnome-common? There's a bug for it, but no apparent activity (yet): http://bugzilla.gnome.org/show_bug.cgi?id=579279 Philip That would make it easier, and more consistent. We should also use --since or --after so as to avoid duplicating data that's in the other ChangeLogs. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, Apr 20, 2009 at 11:35 AM, Ruben Vermeersch ru...@savanne.be wrote: On Mon, 2009-04-20 at 11:20 -0400, Tristan Van Berkom wrote: On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote: [...] So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Generally its the tarball that is published and trusted, not the git repository. Given that tags can be signed in Git, shouldn't it be about time that we move to a more modern way of trust, one that maintains a 1:1 mapping between changelog and changes? For someone that maintains a module, how you manage your ChangeLog and how much you trust your current revisioning system to do what you expect is your business, I personally feel safer populating my revision history with ChangeLog entries and not the other way around, but thats my perogative and besides the point here. On the other hand, for someone who receives your release, i.e. your tarball, they dont want to know how you manage your ChangeLog or your revision history, without forcing them to understand git, or understand branching schemes in GNOME, they still deserve an exported ChangeLog (which is why I answer to Dan, this is why we do at least need a ChangeLog, generated or otherwise). Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Tristan Van Berkom wrote: On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote: [...] So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Generally its the tarball that is published and trusted, not the git repository. The ChangeLog comes with the published tarball like an exported history, for the use of anyone who receives the tarball (the NEWS is just a quick resume of what happened in a release). But that doesn't answer the question. Who are these people who read ChangeLog, and what is it that they're doing with it, such that NEWS is too brief, but a fully-VCS-ed source tree is unnecessary. Eg, this subthread started when Alex suggested that we needed to put the names of all modified files into each ChangeLog entry. It seems to me that anyone who cares exactly which files got modified by a particular change is going to want to see the actual diff very soon after, and so those people are not actually part of the don't-need-a-full-checkout use case. But that's just a gut feeling and maybe it's wrong. The point is, ChangeLogs were invented back when RCS-files-on-an-NFS-server was the pinnacle of version control technology, and maybe what was most useful then isn't what's most useful now. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 10:58 -0400, Dan Winship wrote: So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Very good question! I used to think that a ChangLog was very nice for casual bug-fixers, who may want to fix a quickie bug without having a full clone, but maintaining those one-off patches is so cumbersome in the long run that you are much better off getting a full clone anyway. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On 04/20/2009 12:45 PM, Federico Mena Quintero wrote: On Mon, 2009-04-20 at 10:58 -0400, Dan Winship wrote: So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Very good question! I used to think that a ChangLog was very nice for casual bug-fixers, who may want to fix a quickie bug without having a full clone, but maintaining those one-off patches is so cumbersome in the long run that you are much better off getting a full clone anyway. Indeed. These days I find it that just reading the ChangeLog comments is no where close to enough to find out *why* something is the way it is. And that's assuming that you can find the ChangeLog entry to begin with. I find myself doing the following more and more these days: - git blame, lookup the commit id of the line I'm interested in, - check the commit in full, including the patch, how things were, why they changed, and what may have been overlooked in that change. Read bug history on any bugs referenced in the commit, - If this looks like a patch in a series, do a git-log and check surrounding commits, - Only then fix the bug and have confidence in the fix. behdad Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Le lundi 20 avril 2009 à 12:17 -0400, Dan Winship a écrit : Who are these people who read ChangeLog Hi, The ChangeLog are quite handy for distribution packages, they have a list of the changes you can look at quickly and the closed bug numbers. Usually NEWS summary are either not there or listing only main changes in the new version and not enough to know what bugs you can close while doing the upgrade for example Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, Apr 20, 2009 at 7:10 PM, Sebastien Bacher seb...@ubuntu.com wrote: Le lundi 20 avril 2009 à 12:17 -0400, Dan Winship a écrit : Who are these people who read ChangeLog Hi, The ChangeLog are quite handy for distribution packages, they have a list of the changes you can look at quickly and the closed bug numbers. Usually NEWS summary are either not there or listing only main changes in the new version and not enough to know what bugs you can close while doing the upgrade for example Exactly, very useful when adapting downstream patches (and before you go to kick my ass, there are various kinds of patches that can't and won't go upstream including various distro-specific path customizations at build time). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 12:17 -0400, Dan Winship wrote: Tristan Van Berkom wrote: On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote: [...] So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want tSysadmins, Package maintainersmo actually check out the source tree, and what information, exactly, do they need? Generally its the tarball that is published and trusted, not the git repository. The ChangeLog comes with the published tarball like an exported history, for the use of anyone who receives the tarball (the NEWS is just a quick resume of what happened in a release). But that doesn't answer the question. Who are these people who read ChangeLog, and what is it that they're doing with it, such that NEWS is too brief, but a fully-VCS-ed source tree is unnecessary. Eg, this subthread started when Alex suggested that we needed to put the names of all modified files into each ChangeLog entry. It seems to me that anyone who cares exactly which files got modified by a particular change is going to want to see the actual diff very soon after, and so those people are not actually part of the don't-need-a-full-checkout use case. But that's just a gut feeling and maybe it's wrong. The point is, ChangeLogs were invented back when RCS-files-on-an-NFS-server was the pinnacle of version control technology, and maybe what was most useful then isn't what's most useful now. Sysadmins and they take the decision if it worth an update/upgrade or when they should do it. If we ask people to read ChangeLogs from git, I wonder why do we bother in releasing tarballs when they could them from the repository also? (in the sense you can get a tar.gz/tar.bz2, they are tagged, etc.) -- Germán Póo-Caamaño Concepción - Chile http://www.gnome.org/~gpoo/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 15:37 -0400, Germán Póo-Caamaño wrote: But that's just a gut feeling and maybe it's wrong. The point is, ChangeLogs were invented back when RCS-files-on-an-NFS-server was the pinnacle of version control technology, and maybe what was most useful then isn't what's most useful now. Sysadmins and they take the decision if it worth an update/upgrade or when they should do it. If we ask people to read ChangeLogs from git, I wonder why do we bother in releasing tarballs when they could them from the repository also? (in the sense you can get a tar.gz/tar.bz2, they are tagged, etc.) This is a totally bogus comparison in so many way. First of all, not everyone has the setup necessary to dist from the repository, secondly a release that you can put on a ftp site, CD, in an rpm, or whatever is clearly necessary, whereas its not at all obvious exactly how and if a ChangeLog in the tarball is used. For instance, if a sysadmin wants to determine wheter to update to the new release of gtk+. Starting from zero data, how does he start? Does he download the tarball and extract the ChangeLog? Possibly so, but it seems vastly easier to look at e.g the release mail, the NEWS file on the ftp site, or even the gnome cgit instance. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Sat, 2009-04-18 at 22:23 -0400, Tristan Van Berkom wrote: I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: Personally, I prefer maintaining an actual revisioned ChangeLog file, simply because I like having the ChangeLog as a part of the project data, revisioning tools come and go, projects get exported and imported, but the ChangeLog always remains in the repository or published tarball. Yeah, but the thing that sucks about versioned ChangeLogs is merging/rebasing your code. Typically you always leave writing a ChangeLog last for this reason, but it just makes so much more sense to be able to write your entry when you do your commit. If you're posting a branch for review or something, people can read your commit logs as well as the code.. but if you post patches for review, you probably don't post the ChangeLog with it because it'll get clobbered when you have to merge it into the tree. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Behdad Esfahbod wrote: Cons: - Have to modify autogen.sh to create an empty ChangeLog, or pass the foreign flag to automake We really ought to be passing foreign anyway. No one benefits from having people be forced to create 0-length README files. (And if we want to say but people should have useful README files, then we should create our own GNOME module standards rather than accidentally picking up the GNU ones, and then we should actually enforce them.) -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On 04/19/2009 11:34 AM, Dan Winship wrote: Behdad Esfahbod wrote: Cons: - Have to modify autogen.sh to create an empty ChangeLog, or pass the foreign flag to automake We really ought to be passing foreign anyway. No one benefits from having people be forced to create 0-length README files. (And if we want to say but people should have useful README files, then we should create our own GNOME module standards rather than accidentally picking up the GNU ones, and then we should actually enforce them.) I actually like the GNU standards. A one-line README is much better than no README. The only bit that has become really limiting is warning on non-portable Makefile's. behdad -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Sat, Apr 18, 2009 at 9:54 PM, Behdad Esfahbod beh...@behdad.org wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: Personally, I prefer maintaining an actual revisioned ChangeLog file, simply because I like having the ChangeLog as a part of the project data, revisioning tools come and go, projects get exported and imported, but the ChangeLog always remains in the repository or published tarball. ... I'd be tempted though to somehow preset the commit message of a changeset to be the current diffs against the ChangeLog (i.e. when prompted with the editor), that would save me a step of getting the information from ChangeLog into the commit message... Cheers, -Tristan Pros for generating ChangeLog proper: - No need to have a placeholder ChangeLog, nor need to pass foreign to automake - You can make ChangeLog and inspect it before it goes into the tarball Cons: - Have to modify autogen.sh to create an empty ChangeLog, or pass the foreign flag to automake Humm, no idea about pros and cons of the other approach. So, what do people think? Cheers, behdad PS. If you need any autotools hacking, related to git or not, feel free to ping me. I'd always be happy to help. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Sat, 2009-04-18 at 22:23 -0400, Tristan Van Berkom wrote: On Sat, Apr 18, 2009 at 9:54 PM, Behdad Esfahbod beh...@behdad.org wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: Personally, I prefer maintaining an actual revisioned ChangeLog file, simply because I like having the ChangeLog as a part of the project data, revisioning tools come and go, projects get exported and imported, but the ChangeLog always remains in the repository or published tarball. I recall someone once mentioning (excuse my butchering the correct terms) a git merge strategy that makes it easier to maintain a ChangeLog and not have to fight with it when merging branches. Who was that person, and can they please attach the information to http://live.gnome.org/Git/ChangeLog Thanks John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
