[chromium-dev] Re: Read me: When checking in patches for someone else
It seems like GCL should really have support for "shepherding" a contributed CL to make this less error prone. -Darin On Sun, May 3, 2009 at 7:47 AM, Peter Kasting wrote: > If you check in patches for someone else, please do the following:* > Mention the person who wrote the patch. > * Since your gcl change is not the same Rietveld issue as the original > review, put a link to the original review in your change description. > * Put a BUG= or http://crbug.com/... line in so the bug gets updated > correctly. > * Either you or the original author should mark the original issue "closed" > and the bug "fixed". > > We've had a number of people not doing the last couple steps, which means > that bugs have been patched, but the bug is open with no indication of fixes > on it. This hinders testing, merging, triage, etc. Try not to be sloppy! > > PK > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Read me: When checking in patches for someone else
On svn, it's not integrated yet. Roughly: curl http://...patchset.diff | patch -p0 # need to fix that: echo change id > ./.svn/gcl_info/temp_change gcl try temp_change gcl commit temp_change The issue with that at the moment is that a @chromium.org user cannot use /close POST url (used by gcl on gcl commit) to close an issue he doesn't own, he must use the web interface. Once it's fixed, it will be much easier. If you feel compelled enough, send a patch to jam@ from somewhere in there: http://code.google.com/p/rietveld/source/browse/#svn/branches/chromium M-A 2009/5/3 Peter Kasting > 2009/5/3 Evan Martin > >> On Sun, May 3, 2009 at 10:57 AM, Paweł Hajdan Jr. >> wrote: >> > How should I check whether someone has filed the CLA if it's his first >> patch >> > going to be committed? >> >> I don't know if there's a way to verify. I just ask if they're not in >> the AUTHORS file and put them in with their first commit after they've >> said they've filled it out. >> > > Yes, we can (and should) verify this. There's an internal file that keeps > these on record, I'm sure someone has the link and can check for you (last > time I had to do it I asked Pam). > > BTW, in case the original point of my message got obscured by Evan's git > comments, I reiterate: make sure to update the bug database after checking > in. > > PK > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Read me: When checking in patches for someone else
2009/5/3 Evan Martin > On Sun, May 3, 2009 at 10:57 AM, Paweł Hajdan Jr. > wrote: > > How should I check whether someone has filed the CLA if it's his first > patch > > going to be committed? > > I don't know if there's a way to verify. I just ask if they're not in > the AUTHORS file and put them in with their first commit after they've > said they've filled it out. > Yes, we can (and should) verify this. There's an internal file that keeps these on record, I'm sure someone has the link and can check for you (last time I had to do it I asked Pam). BTW, in case the original point of my message got obscured by Evan's git comments, I reiterate: make sure to update the bug database after checking in. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Read me: When checking in patches for someone else
On Sun, May 3, 2009 at 10:57 AM, Paweł Hajdan Jr. wrote: > How should I check whether someone has filed the CLA if it's his first patch > going to be committed? I don't know if there's a way to verify. I just ask if they're not in the AUTHORS file and put them in with their first commit after they've said they've filled it out. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Read me: When checking in patches for someone else
How should I check whether someone has filed the CLA if it's his first patch going to be committed? On Sun, May 3, 2009 at 17:23, Evan Martin wrote: > I typically paste that in from the AUTHORS file (which is a good extra > check on whether someone has filed the CLA). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Read me: When checking in patches for someone else
If you're using git, I typically do: git cl patch -b 12345 where the number is the CL number. This patches in the change and makes the new branch use up the CL number of the original review, which will then be included in your commit. (If you want to fix the issue mapping of a branch later due to something going wrong, "git cl issue 12345" will do that.) Then when you commit: git cl dcommit -c 'Full Name ' I typically paste that in from the AUTHORS file (which is a good extra check on whether someone has filed the CLA). Caveats: - I really ought to make it pull the author's name from the change description. I forget this sometimes. :( - When this attempts to close the code review after the commit goes through, it will fail (since it's not yours). This would be a one-liner fix in Rietveld that I've also been putting off. On Sun, May 3, 2009 at 7:47 AM, Peter Kasting wrote: > If you check in patches for someone else, please do the following: > * Mention the person who wrote the patch. > * Since your gcl change is not the same Rietveld issue as the original > review, put a link to the original review in your change description. > * Put a BUG= or http://crbug.com/... line in so the bug gets updated > correctly. > * Either you or the original author should mark the original issue "closed" > and the bug "fixed". > We've had a number of people not doing the last couple steps, which means > that bugs have been patched, but the bug is open with no indication of fixes > on it. This hinders testing, merging, triage, etc. Try not to be sloppy! > PK > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
