Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Wed, 2009-08-26 at 17:38 -0700, Geoffrey Garen wrote:
[This question not necessarily just for Peter:]
If we removed the discipline of reviewing ChangeLogs, and the tools
that autogenerate a ChangeLog template and check for a ChangeLog entry
without an OOPs I didn't get this reviewed message, what would we
replace them with?
You can include the commit message to the patch nevertheless. That's
what git format-patch does, for instance. I am attaching an example.
See you,
--
Gustavo Noronha Silva g...@gnome.org
GNOME
From 04a4fd6c2a0f59c990162fcbac6607d50240dc38 Mon Sep 17 00:00:00 2001
From: jmalo...@webkit.org jmalo...@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc
Date: Fri, 28 Aug 2009 15:12:29 +
Subject: [PATCH] 2009-08-28 Jan Michael Alonzo jmalo...@webkit.org
Reviewed by Gustavo Noronha and Xan Lopez.
[Gtk] Add view source mode API
https://bugs.webkit.org/show_bug.cgi?id=28805
Implement setter and getter for view source mode.
* webkit/webkitwebview.cpp:
(webkit_web_view_set_view_source_mode):
(webkit_web_frame_get_view_source_mode):
* webkit/webkitwebview.h:
git-svn-id: http://svn.webkit.org/repository/webkit/tr...@47865 268f45cc-cd09-0410-ab3c-d52691b4dbfc
---
WebKit/gtk/ChangeLog| 14
WebKit/gtk/webkit/webkitwebview.cpp | 38 +++
WebKit/gtk/webkit/webkitwebview.h |7 ++
3 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/WebKit/gtk/ChangeLog b/WebKit/gtk/ChangeLog
index 4d64cc8..da5a432 100644
--- a/WebKit/gtk/ChangeLog
+++ b/WebKit/gtk/ChangeLog
@@ -1,3 +1,17 @@
+2009-08-28 Jan Michael Alonzo jmalo...@webkit.org
+
+Reviewed by Gustavo Noronha and Xan Lopez.
+
+[Gtk] Add view source mode API
+https://bugs.webkit.org/show_bug.cgi?id=28805
+
+Implement setter and getter for view source mode.
+
+* webkit/webkitwebview.cpp:
+(webkit_web_view_set_view_source_mode):
+(webkit_web_frame_get_view_source_mode):
+* webkit/webkitwebview.h:
+
2009-08-26 Xan Lopez xlo...@igalia.com
Reviewed by Gustavo Noronha.
diff --git a/WebKit/gtk/webkit/webkitwebview.cpp b/WebKit/gtk/webkit/webkitwebview.cpp
index ae0b45f..8d0f08b 100644
--- a/WebKit/gtk/webkit/webkitwebview.cpp
+++ b/WebKit/gtk/webkit/webkitwebview.cpp
@@ -3733,3 +3733,41 @@ void webkit_web_view_redo(WebKitWebView* webView)
if (webkit_web_view_can_redo(webView))
g_signal_emit(webView, webkit_web_view_signals[REDO], 0);
}
+
+
+/**
+ * webkit_web_view_set_view_source_mode:
+ * @web_view: a #WebKitWebView
+ * @view_source_mode: the mode to turn on or off view source mode
+ *
+ * Set whether the view should be in view source mode. Setting this mode to
+ * %TRUE before loading a URI will display the source of the web page in a
+ * nice and readable format.
+ *
+ * Since: 1.1.14
+ */
+void webkit_web_view_set_view_source_mode (WebKitWebView* webView, gboolean mode)
+{
+g_return_if_fail(WEBKIT_IS_WEB_VIEW(webView));
+
+if (Frame* mainFrame = core(webView)-mainFrame())
+mainFrame-setInViewSourceMode(mode);
+}
+
+/**
+ * webkit_web_view_get_view_source_mode:
+ * @web_view: a #WebKitWebView
+ *
+ * Return value: %TRUE if @web_view is in view source mode, %FALSE otherwise.
+ *
+ * Since: 1.1.14
+ */
+gboolean webkit_web_view_get_view_source_mode (WebKitWebView* webView)
+{
+g_return_val_if_fail(WEBKIT_IS_WEB_VIEW(webView), FALSE);
+
+if (Frame* mainFrame = core(webView)-mainFrame())
+return mainFrame-inViewSourceMode();
+
+return FALSE;
+}
diff --git a/WebKit/gtk/webkit/webkitwebview.h b/WebKit/gtk/webkit/webkitwebview.h
index 42736dc..968b74e 100644
--- a/WebKit/gtk/webkit/webkitwebview.h
+++ b/WebKit/gtk/webkit/webkitwebview.h
@@ -356,6 +356,13 @@ webkit_web_view_redo(WebKitWebView*webView);
WEBKIT_API gboolean
webkit_web_view_can_redo(WebKitWebView*webView);
+WEBKIT_API void
+webkit_web_view_set_view_source_mode(WebKitWebView*web_view,
+ gboolean view_source_mode);
+
+WEBKIT_API gboolean
+webkit_web_view_get_view_source_mode(WebKitWebView*web_view);
+
G_END_DECLS
#endif
--
1.6.3.3
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Fri, Aug 28, 2009 at 12:26 PM, Brady Eidson beid...@apple.com wrote: On Aug 28, 2009, at 12:18 PM, George Staikos wrote: On 26-Aug-09, at 2:44 PM, Maciej Stachowiak wrote: On Aug 26, 2009, at 5:38 PM, Geoffrey Garen wrote: Detailed descriptions, bug links, test instructions, and a link back to the entire original review history are all part of Chromium commits, yet we don't use ChangeLogs. I think discipline about what to include + tooling to support it are orthogonal to a project's use of a ChangeLog as the mechanism for conveying this information. [This question not necessarily just for Peter:] If we removed the discipline of reviewing ChangeLogs, and the tools that autogenerate a ChangeLog template and check for a ChangeLog entry without an OOPs I didn't get this reviewed message, what would we replace them with? I can imagine a discipline where we ensure that pending commit entries sit in a designated file in your tree, are made by a tool much like prepare-ChangeLog, are included in patches by svn-create-patch, are applied by svn-apply-patch, and are used by commit-log-editor. That would ensure the entries go through the patch life cycle just as much as currently. Another possibility is to have a review site (bugzilla?) be the canonical place for log entries until they get committed. At commit time, a tool would pull from this location. I want to add a +1 for the hate changelogs group. I have been advocating this for about 4 years now. It's much more painful when on a remote, slow link. Is it really a problem to generate the ChangeLog files from the svn commit messages on a daily or weekly basis? There are scripts for this. This is an interesting idea. Mark Rowe already pointed out - doing an automated step for each checkin that causes another checkin would be ridiculous. But how about a nightly script that checks in a ChangeLog accounting for the day's commits? Seems reasonable to me. +1 +1 Agreed. If it's done daily, Trac would be a good way to look at what's happened very recently. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Friday, August 28, 2009 at 1:05:57 PM, Jeremy Orlow wrote: On Fri, Aug 28, 2009 at 12:26 PM, Brady Eidson wrote: Mark Rowe already pointed out - doing an automated step for each checkin that causes another checkin would be ridiculous. But how about a nightly script that checks in a ChangeLog accounting for the day's commits? Agreed. If it's done daily, Trac would be a good way to look at what's happened very recently. This would make it impossible to track a single ChangeLog entry back to the original commit using git/svn annotate/blame, but the new process could add the commit revision to each ChangeLog entry automatically when it generates the update, thus achieving some level of ChangeLog-nirvana. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Aug 28, 2009, at 1:15 PM, David Kilzer wrote: On Friday, August 28, 2009 at 1:05:57 PM, Jeremy Orlow wrote: On Fri, Aug 28, 2009 at 12:26 PM, Brady Eidson wrote: Mark Rowe already pointed out - doing an automated step for each checkin that causes another checkin would be ridiculous. But how about a nightly script that checks in a ChangeLog accounting for the day's commits? Agreed. If it's done daily, Trac would be a good way to look at what's happened very recently. This would make it impossible to track a single ChangeLog entry back to the original commit using git/svn annotate/blame, but the new process could add the commit revision to each ChangeLog entry automatically when it generates the update, thus achieving some level of ChangeLog-nirvana. I would argue this is a *progression* from the current system, not having to dig into `svn blame` or trac or whatever to find a revision number. ~Brady Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Fri, Aug 28, 2009 at 1:18 PM, Brady Eidson beid...@apple.com wrote: On Aug 28, 2009, at 1:15 PM, David Kilzer wrote: On Friday, August 28, 2009 at 1:05:57 PM, Jeremy Orlow wrote: On Fri, Aug 28, 2009 at 12:26 PM, Brady Eidson wrote: Mark Rowe already pointed out - doing an automated step for each checkin that causes another checkin would be ridiculous. But how about a nightly script that checks in a ChangeLog accounting for the day's commits? Agreed. If it's done daily, Trac would be a good way to look at what's happened very recently. This would make it impossible to track a single ChangeLog entry back to the original commit using git/svn annotate/blame, but the new process could add the commit revision to each ChangeLog entry automatically when it generates the update, thus achieving some level of ChangeLog-nirvana. Does anyone actually have any objections to Maciej's proposal? I can imagine a discipline where we ensure that pending commit entries sit in a designated file in your tree, are made by a tool much like prepare-ChangeLog, are included in patches by svn-create-patch, are applied by svn-apply-patch, and are used by commit-log-editor. That would ensure the entries go through the patch life cycle just as much as currently. Slightly more concrete. prepare-ChangeLog is modified to create a .changelog file in the root of your checkout. Then svn-create-patch, svn-apply-patch and commit-log-editor all use the .changelog file to prepend your change description to the actual ChangeLog file before doing their thing. Are there any downsides to that proposal? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Fri, Aug 28, 2009 at 1:37 PM, Ojan Vafaio...@chromium.org wrote: Does anyone actually have any objections to Maciej's proposal? I can imagine a discipline where we ensure that pending commit entries sit in a designated file in your tree, are made by a tool much like prepare-ChangeLog, are included in patches by svn-create-patch, are applied by svn-apply-patch, and are used by commit-log-editor. That would ensure the entries go through the patch life cycle just as much as currently. Slightly more concrete. prepare-ChangeLog is modified to create a .changelog file in the root of your checkout. Then svn-create-patch, svn-apply-patch and commit-log-editor all use the .changelog file to prepend your change description to the actual ChangeLog file before doing their thing. Are there any downsides to that proposal? Ojan You'd probably still want to do an explicit 'svn update' on the changelogs immediately prior to prepending them, to minimize the window for a commit race, but it's probably good enough in most cases. Assuming there is no way to get an atomic prepend, of course. I much prefer this approach to the roll the changelog once a day approach. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Aug 26, 2009, at 3:43 PM, Maciej Stachowiak wrote: On Aug 26, 2009, at 3:37 PM, David Hyatt wrote: If the files could just merge properly, I would not be so annoyed, but the fact that you basically have to re-resolve conflicts every time anyone beats you to a checkin is just horrible. Surely other people run into this. It wastes time for me on practically every single checkin and I have ended up causing regressions because I don't wait to re-run layout tests every time just because I am trying to get my files landed before someone else modified the ChangeLog again. If you use update-webkit it should merge the ChangeLog for you, or if you use vanilla svn update, resolve-ChangeLogs should fix up the conflicts. Do these not work for you? No, they really don't. update-webkit is very heavyweight when you are mostly working in one particular area. I don't necessarily want to rebuild the whole world just because I wrote a 2-line patch to one file in WebCore. I don't need to test how that patch interacts with every other new change made since I last wrote the patch, so telling me I have to fully update to ToT is lame. Remember also that update-webkit pulls the internal Safari tree for Apple folks as well, so that makes it even more heavyweight. I certainly don't need all the random Safari UI changes for the day just because I want to land a WebCore patch. So assuming I don't update-webkit every single time I want to write a ChangeLog, I end up having to run resolve-Changelogs myself. The other annoyance is that I have essentially a single checkin comment that I have to duplicate across N changelogs. Even the most minimal patch forces me to touch two ChangeLogs and say the exact same thing in both. This is a pain. Some WebKit refactoring changes I've made in the past have forced me to touch as many as SEVEN(!!!) ChangeLogs just to check in. This is just nuts. On top of that, resolve-Changelogs often fails on the LayoutTests changelog, and you have to svn resolve manually. Even before you get to the conflict state, ChangeLogs can merge cleanly forcing you to then hand edit them to move your entry up to the top of the file. I've literally had situations where I get conflicts worked out, make the 2-3 changes a reviewer demands, run layout tests, and then someone else beats me to a checkin. I don't necessarily want to pull that person's checkin just to land (maybe they touched Vector.h or something). I just want to get my patch in. A model where I am forced to keep re-syncing up to a rapidly changing ToT is not a good one, especially when I know my change is simple and self-contained. On top of that sometimes the ChangeLog merges cleanly but puts your entry underneath others, and then you have to open the file and move your entry back to the top. Sometimes I have not noticed this and then I land with someone else's commit message. I just don't get why people are willing to put up with this. It's really driving me crazy. The above make it tolerable for me, but if it's really unlivable, we can consider some other way to do this. One possibility is to have a commit hook that builds the ChangeLog entry and includes it in the commit atomically - that way there are no races. I really consider it intolerable. This has been bugging me for a long time, and hearing others complain about it (and running into it yet again) has motivated me to say something. :) Having to edit seven changelogs to put the same message in each just to be able to land a patch is stupid. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On 2009-08-26, at 15:43, Maciej Stachowiak wrote: On top of that sometimes the ChangeLog merges cleanly but puts your entry underneath others, and then you have to open the file and move your entry back to the top. Sometimes I have not noticed this and then I land with someone else's commit message. I just don't get why people are willing to put up with this. It's really driving me crazy. One possibility is to have a commit hook that builds the ChangeLog entry and includes it in the commit atomically - that way there are no races. Hooks in Subversion cannot mutate the transaction that is taking place so I don't think this is an option. - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Aug 27, 2009, at 12:26 AM, David Hyatt wrote: They need to die. +1. Pierre. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Aug 26, 2009, at 3:26 PM, David Hyatt wrote: What purpose do these stupid files even serve at this point? I don’t like writing change log entries. But unlike you I have no problems merging them. The update-webkit script usually works for me, although I find it really irritating that I can’t use it on a single directory. I don’t think the multiple change logs inside the WebKit directory make sense for my use. I typically write cross-platform code so I end up modifying many directories at once. I’d be happier if there was only one. I love reading change logs, though. I do this roughly once a week all year long. I try looking at trac or svn blame first, but typically I am unable to find the change I am looking for this way. Then, the ChangeLog files, my good friends, invariably work for finding the change by searching for key words or function names. I get lots of history about the bug, including bug numbers that point me at bugs.webkit.org and even Apple’s internal Radar. And I often use the date to follow up reading the change in trac. On the projects I’ve worked on with more low key change description disciplines, I find that check-in comments or their equivalents are vague, and missing critical information like the name of the reviewer, whether the code is tested, the nature of the bug being fixed, and the nature of the fix. I agree that in theory we could find a different way of doing the project that still encourages people to communicate these things, but I am skeptical. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Aug 26, 2009, at 4:20 PM, Mark Rowe wrote: On 2009-08-26, at 15:43, Maciej Stachowiak wrote: On top of that sometimes the ChangeLog merges cleanly but puts your entry underneath others, and then you have to open the file and move your entry back to the top. Sometimes I have not noticed this and then I land with someone else's commit message. I just don't get why people are willing to put up with this. It's really driving me crazy. One possibility is to have a commit hook that builds the ChangeLog entry and includes it in the commit atomically - that way there are no races. Hooks in Subversion cannot mutate the transaction that is taking place so I don't think this is an option. Is there any sort of guarantee that a post commit hook for revision N will complete before the post commit hook for revision N + 1 executes? Couldn't that accomplish this? ~Brady - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On 2009-08-26, at 17:19, Brady Eidson wrote: On Aug 26, 2009, at 4:20 PM, Mark Rowe wrote: On 2009-08-26, at 15:43, Maciej Stachowiak wrote: On top of that sometimes the ChangeLog merges cleanly but puts your entry underneath others, and then you have to open the file and move your entry back to the top. Sometimes I have not noticed this and then I land with someone else's commit message. I just don't get why people are willing to put up with this. It's really driving me crazy. One possibility is to have a commit hook that builds the ChangeLog entry and includes it in the commit atomically - that way there are no races. Hooks in Subversion cannot mutate the transaction that is taking place so I don't think this is an option. Is there any sort of guarantee that a post commit hook for revision N will complete before the post commit hook for revision N + 1 executes? Couldn't that accomplish this? Generating two SVN revisions for each change would be awful. - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
Detailed descriptions, bug links, test instructions, and a link back to the entire original review history are all part of Chromium commits, yet we don't use ChangeLogs. I think discipline about what to include + tooling to support it are orthogonal to a project's use of a ChangeLog as the mechanism for conveying this information. [This question not necessarily just for Peter:] If we removed the discipline of reviewing ChangeLogs, and the tools that autogenerate a ChangeLog template and check for a ChangeLog entry without an OOPs I didn't get this reviewed message, what would we replace them with? Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On 2009-08-26, at 17:29, Brady Eidson wrote: On Aug 26, 2009, at 5:26 PM, Mark Rowe wrote: On 2009-08-26, at 17:19, Brady Eidson wrote: On Aug 26, 2009, at 4:20 PM, Mark Rowe wrote: On 2009-08-26, at 15:43, Maciej Stachowiak wrote: On top of that sometimes the ChangeLog merges cleanly but puts your entry underneath others, and then you have to open the file and move your entry back to the top. Sometimes I have not noticed this and then I land with someone else's commit message. I just don't get why people are willing to put up with this. It's really driving me crazy. One possibility is to have a commit hook that builds the ChangeLog entry and includes it in the commit atomically - that way there are no races. Hooks in Subversion cannot mutate the transaction that is taking place so I don't think this is an option. Is there any sort of guarantee that a post commit hook for revision N will complete before the post commit hook for revision N + 1 executes? Couldn't that accomplish this? Generating two SVN revisions for each change would be awful. And - I honestly don't know the answer to this - there's actually *NO* way to alter a previous commit in SVN, even when you have full access to the server? It may be doable through some amount of hackery, but it wouldn't be a good idea. For example, let's assume that I made a commit that the server recorded as r35000. If r35000 was somehow rewritten to include modifications to ChangeLogs then suddenly the view of r35000 in my working copy differs from the view of anyone else looking at the repository. For this to be a workaround solution Subversion would need the ability to allow a pre-commit hook to modify the transaction that is currently underway, and to be able to push any modifications made back to the committer. (I ask this with the risk of you bringing up GIT, and me smacking you upside the head for the non-helpful suggestion in getting SVN to work better for us) ;) There's no need to be such a git about it ;-) I have no interest in pushing Git on other people working on WebKit. It works well for my uses, but I can easily see why the vastly different model, complexity of interface, etc. make some people balk at the idea of using it. - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Aug 26, 2009, at 5:38 PM, Geoffrey Garen wrote: Detailed descriptions, bug links, test instructions, and a link back to the entire original review history are all part of Chromium commits, yet we don't use ChangeLogs. I think discipline about what to include + tooling to support it are orthogonal to a project's use of a ChangeLog as the mechanism for conveying this information. [This question not necessarily just for Peter:] If we removed the discipline of reviewing ChangeLogs, and the tools that autogenerate a ChangeLog template and check for a ChangeLog entry without an OOPs I didn't get this reviewed message, what would we replace them with? I can imagine a discipline where we ensure that pending commit entries sit in a designated file in your tree, are made by a tool much like prepare-ChangeLog, are included in patches by svn-create-patch, are applied by svn-apply-patch, and are used by commit-log-editor. That would ensure the entries go through the patch life cycle just as much as currently. Another possibility is to have a review site (bugzilla?) be the canonical place for log entries until they get committed. At commit time, a tool would pull from this location. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Wed, Aug 26, 2009 at 5:44 PM, Maciej Stachowiak m...@apple.com wrote: Another possibility is to have a review site (bugzilla?) be the canonical place for log entries until they get committed. At commit time, a tool would pull from this location. This is probably the closest analog to how the Chromium disciplines are concretely implemented. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
Arguably a text file is the simplest and most reliable way to keep a log over time and across tools and platforms. Things happen to databases (bugzilla!) more often then to plain text files. It seems there are ways to reduce the merging hassle using better tools/process. +1 to having a single ChangeLog though! Also, this can be done independently from other improvements. Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
Hey ALL, I was wondering, is there list of known issues with CSS 2.1/3 support under webkit? Is there a test suite that I can run against WebKit? Thanks in advance, -Conrad ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Aug 26, 2009, at 6:14 PM, Dmitry Titov wrote: Arguably a text file is the simplest and most reliable way to keep a log over time and across tools and platforms. Things happen to databases (bugzilla!) more often then to plain text files. It seems there are ways to reduce the merging hassle using better tools/ process. +1 to having a single ChangeLog though! Also, this can be done independently from other improvements. I'm largely ambivalent to this whole thing - I find ChangeLogs useful, but they also annoy me greatly when they conflict. So to play devils advocate to your suggestion, if we shifted from the many ChangeLogs we have now to a single ChangeLog, we'd be *increasing* the chance that your check-in will run in to a ChangeLog conflict. ~Brady Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
