[webkit-dev] Patch process - let's make it better

[Maciej Stachowiak]

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