Please do not commit-queue+ changes to ChromiumBridge.h
Please do not commit-queue+ changes to ChromiumBridge.h These changes by definition break the Chromium build because they require corresponding changes in the Chromium repository. Please leave such CLs to a Chromium developer to commit because they can then coordinate the landing of the other side of the patch. Also, if you are wondering about the impact of a WebKit patch on the Chromium build, please see our integration bots here: http://tinyurl.com/md47pk Thanks! -Darin
Even better if the person submitting the patch marks it as commit-queue- when they do the r? (as Jian does for example) to prevent this from happening. Just do this for any patch that you want to be in control of landing. dave On Fri, Sep 4, 2009 at 11:04 AM, Darin Fisher <darin@chromium.org> wrote:
Please do not commit-queue+ changes to ChromiumBridge.h These changes by definition break the Chromium build because they require corresponding changes in the Chromium repository. Please leave such CLs to a Chromium developer to commit because they can then coordinate the landing of the other side of the patch.
Also, if you are wondering about the impact of a WebKit patch on the Chromium build, please see our integration bots here: http://tinyurl.com/md47pk
Thanks! -Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Agreed. It's the submitters responsibility to make it clear that they don't want their patch committed immediately after review. Current assumption is that all committers don't want their patches committed after review, but all non-committers do. -eric On Fri, Sep 4, 2009 at 7:12 PM, David Levin <levin@chromium.org> wrote:
Even better if the person submitting the patch marks it as commit-queue- when they do the r? (as Jian does for example) to prevent this from happening. Just do this for any patch that you want to be in control of landing.
dave
On Fri, Sep 4, 2009 at 11:04 AM, Darin Fisher <darin@chromium.org> wrote:
Please do not commit-queue+ changes to ChromiumBridge.h These changes by definition break the Chromium build because they require corresponding changes in the Chromium repository. Please leave such CLs to a Chromium developer to commit because they can then coordinate the landing of the other side of the patch.
Also, if you are wondering about the impact of a WebKit patch on the Chromium build, please see our integration bots here: http://tinyurl.com/md47pk
Thanks! -Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
That's why I started this thread. The process may be a bit unfamiliar to somepatch contributors (especially new ones), and so I wanted reviewers to be in the know that changes to ChromiumBridge.h should not be committed using the commit queue. -Darin On Sat, Sep 5, 2009 at 1:45 AM, Eric Seidel <eric@webkit.org> wrote:
Agreed. It's the submitters responsibility to make it clear that they don't want their patch committed immediately after review. Current assumption is that all committers don't want their patches committed after review, but all non-committers do. -eric
On Fri, Sep 4, 2009 at 7:12 PM, David Levin <levin@chromium.org> wrote:
Even better if the person submitting the patch marks it as commit-queue- when they do the r? (as Jian does for example) to prevent this from happening. Just do this for any patch that you want to be in control of landing.
dave
On Fri, Sep 4, 2009 at 11:04 AM, Darin Fisher <darin@chromium.org> wrote:
Please do not commit-queue+ changes to ChromiumBridge.h These changes by definition break the Chromium build because they require corresponding changes in the Chromium repository. Please leave such CLs to a Chromium developer to commit because they can then coordinate the landing of the other side of the patch.
Also, if you are wondering about the impact of a WebKit patch on the Chromium build, please see our integration bots here: http://tinyurl.com/md47pk
Thanks! -Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Ok. I see the "commit-queue" as orthogonal to the discussion. It's just a means of automating patch commits. You're asking that committers not commit patches containing "ChromiumBridge.h", which I think is fair to ask, but I'm just pointing out that I don't think folks will necessarily remember if contributers don't remind us in the bugs. Keeping up with the to-be-committed seems to keep us plenty busy without a list of special exceptions. :) I will certainly endeavor to avoid patches containing ChromiumBridge.h -eric On Sat, Sep 5, 2009 at 3:16 PM, Darin Fisher <darin@chromium.org> wrote:
That's why I started this thread. The process may be a bit unfamiliar to somepatch contributors (especially new ones), and so I wanted reviewers to be in the know that changes to ChromiumBridge.h should not be committed using the commit queue.
-Darin
On Sat, Sep 5, 2009 at 1:45 AM, Eric Seidel <eric@webkit.org> wrote:
Agreed. It's the submitters responsibility to make it clear that they don't want their patch committed immediately after review. Current assumption is that all committers don't want their patches committed after review, but all non-committers do. -eric
On Fri, Sep 4, 2009 at 7:12 PM, David Levin <levin@chromium.org> wrote:
Even better if the person submitting the patch marks it as commit-queue- when they do the r? (as Jian does for example) to prevent this from happening. Just do this for any patch that you want to be in control of landing.
dave
On Fri, Sep 4, 2009 at 11:04 AM, Darin Fisher <darin@chromium.org>wrote:
Please do not commit-queue+ changes to ChromiumBridge.h These changes by definition break the Chromium build because they require corresponding changes in the Chromium repository. Please leave such CLs to a Chromium developer to commit because they can then coordinate the landing of the other side of the patch.
Also, if you are wondering about the impact of a WebKit patch on the Chromium build, please see our integration bots here: http://tinyurl.com/md47pk
Thanks! -Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Yeah, I agree that it would be best for contributors to flag their own patches. commit-queue- seems like a great way to do that! I was just hoping for some extra awareness from committers to help not break the Chromium build. Thanks, -Darin On Sat, Sep 5, 2009 at 3:51 PM, Eric Seidel <eric@webkit.org> wrote:
Ok. I see the "commit-queue" as orthogonal to the discussion. It's just a means of automating patch commits. You're asking that committers not commit patches containing "ChromiumBridge.h", which I think is fair to ask, but I'm just pointing out that I don't think folks will necessarily remember if contributers don't remind us in the bugs. Keeping up with the to-be-committed seems to keep us plenty busy without a list of special exceptions. :) I will certainly endeavor to avoid patches containing ChromiumBridge.h
-eric
On Sat, Sep 5, 2009 at 3:16 PM, Darin Fisher <darin@chromium.org> wrote:
That's why I started this thread. The process may be a bit unfamiliar to somepatch contributors (especially new ones), and so I wanted reviewers to be in the know that changes to ChromiumBridge.h should not be committed using the commit queue.
-Darin
On Sat, Sep 5, 2009 at 1:45 AM, Eric Seidel <eric@webkit.org> wrote:
Agreed. It's the submitters responsibility to make it clear that they don't want their patch committed immediately after review. Current assumption is that all committers don't want their patches committed after review, but all non-committers do. -eric
On Fri, Sep 4, 2009 at 7:12 PM, David Levin <levin@chromium.org> wrote:
Even better if the person submitting the patch marks it as commit-queue- when they do the r? (as Jian does for example) to prevent this from happening. Just do this for any patch that you want to be in control of landing.
dave
On Fri, Sep 4, 2009 at 11:04 AM, Darin Fisher <darin@chromium.org>wrote:
Please do not commit-queue+ changes to ChromiumBridge.h These changes by definition break the Chromium build because they require corresponding changes in the Chromium repository. Please leave such CLs to a Chromium developer to commit because they can then coordinate the landing of the other side of the patch.
Also, if you are wondering about the impact of a WebKit patch on the Chromium build, please see our integration bots here: http://tinyurl.com/md47pk
Thanks! -Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
participants (3)
-
Darin Fisher
-
David Levin
-
Eric Seidel