On Jul 10, 2009, at 4:17 PM, Chris Marrin wrote:
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.
The resolve-ChangeLogs script will fix it for you automatically.
Perhaps we should make update-webkit (or some new wrapper type tool)
run resolve-ChangeLogs automatically.
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.
This has already been discussed to death in the recent thread on
prepare-ChangeLog. I think for now we should focus on removing the
pain points of maintaining ChangeLogs, and switch away when/if we have
a truly viable alternative that works with our process. I believe any
minor annoyances with ChangeLog maintenance are solvable.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
