Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Mon, 2007-09-17 at 21:05 -0600, Elijah Newren wrote: > On 9/17/07, Sebastien Bacher <[EMAIL PROTECTED]> wrote: > > Le dimanche 16 septembre 2007 à 09:42 +0200, Vincent Untz a écrit : > > > Le samedi 15 septembre 2007, à 21:44 -0400, Behdad Esfahbod a écrit : > > > > Ok, lets be fair: most people who care about hacking on GNOME already > > > > know git, why should other options be selected? > > > > > > I don't think it is fair to state this. A lot of people certainly care > > > about hacking on GNOME and don't know git (and don't care about it). > > > > I think Vincent is right there, looks like some people are using git and > > trying to make it look like that's the case for everybody else in the > > GNOME world which is not correct > > To be fair, if my guess is right that low-level GNOME hackers are > highly correlated with git users (and anti-correlated to usage of > other SCM systems)[1], then it may well have seemed to Behdad that > this was in fact the case, as he is most likely to interact > development wise with his fellow low-level hackers. Yep, most probably. Didn't want to cheat. I corrected myself in a follow-up. All I'm saying is that in all the various threads about this issue this past couple of weeks, we've seen many pro-git hackers, but not as many pro-others. But I particularly think your low-level vs higher-level separation is very real. Which leads me to think that there's no reason why all GNOME modules have to live in the same kind of repository. > Again, just some food for thought. > > Elijah > > [1] > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00195.html -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On 9/17/07, Sebastien Bacher <[EMAIL PROTECTED]> wrote: > Le dimanche 16 septembre 2007 à 09:42 +0200, Vincent Untz a écrit : > > Le samedi 15 septembre 2007, à 21:44 -0400, Behdad Esfahbod a écrit : > > > Ok, lets be fair: most people who care about hacking on GNOME already > > > know git, why should other options be selected? > > > > I don't think it is fair to state this. A lot of people certainly care > > about hacking on GNOME and don't know git (and don't care about it). > > I think Vincent is right there, looks like some people are using git and > trying to make it look like that's the case for everybody else in the > GNOME world which is not correct To be fair, if my guess is right that low-level GNOME hackers are highly correlated with git users (and anti-correlated to usage of other SCM systems)[1], then it may well have seemed to Behdad that this was in fact the case, as he is most likely to interact development wise with his fellow low-level hackers. Again, just some food for thought. Elijah [1] http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00195.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Sun, 2007-09-16 at 21:43 +0200, Thomas Vander Stichele wrote: > On Sun, 2007-09-16 at 00:13 +0200, Jaap Haitsma wrote: > > Hi > > > > Talking to Daniel "Cheese" Siegel we asked ourselves: > > Why do all GNOME projects have a ChangeLog file? > > Isn't it redundant when you just save a commit message. > > Because they communicate at different levels. Well, with the rule that all commits should have accompanying ChangeLog entries, there can't be much different levels of communication. > I have yet to see a project that has clear, concise commit messages, and > all the commits are well-defined, atomic, and no screwups. See cairo. > The number of commit messages that go "fixed stupid typo" or "I was > drunk when I commited this" make a commit message log unsuitable as a > candidate for a ChangeLog. > > When I'm reading a ChangeLog, I want to know what changed in the > software overall; what changes the developers are making, and why they > are making them. I don't want to read about every single small detail > they changed while making those changes. > > When I'm reading a commit log, I typically figure out what the hell a > developer was thinking when he introduced a bug or did something silly. Not sure I follow. IMO many projects have crappy log messages because people already wrote the important stuff in the ChangeLog, so they think that the log message is not important. If you tell them that commit log is where the ChangeLog comes from, that changes everything. Of course the downside is that you can't use prepare-ChangeLog.pl, but if you are committing atomic changes with git, it doesn't matter as your changes apply to all files involved. No need to go into per-file detail. This is cairo's commit log for some recent commits for example: commit 21ab44f11d3d20eead5d988c7a6cf48eebff08c7 Author: Behdad Esfahbod <[EMAIL PROTECTED]> Date: Mon Sep 17 16:41:52 2007 -0400 [ChangeLog.mk] Make make rule depend on .git/HEAD, not .git That is exactly what we want. Kristian Høgsberg suggested it. commit 3f4875dbe20e1d093d70f49c32f7ddf6a6e6ef61 Author: Adrian Johnson <[EMAIL PROTECTED]> Date: Sun Sep 16 20:26:33 2007 +0930 Analysis-surface: Use pattern extents to limit show_glyphs extents commit 14786385b40aa0ae83e3b077a82e3f34aba63f22 Author: Adrian Johnson <[EMAIL PROTECTED]> Date: Sun Sep 16 19:43:28 2007 +0930 Change paginated surface size when PS/PDF _set_size() called The finer-grained fallbacks would not work correctly if the page was set to a larger size. Add _cairo_paginated_surface_set_size() function that is called from cairo_ps_surface_set_size() and cairo_pdf_surface_set_size(). commit 46cb7e69526e8b5663077e7409dc232a0f56800b Author: Adrian Johnson <[EMAIL PROTECTED]> Date: Sun Sep 16 16:32:54 2007 +0930 PS: Remove initclip operator The DSC and EPS specifications do not allow the use of initclip. Instead each page is wrapped in a gsave/restore pair and a "grestore gsave" is emitted when the clip path is reset. > Just my 2 cents, > Thomas > > -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GDM branches for 2.20
GDM2 has been branched for GNOME 2.20. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Sun, 2007-09-16 at 00:13 +0200, Jaap Haitsma wrote: > Hi > > Talking to Daniel "Cheese" Siegel we asked ourselves: > Why do all GNOME projects have a ChangeLog file? > Isn't it redundant when you just save a commit message. Because they communicate at different levels. I have yet to see a project that has clear, concise commit messages, and all the commits are well-defined, atomic, and no screwups. The number of commit messages that go "fixed stupid typo" or "I was drunk when I commited this" make a commit message log unsuitable as a candidate for a ChangeLog. When I'm reading a ChangeLog, I want to know what changed in the software overall; what changes the developers are making, and why they are making them. I don't want to read about every single small detail they changed while making those changes. When I'm reading a commit log, I typically figure out what the hell a developer was thinking when he introduced a bug or did something silly. Just my 2 cents, Thomas -- And every time she sneezes I think it's love and oh lord I'm not ready for this sort of thing -- MOAP - Maintaining your projects since 2006 https://apestaart.org/moap/trac/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI break request: logout icon
Le jeudi 06 septembre 2007, à 11:25 +0200, Frederic Crozat a écrit : > Le jeudi 06 septembre 2007 à 11:09 +0200, Luca Ferretti a écrit : > > Previous icon: "gnome-logout", with the appearance of an open door with > > a red arrow on it. > > > > New icon: "system-log-out" (as per Icon Naming Spec), see > > http://people.freedesktop.org/~jimmac/icons/ (note that the door with > > red arrow is now used for "application-exit") > > > > Issues: > > 1. new and previous icons are currently both shipped in > > gnome-icon-theme (see bug #473082) > > This is not a problem to have both icons, I think. > > > 2. panel should use the new icon (see bug #472254) > > Vuntz, where are you ? :) > > Approval 1 of 2 for UI freeze if doc-team is ok with it. I hate to approve break requests for a module I maintain, but here's a second approval. Rationale: we don't have the old icon in 22x22 size, so the new one is used anyway in the menu. I asked if we could have the old icon in 22x22 size, but we won't have it before 2.20.0. So it's better to at least always use the same icon in the panel (instead of having a mix of the two...). 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: Why have a ChangeLog file if you already have commit messages?
On Mon, 2007-09-17 at 09:51 -0400, Tristan Van Berkom wrote: > > The ChangeLog therefore throws away one of the biggest advantages of > > DSCM, which is not only offering decentralized source control, or very > > fast commits, but also much more intelligent branching and merging when > > compared to CVS or Subversion. > > I've never seen a merge conflict in a ChangeLog that wasnt /really/ easy > to resolve - usually I just include both different portions unless I've > been backporting fixes to a stable branch in which case some cherry > picking is needed. not when you're merging a branch that might span a development cycle. making a merge work in that case is so frustrating that the current approach is to simply fill out a secondary ChangeLog with the branch changes and then add it to "trunk" (HEAD or whatever). > ChangeLogs from my experience are always better than commit logs > probably /because/ its a revisioned file; i.e. people care about > the quality of the changelog, because they have to reffer to it > when fixing bugs etc - its actually part of the product. I thought about it in the exact same terms - a ChangeLog is something surely more interesting than reading a NEWS file. but then I found myself writing more interesting commit logs, often very long, detailing what and why I did something, more free form than what I usually do in ChangeLogs (because of the formatting rules and the fact that most of the space gets stolen away by the functions and files list). as for bugs: the patchsets I sometime attach to bugs via git-send-bugzilla contain not only the patches but a short description of each one of them, and it's much better than a single ChangeLog entry. this would work with SVN as well - as, unlike CVS, a commit is atomic - and I often though about dropping the ChangeLog requirement for the stuff I maintain. the only remaining bit would be merging, but we all know that SVN is not very good at that either. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gcalctool branched for 2.20
gcalctool has been branched for GNOME 2.20. The branch name is "gnome-2-20". Future work (mostly bug fixes, unless anybody would like to help with some of the suggested enhancements) will continue in trunk. Thanks. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Mon, 2007-09-17 at 13:20 +0100, Gustavo J. A. M. Carneiro wrote: > On Seg, 2007-09-17 at 10:49 +0100, Emmanuele Bassi wrote: > > On Mon, 2007-09-17 at 11:36 +0200, Sebastien Bacher wrote: > > > Le samedi 15 septembre 2007 à 18:19 -0400, Behdad Esfahbod a écrit : > > > > > > > Of course no project using git maintains ChangeLog. > > > > > > Why? You could update the ChangeLog when commiting changes on git > > > > what's the point? a ChangeLog is useful for people that do not have > > access to the repository and to the history of the project. if you clone > > a git repository you have the full history, with the ability to see each > > commit complete of a diff and a summary (this is also why listing all > > the functions that have been touched by the commit is pretty much > > useless). > > It should also be emphasized that maintaining a ChangeLog file under > version control *gets in the way* of branching and merging. That little > detail seems to ellude everyone's grasp, for some reason. > > Having a ChangeLog file under version control not only means that you > have to duplicate information in every commit (once in changelog, once > in commit log message), but also that you will almost always get > conflicts when merging branches. > > The ChangeLog therefore throws away one of the biggest advantages of > DSCM, which is not only offering decentralized source control, or very > fast commits, but also much more intelligent branching and merging when > compared to CVS or Subversion. I've never seen a merge conflict in a ChangeLog that wasnt /really/ easy to resolve - usually I just include both different portions unless I've been backporting fixes to a stable branch in which case some cherry picking is needed. ChangeLogs from my experience are always better than commit logs probably /because/ its a revisioned file; i.e. people care about the quality of the changelog, because they have to reffer to it when fixing bugs etc - its actually part of the product. Writing your changes to a file is a really simple task, but its a task none the less and IMO it should at least be a task, makeing things simpler than they already are could only result in carelessly written commit messages (i.e. that dont even include the files & functions that they effect etc.). I get my own spot of lazyness though ;-) I just copy paste my ChangeLog entry right into the commit log. Oh, and here's another point nobody mentioned about changelogs, when people who dont have access to commit to the repository (probably 50% of patches ?) - they should always include ChangeLog entries in thier patches :) Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Tomboy branched for GNOME 2.20
Tomboy has branched for GNOME 2.20. The branch is named gnome-2-20. The 0.8.0 release of Tomboy has been tagged from there and is being uploaded as we speak. The trunk is open for new development. Some plans for the new release cycle: * Complete Tasks add-in. * Implement awesome tagging UI. * A more "zen" note synchronization experience (thinking about automatic sync, sync based on tags, Online Desktop integration, etc) These plans are not final and everyone is welcome to participate in the Tomboy development process through the mailing list, wiki, and IRC channel. Cheers, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Seg, 2007-09-17 at 10:49 +0100, Emmanuele Bassi wrote: > On Mon, 2007-09-17 at 11:36 +0200, Sebastien Bacher wrote: > > Le samedi 15 septembre 2007 à 18:19 -0400, Behdad Esfahbod a écrit : > > > > > Of course no project using git maintains ChangeLog. > > > > Why? You could update the ChangeLog when commiting changes on git > > what's the point? a ChangeLog is useful for people that do not have > access to the repository and to the history of the project. if you clone > a git repository you have the full history, with the ability to see each > commit complete of a diff and a summary (this is also why listing all > the functions that have been touched by the commit is pretty much > useless). It should also be emphasized that maintaining a ChangeLog file under version control *gets in the way* of branching and merging. That little detail seems to ellude everyone's grasp, for some reason. Having a ChangeLog file under version control not only means that you have to duplicate information in every commit (once in changelog, once in commit log message), but also that you will almost always get conflicts when merging branches. The ChangeLog therefore throws away one of the biggest advantages of DSCM, which is not only offering decentralized source control, or very fast commits, but also much more intelligent branching and merging when compared to CVS or Subversion. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NetworkManager and nm-applet inconsistences in 2.20 jhbuild moduleset
On Sat, 2007-09-15 at 14:50 -0400, Claudio Saavedra wrote: > Hei, > > I don't know if it's just me, but I noticed today that building > network-manager-applet with jhbuild's 2.20 module set, NM from the 0.6.x > branch is grabbed and nm-applet is grabbed from trunk. > > Problem is that nm-applet from trunk requires NM from trunk (0.7.0) as > well, so nm-applet can't be built. > > Not sure how to fix this, so I raise it here. > you need to change it in jhbuild/modulesets/gnome-2.20.modules -- Rodrigo Moya <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
Hey, Callum McKenzie wrote: > For some modules, like gnome-applets or gnome-games, with lots of small > - loosely related - programs inside, the ChangeLog has a finer > granularity than the commit message. The ChangeLog provides a coherent > story for the sub-module - something the commit messages don't. In some > ways its a sign the repository is poorly arranged, but thats what we've > got. For some perspective, the OpenSolaris guys use very simple commit messages, but *all* commits contain a bug id which links to all the information you need. Very similar in many ways to a good detailed ChangeLog, but I'm very much of the either/or group - having nothing seems silly to me. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Mon, 2007-09-17 at 12:11 +0200, Sebastien Bacher wrote: > Le lundi 17 septembre 2007 à 10:49 +0100, Emmanuele Bassi a écrit : > > > generating a ChangeLog from the git log is something that should be done > > at release time, when you are preparing the tarball, as the users of the > > package have no access to the git repository history. > > looks like we don't have the same definition of maintaining a ChangeLog, > if you generate one from git when rolling a tarball that's good enough > for people using the tarballs yes, because - as I said - that's the only place where you actually *need* a ChangeLog (or a NEWS file, even though I still prefer to read ChangeLogs because they tend to be more verbose). if the SCM you're using preserves the entire history of the project under its own log system, and when you get the repository from the origin you also get the entire revision history (as is the case with bzr, hg and git, for instance) then having a file under revision control that tells you the exact same information (or less information, as it's the case with git) is of no use. with a distributed SCM, it can even be a source of conflicts when the maintainer is merging the work of different contributors, so is even less beneficial to the developers and the users checking out a project. in git's case from the log you can get the actual diff (and diffstat output) of a commit with a single command (or, if you're using giggle, which I strongly recommend, you'll get it together with the log) - which, in my book, beats a list of files and functions every day of the week and twice on Sundays. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
Le lundi 17 septembre 2007 à 10:49 +0100, Emmanuele Bassi a écrit : > generating a ChangeLog from the git log is something that should be done > at release time, when you are preparing the tarball, as the users of the > package have no access to the git repository history. looks like we don't have the same definition of maintaining a ChangeLog, if you generate one from git when rolling a tarball that's good enough for people using the tarballs Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Mon, 2007-09-17 at 11:36 +0200, Sebastien Bacher wrote: > Le samedi 15 septembre 2007 à 18:19 -0400, Behdad Esfahbod a écrit : > > > Of course no project using git maintains ChangeLog. > > Why? You could update the ChangeLog when commiting changes on git what's the point? a ChangeLog is useful for people that do not have access to the repository and to the history of the project. if you clone a git repository you have the full history, with the ability to see each commit complete of a diff and a summary (this is also why listing all the functions that have been touched by the commit is pretty much useless). generating a ChangeLog from the git log is something that should be done at release time, when you are preparing the tarball, as the users of the package have no access to the git repository history. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
Le samedi 15 septembre 2007 à 18:19 -0400, Behdad Esfahbod a écrit : > Of course no project using git maintains ChangeLog. Why? You could update the ChangeLog when commiting changes on git Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
Le dimanche 16 septembre 2007 à 09:42 +0200, Vincent Untz a écrit : > Le samedi 15 septembre 2007, à 21:44 -0400, Behdad Esfahbod a écrit : > > Ok, lets be fair: most people who care about hacking on GNOME already > > know git, why should other options be selected? > > I don't think it is fair to state this. A lot of people certainly care > about hacking on GNOME and don't know git (and don't care about it). I think Vincent is right there, looks like some people are using git and trying to make it look like that's the case for everybody else in the GNOME world which is not correct Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Sun, 2007-09-16 at 18:44 -0400, Havoc Pennington wrote: > Hi, > > On 9/15/07, Jaap Haitsma <[EMAIL PROTECTED]> wrote: > > Talking to Daniel "Cheese" Siegel we asked ourselves: > > Why do all GNOME projects have a ChangeLog file? > > Isn't it redundant when you just save a commit message. > > > For some modules, like gnome-applets or gnome-games, with lots of small - loosely related - programs inside, the ChangeLog has a finer granularity than the commit message. The ChangeLog provides a coherent story for the sub-module - something the commit messages don't. In some ways its a sign the repository is poorly arranged, but thats what we've got. - Callum ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
LIBGAIL-GNOME branched for 2.20
Hi, LIBGAIL-GNOME has been branched for GNOME 2.20 with the release of 1.20.0. LIBGAIL-GNOME 1.20.0 sources represent the beginning of the branch (svn.gnome.org/svn/libgail-gnome/branches/gnome-2-20). Now we will focus on TRUNK for the new features development. Thanks, Li ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
AT-SPI branched for 2.20
Hi, AT-SPI has been branched for GNOME 2.20 with the release of 1.20.0. AT-SPI 1.20.0 sources represent the beginning of the branch (svn.gnome.org/svn/at-spi/branches/gnome-2-20). Now we will focus on TRUNK for the new features development. Thanks, Li ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GAIL branched for 2.20
Hi, GAIL has been branched for GNOME 2.20 with the release of 1.20.0. GAIL 1.20.0 sources represent the beginning of the branch (svn.gnome.org/svn/gail/branches/gnome-2-20). Now we will focus on TRUNK for the new features development. Thanks, Li ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
ATK branched for 2.20
Hi, ATK has been branched for GNOME 2.20 with the release of 1.20.0. ATK 1.20.0 sources represent the beginning of the branch (svn.gnome.org/svn/atk/branches/gnome-2-20). Now we will focus on TRUNK for the new features development. Thanks, Li ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
evolution-jescs branched for gnome 2.20
Hi, Evolution-jescs has been branched for GNOME 2.20. The new branch is gnome-2-20. The new version is 2.12.0 and it is branched from 2.11.2. There are no additional fixes in HEAD. -- Regards, Jedy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Sun, 2007-09-16 at 18:44 -0400, Havoc Pennington wrote: > Hi, > > On 9/15/07, Jaap Haitsma <[EMAIL PROTECTED]> wrote: > > Talking to Daniel "Cheese" Siegel we asked ourselves: > > Why do all GNOME projects have a ChangeLog file? > > Isn't it redundant when you just save a commit message. > > > > When I've seen projects just dump CVS or SVN log to ChangeLog, > typically the resulting ChangeLog sucked badly; most commit messages > are not very good, while ChangeLog entries frequently are. Why the > difference? Who knows. It is a real difference whether there's a > logical reason for it or not though. > > (For me I think the difference is that I do the ChangeLog in Emacs > with 'C-x 4 a' and I do the commit message with VISUAL=vi, so for > projects where we don't bother with ChangeLog my commit messages are > junky. I don't know why it happens for other people.) > > People say git helps with this, though I admit I don't see how (for me > at least) the bad commit messages vs. nice ChangeLog entries are > related to the SCM system, since my best guess at why my no-ChangeLog > commit messages are junk is the difference in editor. > > The log for Cairo looks pretty good for example so clearly the > "autogenerate" approach works for someone: > http://gitweb.freedesktop.org/?p=cairo;a=log For me, even the Cairo ChangeLog isn't good enough because it doesn't mention the files or functions that were changed and why. No tool can generate that information from the commit history. A system that encouraged people to write the ChangeLog before committing would improve ChangeLogs. > Perhaps it just comes down to the maintainer being a hardass about > commit message quality in the same way they might be about ChangeLog > entries. I think Carl summarized it that way at GUADEC. > > I don't agree that the purpose of ChangeLog (with svn at least) is > offline access, though. The reason I use it in my projects is that > when people don't use it, specifically when I don't, the quality of > the log suffers. (For my projects I always just cut-and-paste from > ChangeLog to the commit message.) > > I guess the summary is, the focus should be on whether people write > good change history messages, and maintainers should probably feel > free to use any mechanism that works for them for that. But as soon as > messages start to be useless, like "fixed stuff," "hacked on foo.c," > it's a problem no matter what technology is used to save the messages. -- [EMAIL PROTECTED] 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
java-access-bridge branched for 2.20
Hi java-access-bridge has been branched for 2.20. The branch is gnome-2-20. This branch, java-access-bridge 1.20, is branched from java-access-bridge 1.19.2 and there are no additional fixes in HEAD. -- Regards Jeff ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
