On Jul 10, 2009, at 3:55 PM, Maciej Stachowiak wrote:
Hi everyone,
One common topic for discussion has been how to make our process
around patch submission better. As the project grows, it's becoming
more important for this process to work really smoothly, and we are
seeing some breakdowns. I've been doing a lot of thinking about
this, and discussion with some project old hands. I think the right
way to tackle this is to identify the process problems, and make
sure we address each one. I'd also like to start by fixing the
problems that can be addressed without making major wholesale tools
changes first, then look at the bigger changes. Here are my thoughts
on the steps in the lifecycle of a patch:
=== 1) Submitting the patch ===
Steps:
1.1) File a bug if there isn't one already.
1.2) Put the bug number in your ChangeLog entry.
Maybe it's because I'm a noob and there is a better way, but one of
the most annoying things about the patch process is the need to add
Changelog entries. It's not hard to create a Changelog entry (given
the existance of prepareChangelog). The annoying part is the fact that
I ALWAYS get conflicts in at least one Changelog file when I try to
check in. I have to fix these by hand, do svn resolved, and try to
check in again. Assuming someone hasn't checked something in under me
in the 2 minutes it took me to fix the changelogs, (which has happened
a couple of times), I can successfully commit.
This isn't THAT big of a deal, but it is annoying. And I'm not sure
why we need changelogs when we have a complete log of every checkin
from svn anyway? Maybe it would be better to do away with Changelogs
and just put stricter controls on what's in a commit message.
-----
~Chris
cmar...@apple.com
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
