I was reading through the old "I HATE CHANGELOGS" messages from August:
https://lists.webkit.org/pipermail/webkit-dev/2009-August/thread.html The discussion attracted a lot of interest and ideas, but it looks like it died out without reaching any conclusion. It seems like the tools around ChangeLogs have improved somewhat since then, but we still have, for example, the fundamental conflict-on-commit annoyance. What do people think about these two possibilities for short- and mid-term strategies, respectively? (1) Provide a simple wrapper around "svn commit" and "git svn dcommit" that encapsulates the retry logic in case of ChangeLog conflicts. This way, the end-user will never have to resolve ChangeLog conflicts on commit. Higher-level commands like webkit-patch could use this under the hood, if they wanted, to cope with race conditions. (2) Consider phasing in support for an alternate workflow where new ChangeLog entries for the next commit are stored separately from the versioned ChangeLog files -- perhaps in individual .changelog files for Subversion users and in the commit message for Git users. The commands in (1) would be smart enough to read the new ChangeLog information from these alternate locations, and then add the ChangeLog information to the ChangeLog files at the last moment -- prior to commit. Users of this workflow would never have to resolve ChangeLog conflicts during the review process, since new entries are stored separately. It may be easiest to support this new workflow for Git users first. The second idea is essentially Ojan's proposed modification of one of Maciej's ideas: https://lists.webkit.org/pipermail/webkit-dev/2009-August/009708.html It is a mid-term rather than short-term strategy since it involves changes to several scripts (e.g. svn-create-patch) to allow the review process to support this alternate workflow. --Chris _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
