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

[Maciej Stachowiak]

Hi Luke,

I think your webkit-dev emails are becoming disruptive. Sending  
profanity-laced walls of text is not an appropriate use of this list.  
Please find a way to communicate without annoying the rest of the  
list, or I will ask the list administrators to "censor" you from the  
mailing list for the period of at least a week.

Regards,
Maciej

On Jul 12, 2009, at 10:47 PM, Luke Kenneth Casson Leighton 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.
>
> well, this is interesting - some good timing on sending this message.
> i believe it would be reasonable to say that regarding #16401,  
> "breakdown"
> would be an understatement of the first order.
>
>> 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.
>
> yes.
>
> perhaps, as i have been on the receiving end of some quite shit and
> unnecessary treatment, i can help give some insights here.
>
> 1) there is no charter for webkit.
>
> one absolutely vital thing which prevents problems is to have a
> charter which outlines, up-front, the expectations and development
> of the project.
>
> the apache foundation charter states clearly that:
>
> * "developers shall treat each other with mutual respect".
>
> * "contributions shall be considered on technical merit"
>
> for the freedce foundation, after the samba fiasco in which continuous
> goal-post moving and technical bullying was utilised to make  
> significant
> technical contributions - and their contributors - look like shit, we
> modified this to:
>
> * "contributions shall be considered on strategic technical merit"
>
> providing a charter clearly outlines an encouraging environment,
> and also allows you to gently - or forcefully - bring people back
> into line.
>
> in the case of webkit, then, a charter containing these vital
> guidelines would have stopped the disrespectful treatment i got
> absolutely dead in its tracks.  if a free software developer says,
> "no, i am a free software _contributor_, not a paid-up employee
> whom you can [effectively] _demand_ [sponge off].  i don't have time  
> or
> money to give more than i have to get this issue dealt with",
> it xxxxing well means "no, you can't ask for more than i've already
> gifted to this project", and the people who were asking should,
> instead of getting stroppy, go "oh - sorry, i apologise for that!
> i didn't mean in any way to .... etc." and generally indicate
> gratitude for, and respect for, the contributions made.
>
> read the comments on #16401 bearing in mind that they are _free_
> and _unpaid_ contributions (not funded by any company or sponsor),
> and watch the breakdown in the conversation due to assumptions made
> by apple paid-up employees - it's very interesting reading.
>
> 2) there are no branches
>
> the KDE development process has what, over a hundred contributors.
> they don't step on each others' toes.  why?  because the committers
> are allowed to create branches.
>
> a branch, with relaxed conditions, allows people to collaborate
> BEFORE quotes landing quotes and still feel like they are part of
> the project.
>
> take the #16401 work as a classic example: with over 5,000 lines,
> not one of the groups of contributors could "officially" collaborate
> on improvements because the contributors had no central "official"
> place in which to collaborate, to meet the over-strict and far too
> time-consuming "review" requirements.
>
> also, if you look around, there are one hell of a lot of unofficial
> branches of webkit.  i found _yet another one_ recently, this time by
> intel, as part of their 3D desktop project!
>
> intel should never have felt it necessary to create a separate
> repository: they should have been _invited_ to have commit rights.
>
> there are plenty of scripts out there that can protect commits to
> branches etc.  so the main trunk can be protected.
>
> 3) the review process is hostile and confrontational.
>
> it even says, up-front, "this process may seem daunting".
> that's got to stop.  i would not be surprised if the confrontational
> approach is a hang-over from internal apple development ethos.
>
> it doesn't work in the free software world: if you're going to state,
> up-front, "we're going to be tough on you", then potential  
> contributors
> will just say "sod you, then" and walk away.
>
> 4) automation of coding standards checking
>
> this is trivial to do.  hindent immediately springs to mind.
> it could even be added as a commit hook to trunk (leaving branches
> alone of course).
>
> 5) assumptions that people know where to read about webkit standards
>    and processes
>
> there seems to be an assumption that people know all about webkit's
> "standards", and irritation and in some cases outright hostility when
> people with enthusiasm and the willingness to contribute simply are
> not aware of these "standards".
> 5) assumptions that people know where to read about webkit standards
>    and processes
>
> there seems to be an assumption that people know all about webkit's
> "standards", and irritation and in some cases outright hostility when
> people with enthusiasm and the willingness to contribute simply are
> not aware of these "standards".
>
> why _should_ they be?  where in the world is it made clear?
> how do contributors find _out_ that there are these standards and
> processes?
>
> both i _and_ adam, in contributing to #16401, had absolutely no idea
> about the "review" process.  absolutely not a damn clue.
>
> so we both sat there wondering why the bloody hell nobody from
> apple was looking at the patch, and nobody bothered to tell us,
> either.
>
> in the case of #16401, due to the size that the patch had to become
> in order to do even the most basic of testing, that led to some
> problems [understatement].  the time to _catch_ those problems was
> wayyyy back at the beginning of the development process, and it was  
> far
> too late to catch them, even a few weeks on, and it's thanks to nobody
> explaining what "review" is.
>
>
> overall, then, the "patch" process is only half the story.  it's the
> support _behind_ the patch process that's far more important, and key
> to that support infrastructure is to have respect for the abilities
> and the available resources of contributors, and to trust the
> contributors to commit [their resources, time and abilities] to the
> project.
>
> if you look carefully at everything i've said, you will see that my
> comments are a mixture of indicating respect for the reviewers'
> technical ability and contributions whilst also absolutely _not_
> letting them get off the hook for stepping over the line, and saying
> so in no uncertain terms.
>
> from experience, i know that when i say things to projects (that
> people don't like), they can get _really_ stroppy about it, and do
> stupid things like censor me from mailing lists.
>
> yet, six months to six years down the line, i do a periodic check, and
> i find that *other people* are still complaining about exactly the
> same issues that i'd raised.
>
> so - with me, you get an "advance warning".  a litmus test, so to  
> speak.
>
> bottom line: look at #16401, and _learn_ from it.
>
> l.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev