Re: [webkit-dev] Patch process - let's make it better
On Friday 10 July 2009 06:55:59 pm Maciej Stachowiak wrote: * Phase 1 * A) Make it really easy to submit a patch. Eric's bugzilla-tool is close to being there. I'm going to help him refine this tool to the point that submitting a patch has only one step - a single command will make the patch, file a bug if needed, attach the patch to the bug, and flag it for review. B) Make it really easy to commit a patch. Again, I think bugzilla-tool is the right path to achieving this. C) Improve the way we get attention from reviewers. I think we should do three things here: C.1) Split review queues, based on our emerging [Bracket] convention for patches needing specialized review. If we find more areas of specialty besides ports, we can add new [Bracket] tags. C.2) Improve the quality of emails sent C.3) Highlight in a special way patches that have been waiting for review longer that some minimum period (a week?). These could be highlighted visually in the review queue, and maybe would send extra review request emails automatically. Speaking of your action plan... I've had a look at C.3 and was going to try to modify the bugzilla tools to highlight as you suggested. But after looking at the review queue over the last few days I'm not sure it is necessary or that it would help to fix the problem. http://www.webkit.org/pending-review The page above already lists the review queue sorted by date. Over the last few days the queue has numbered in the 100's. A significant fraction (50%+) are older than a week. I could highlight them, but if it is already ordered by date and the highlight will encompass more than half the queue... what's the point? Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Wed, Jul 15, 2009 at 1:14 PM, Adam Treat tr...@kde.org wrote: http://www.webkit.org/pending-review The page above already lists the review queue sorted by date. Over the last few days the queue has numbered in the 100's. A significant fraction (50%+) are older than a week. I could highlight them, but if it is already ordered by date and the highlight will encompass more than half the queue... what's the point? I think it would still be effective as it provides a concrete measure of success in getting reviews completed in a timely manner. Having such a highlighting would hopefully provide the motivation to change the fact that half the queue would be highlighted. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
I'll try to get bugs filed for any part of the plan that isn't done by tomorrow, and I'll tag them with a keyword so we can track progress. On Jul 15, 2009, at 1:14 PM, Adam Treat wrote: On Friday 10 July 2009 06:55:59 pm Maciej Stachowiak wrote: * Phase 1 * A) Make it really easy to submit a patch. Eric's bugzilla-tool is close to being there. I'm going to help him refine this tool to the point that submitting a patch has only one step - a single command will make the patch, file a bug if needed, attach the patch to the bug, and flag it for review. B) Make it really easy to commit a patch. Again, I think bugzilla- tool is the right path to achieving this. C) Improve the way we get attention from reviewers. I think we should do three things here: C.1) Split review queues, based on our emerging [Bracket] convention for patches needing specialized review. If we find more areas of specialty besides ports, we can add new [Bracket] tags. C.2) Improve the quality of emails sent C.3) Highlight in a special way patches that have been waiting for review longer that some minimum period (a week?). These could be highlighted visually in the review queue, and maybe would send extra review request emails automatically. Speaking of your action plan... I've had a look at C.3 and was going to try to modify the bugzilla tools to highlight as you suggested. But after looking at the review queue over the last few days I'm not sure it is necessary or that it would help to fix the problem. http://www.webkit.org/pending-review The page above already lists the review queue sorted by date. Over the last few days the queue has numbered in the 100's. A significant fraction (50%+) are older than a week. I could highlight them, but if it is already ordered by date and the highlight will encompass more than half the queue... what's the point? I tend to use this URL to scan the review queue instead: https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=review%3F I have few problems with the official review queue page, and maybe what we need to do is come up with one version that has the benefits of both. Here are the things I don't like about the pending-review page: 1) Uses two lines per bug plus a table border, so you can see fewer items at once. I can see 13 in a max-height browser window on my MacBook Pro, compared to 25 using my preferred query. 2) It splits out bugs with a specific requestee into separate lists, this is I think harmful to prompt review because usually those bugs don't really need review from one specific person. 3) Lists multiple patches on a single bug separately. I don't like this, usually such patches should be reviewed together, and it inflates the list. 4) No summary count. Here are things I like about it, compared to a vanilla query: 1) Skips most of the irrelevant fields, like priority, assignee, status, etc. 2) Sorts by date of request. I would love to have a single view that combines the best of both ways of viewing the review queue. That being said, I think highlighting old bugs is good to do right now. Even though today, 50% are older than a week, we don't want that to be the norm. By marking them in a clear way (and maybe further highlighting patches older than a month), we can help get to a point where this is the exception, not the norm. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Saturday, July 11, 2009 11:55:36 AM, Maciej Stachowiak wrote: On Jul 11, 2009, at 9:39 AM, Darin Adler wrote: On Jul 10, 2009, at 4:23 PM, Maciej Stachowiak wrote: Perhaps we should make update-webkit (or some new wrapper type tool) run resolve-ChangeLogs automatically. Dave Kilzer had the same idea when he created resolve-ChangeLogs, so update-webkit does run resolve-ChangeLogs automatically. See from October 2007. I guess the reason I hadn't noticed is that I often to svn update to update only the directory I'm working on. Maybe we need an update-subtree command. Why don't you update your whole source directory at once? I would think that updating only subdirectories could make the source tree out-of-sync and cause build problems later. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Jul 15, 2009, at 4:13 PM, David Kilzer wrote: On Saturday, July 11, 2009 11:55:36 AM, Maciej Stachowiak wrote: On Jul 11, 2009, at 9:39 AM, Darin Adler wrote: On Jul 10, 2009, at 4:23 PM, Maciej Stachowiak wrote: Perhaps we should make update-webkit (or some new wrapper type tool) run resolve-ChangeLogs automatically. Dave Kilzer had the same idea when he created resolve-ChangeLogs, so update-webkit does run resolve-ChangeLogs automatically. See from October 2007. I guess the reason I hadn't noticed is that I often to svn update to update only the directory I'm working on. Maybe we need an update-subtree command. Why don't you update your whole source directory at once? I would think that updating only subdirectories could make the source tree out-of-sync and cause build problems later. Updating just JavaScriptCore is often useful and a lot faster than a full update, especially when preparing to commit a patch that I have already tested. I agree that full updates are usually the right thing. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
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 ing 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
Re: [webkit-dev] Patch process - let's make it better
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. I concur with Maciej. Luke, in some other culture your posts are already considered derogatory and insulting. -- Ariya Hidayat, Nokia ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On 7/13/09, Maciej Stachowiak m...@apple.com wrote: Hi Luke, hi maciej, I think your webkit-dev emails are becoming disruptive. whilst at the same time apologising for being disruptive, i'd like to ask you why you consider that to be a bad thing. Sending profanity-laced walls of text is not an appropriate use of this list. i apologise for the use of profanity which may cause offense. i ask you to consider this: if it wasn't for the frustration at being treated in a completely inappropriate fashion, i wouldn't feel the need to use profanity to express frustration, would i? if you see things from my perspective, it's that i have great enthusiasm to contribute to free software in areas which require such a wild and overwhelming mix of expertise that nobody is willing to step up to the plate. that's where i step in. Please find a way to communicate without annoying the rest of the list, i will be delighted to do so. in return, you - apple employees - will treat my contributions with a little more respect, and perhaps even apologise for some of the inappropriate treatment. or I will ask the list administrators to censor you from the mailing list for the period of at least a week. i'm sorry to have to say this but i promise you that that will do nothing but prove my point. _read_ what i've written. sticking fingers in ears will only get the ends of your fingers sticky, not solve the problem. sorry i have to go, baby's crying. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
I concur with Maciej. Luke, in some other culture your posts are already considered derogatory and insulting. dear ariya, i apologise for that. i invite you to consider this, especially in light of the subject being discussed: if there was not a deep seated problem with the way that apple is treating people who contribute to the webkit project, then my ire would not have been raised such that i felt it necessary to express my frustration using swearwords, would it? saying that again, in shorter form: if there were no problems with the patch process, there would be no swearing. so, if you would like to help contribute something, please help apple take into consideration the lessons learned from #16401 so that something like the absolutely appalling lack of respect shown for my contributions does not happen again. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On 7/13/09, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com wrote: I concur with Maciej. Luke, in some other culture your posts are already considered derogatory and insulting. also - (i apologise for not thinking of this earlier) - it's worth emphasising that early on in the #16401 development process, when things were going well, the development was progressing rapidly, and i was collecting valuable contributions, advice and input from several sources, including apple employees as well as free software sources, i felt absolutely no need to swear. then, as the sheer scale of the work began to become clear to the reviewers, they began to feel overwhelmed, and, in an effort to reduce stress levels, began to throw up barriers. i began to provide technical counter-arguments and justifications for the progress, and still i did not feel any need to swear. i was asked to take several weeks worth of steps backwards, and began to feel pressurised: eight weeks at eleven hour days has a price. alp toker noticed that things were not going swimmingly and asked that the cost - financial and psychological - be taken into consideration. it was not. at this point, with rules and procedures and processes being placed over-and-above actual people, things started to break down. now we're suddenly gone from development being fun and exciting into development that is about fulfilling your duty and fulfilling the committment to the free software community that you serve, _especially_ in the face of continued hostility and complete lack of respect. this is the experience that you, apple, should never subject anyone to - should not be should not have been responsible for subjecting onto _anyone_. i trust that you, apple, will learn from this breakdown in communications. i trust that the changes to procedures and processes that you will make will help you to spot such things well in advance and act accordingly and appropriately, to make contributing to webkit as interesting and exciting as it should be. lastly, ariya, i've mentioned this elsewhere, but it's worth reiterating, here. as an experienced and gifted developer, i can take any code, from anywhere, and can pretty much immediately make useful contributions to it. i then also have the skills to manage, build and release that code. not everyone has the ability to do that. so i put up with a lot of flak from people such as apple employees in order to serve those users and developers who do _not_ have the ability that i do. and i invite you to ask yourselves: whom do _you_ serve? the answer to that question is the reason why i make the recommendation that webkit gets a charter. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On 7/13/09, Maciej Stachowiak m...@apple.com wrote: Hi Luke, I think your webkit-dev emails are becoming disruptive. Sending profanity-laced [apologised and explained already] walls of text maciej, i thought i'd best pick up on this one and nip it in the bud, even though i've replied already. look at what i wrote. it says that webkit is missing a charter, and cites the apache software foundation charter's key point of treating people with respect as part of the success of the ASF's development and progress. describing the very contribution in which i mention that respect for contributions is key as walls of text is therefore somewhat ironic, is it not, as it clearly says i have no respect for your contribution, yes? you might want to think about that, yes? and perhaps write a message saying, i apologise, i did not mean to convey disrespect, i was upset by the swearwords that you included, which, i also realise from what you've said they were provoked, but i was still upset. also i'd like to officially apologise on behalf of apple for apple employees subjecting you to personal attack and denigration when you were only trying to help contribute to webkit's success. something like that would go down well, and would be a good indication that apple recognises the root of the problem and is willing to engage with unpaid, unsponsored free software contributors in an appropriate and inclusory way. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Monday 13 July 2009 13:47:13 Luke Kenneth Casson Leighton wrote: On 7/13/09, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com wrote: I concur with Maciej. Luke, in some other culture your posts are already considered derogatory and insulting. also - (i apologise for not thinking of this earlier) - it's worth emphasising that early on in the #16401 development process, when things were going well, the development was progressing rapidly, and i was collecting valuable contributions, advice and input from several sources, including apple employees as well as free software sources, i felt absolutely no need to swear. then, as the sheer scale of the work began to become clear to the reviewers, they began to feel overwhelmed, and, in an effort to reduce stress levels, began to throw up barriers. Dear Luke, webkit-dev is really no place for your paranoia. greetings from your unpaid volunteer that feels well treated by the apple engineers working on webkit.org[1]. z. [1] I can not speak for all of apple, because I didn't meet every single person of currently employed by apple... ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
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 ing 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
Re: [webkit-dev] Patch process - let's make it better
On Jul 10, 2009, at 4:23 PM, Maciej Stachowiak wrote: Perhaps we should make update-webkit (or some new wrapper type tool) run resolve-ChangeLogs automatically. Dave Kilzer had the same idea when he created resolve-ChangeLogs, so update-webkit does run resolve-ChangeLogs automatically. See http://trac.webkit.org/changeset/27112 from October 2007. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Jul 11, 2009, at 9:39 AM, Darin Adler wrote: On Jul 10, 2009, at 4:23 PM, Maciej Stachowiak wrote: Perhaps we should make update-webkit (or some new wrapper type tool) run resolve-ChangeLogs automatically. Dave Kilzer had the same idea when he created resolve-ChangeLogs, so update-webkit does run resolve-ChangeLogs automatically. See http://trac.webkit.org/changeset/27112 from October 2007. I guess the reason I hadn't noticed is that I often to svn update to update only the directory I'm working on. Maybe we need an update- subtree command. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
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
Re: [webkit-dev] Patch process - let's make it better
On 2009-07-10, at 16:17, 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. 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. We just had a large thread where we rehashed this exact topic, so lets try not to derail this thread in the same way. In short, many people find ChangeLogs to be very useful, and SCM logs aren't a replacement due to the network requirements and performance issues. We also have the resolve-ChangeLogs script in WebKitTools/ Scripts to make dealing with ChangeLog conflicts trivial. - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Jul 10, 2009, at 4:17 PM, Chris Marrin wrote: 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. No you don’t. You can just use WebKitTools/Scripts/resolve-ChangeLogs; if you use WebKitTools/Scripts/update-webkit instead of just “svn up”, it will do it for you. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
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
Re: [webkit-dev] Patch process - let's make it better
Hi Maciej === Action Plan === * Phase 1 * snip C) Improve the way we get attention from reviewers. I think we should do three things here: C.1) Split review queues, based on our emerging [Bracket] convention for patches needing specialized review. If we find more areas of specialty besides ports, we can add new [Bracket] tags. Can we split by Component as well? So for example, there will be queues for WebCore [Mac], WebCore, Accessibility [Gtk] etc.. and treat non-bracketed patch queues as patches that affect core, non-platform specific code? C.2) Improve the quality of emails sent C.3) Highlight in a special way patches that have been waiting for review longer that some minimum period (a week?). These could be highlighted visually in the review queue, and maybe would send extra review request emails automatically. In addition, is it possible maybe to send a weekly or forthnightly outstanding review requests to webkit-dev? Regards, Jan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Jul 10, 2009, at 4:41 PM, Jan Michael Alonzo wrote: Hi Maciej === Action Plan === * Phase 1 * snip C) Improve the way we get attention from reviewers. I think we should do three things here: C.1) Split review queues, based on our emerging [Bracket] convention for patches needing specialized review. If we find more areas of specialty besides ports, we can add new [Bracket] tags. Can we split by Component as well? So for example, there will be queues for WebCore [Mac], WebCore, Accessibility [Gtk] etc.. and treat non-bracketed patch queues as patches that affect core, non-platform specific code? We could optionally do that, but I'm worried about splitting the review queue too much. I'd like to start with the bracket convention and see if we need to go beyond that. C.2) Improve the quality of emails sent C.3) Highlight in a special way patches that have been waiting for review longer that some minimum period (a week?). These could be highlighted visually in the review queue, and maybe would send extra review request emails automatically. In addition, is it possible maybe to send a weekly or forthnightly outstanding review requests to webkit-dev? That's a reasonable idea. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Friday, July 10, 2009 3:55:59 PM, Maciej Stachowiak wrote: A) Make it really easy to submit a patch. Eric's bugzilla-tool is close to being there. I'm going to help him refine this tool to the point that submitting a patch has only one step - a single command will make the patch, file a bug if needed, attach the patch to the bug, and flag it for review. I already took a first pass at this for git, which probably gets you 60-70% of the way there for svn: bugzilla-tool: Add create-bug command https://bugs.webkit.org/show_bug.cgi?id=27119 B) Make it really easy to commit a patch. Again, I think bugzilla-tool is the right path to achieving this. bugzilla-tool already does this. Today. It's freaking awesome. You can even specify whether you want to build and/or test the patch! (N.B. I haven't tried it with an svn working directory, but the support is already there.) Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
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. It's embarassing for me to admit, but I've been part of the WebKit project for nearly a year and didn't know about this -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
