Hi Zach,
We have a request in the queue to set up Gerrit for the Android team, and I know it's something that you consider very important. We haven't yet talked specifics of the configuration of Gerrit, and so I don't yet have a solid idea of what work there is for the Infrastructure team there. I'd like to rectify that and create an implementation plan for the first steps to where you want to go.
To that end, if we had a vanilla Gerrit instance up and running tomorrow, what would be the first things that you would want to do to it before it would be useful to you?
Thanks,
James
James,
Thanks for jumping on this. The need for Gerrit grows by the day.
The first thing I'd want to do would be to log in using my openid and upload my ssh key to it.
Second, I'd want to sync the Android-LEB and push a test change.
Third, I'd want to take the test change through the Gerrit lifecycle.
From there I'd want to hook up auto-merging and per-change build validation.
-Zach
On 13 June 2011 19:34, James Westby james.westby@linaro.org wrote:
Hi Zach,
We have a request in the queue to set up Gerrit for the Android team, and I know it's something that you consider very important. We haven't yet talked specifics of the configuration of Gerrit, and so I don't yet have a solid idea of what work there is for the Infrastructure team there. I'd like to rectify that and create an implementation plan for the first steps to where you want to go.
To that end, if we had a vanilla Gerrit instance up and running tomorrow, what would be the first things that you would want to do to it before it would be useful to you?
Thanks,
James
Hi Zach,
Thanks for the prompt response.
Please asssume that you are talking to someone that has never used Gerrit before :-)
On Mon, 13 Jun 2011 20:27:34 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
James,
Thanks for jumping on this. The need for Gerrit grows by the day.
The first thing I'd want to do would be to log in using my openid and upload my ssh key to it.
Openid is easy I think, I'll make sure it's documented in the RT ticket that openid is what we want the service to use for auth.
Is uploading your ssh key a standard part of Gerrit?
Second, I'd want to sync the Android-LEB and push a test change.
What does syncing and pushing involve? I assume they are native parts of Gerrit, but do we need to adjust our hosting of the Android trees on git.linaro.org to support this?
Third, I'd want to take the test change through the Gerrit lifecycle.
This is just the review cycle that is a standard part of Gerrit?
From there I'd want to hook up auto-merging and per-change build validation.
This would take approved changes and attempt to merge them in to a staging tree. From there it would do a build test, and then ideally push the results through LAVA. If all of that is successful then it would replace the current LEB tip with the staging tree and start again?
Thanks,
James
-Zach
On 13 June 2011 19:34, James Westby james.westby@linaro.org wrote:
Hi Zach,
We have a request in the queue to set up Gerrit for the Android team, and I know it's something that you consider very important. We haven't yet talked specifics of the configuration of Gerrit, and so I don't yet have a solid idea of what work there is for the Infrastructure team there. I'd like to rectify that and create an implementation plan for the first steps to where you want to go.
To that end, if we had a vanilla Gerrit instance up and running tomorrow, what would be the first things that you would want to do to it before it would be useful to you?
Thanks,
James
Hi,
It sounds like we have found someone to volunteer for the first steps of the Android review blueprint https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-code-...
/Patrik
On 14 June 2011 05:46, James Westby james.westby@linaro.org wrote:
Hi Zach,
Thanks for the prompt response.
Please asssume that you are talking to someone that has never used Gerrit before :-)
On Mon, 13 Jun 2011 20:27:34 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
James,
Thanks for jumping on this. The need for Gerrit grows by the day.
The first thing I'd want to do would be to log in using my openid and upload my ssh key to it.
Openid is easy I think, I'll make sure it's documented in the RT ticket that openid is what we want the service to use for auth.
Is uploading your ssh key a standard part of Gerrit?
Second, I'd want to sync the Android-LEB and push a test change.
What does syncing and pushing involve? I assume they are native parts of Gerrit, but do we need to adjust our hosting of the Android trees on git.linaro.org to support this?
Third, I'd want to take the test change through the Gerrit lifecycle.
This is just the review cycle that is a standard part of Gerrit?
From there I'd want to hook up auto-merging and per-change build validation.
This would take approved changes and attempt to merge them in to a staging tree. From there it would do a build test, and then ideally push the results through LAVA. If all of that is successful then it would replace the current LEB tip with the staging tree and start again?
Thanks,
James
-Zach
On 13 June 2011 19:34, James Westby james.westby@linaro.org wrote:
Hi Zach,
We have a request in the queue to set up Gerrit for the Android team, and I know it's something that you consider very important. We haven't yet talked specifics of the configuration of Gerrit, and so I don't yet have a solid idea of what work there is for the Infrastructure team there. I'd like to rectify that and create an implementation plan for the first steps to where you want to go.
To that end, if we had a vanilla Gerrit instance up and running tomorrow, what would be the first things that you would want to do to it before it would be useful to you?
Thanks,
James
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 13 June 2011 22:46, James Westby james.westby@linaro.org wrote:
Hi Zach,
Thanks for the prompt response.
Please asssume that you are talking to someone that has never used Gerrit before :-)
On Mon, 13 Jun 2011 20:27:34 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
James,
Thanks for jumping on this. The need for Gerrit grows by the day.
The first thing I'd want to do would be to log in using my openid and upload my ssh key to it.
Openid is easy I think, I'll make sure it's documented in the RT ticket that openid is what we want the service to use for auth.
Is uploading your ssh key a standard part of Gerrit?
Yes. Gerrit uses ssh (I'm not sure if this is configurable) for git transport between the local repo and the server.
Second, I'd want to sync the Android-LEB and push a test change.
What does syncing and pushing involve? I assume they are native parts of Gerrit, but do we need to adjust our hosting of the Android trees on git.linaro.org to support this?
No, we shouldn't have to adjust our hosting. Take a look at http://android.git.kernel.org/ where all the Android trees are hosted.
This write up shows the basic workflow:
http://source.android.com/source/version-control.html
This write up documents submitting patches:
http://source.android.com/source/submit-patches.html
Third, I'd want to take the test change through the Gerrit lifecycle.
This is just the review cycle that is a standard part of Gerrit?
See submitting patches above.
From there I'd want to hook up auto-merging and per-change build validation.
This would take approved changes and attempt to merge them in to a staging tree. From there it would do a build test, and then ideally push the results through LAVA. If all of that is successful then it would replace the current LEB tip with the staging tree and start again?
Yup.
On Tue, 14 Jun 2011 06:22:23 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
No, we shouldn't have to adjust our hosting. Take a look at http://android.git.kernel.org/ where all the Android trees are hosted.
What does this mean for the hosting of Gerrit though. Does this mean that Gerrit has to be on a server with enough space to host all the trees that will be put through review? Is it one tree per-user?
This would take approved changes and attempt to merge them in to a staging tree. From there it would do a build test, and then ideally push the results through LAVA. If all of that is successful then it would replace the current LEB tip with the staging tree and start again?
Yup.
Ok, that sounds like the biggest chunk of work. Are there any standard extensions to Gerrit to drive some of this?
To me it seems like we need:
* cron job/daemon to poll Gerrit for approved reviews * This does the test merges and leaves comments on Gerrit if something doesn't merge * It then triggers a test build on the build system and waits for the result. If it fails it leaves a comment on Gerrit linking to the build record. * Then we want to add LAVA in to the mix. I think this needs further discussion before we can include it in the plan as there would seem to be many open questions.
Thanks,
James
On 14 June 2011 07:52, James Westby james.westby@linaro.org wrote:
On Tue, 14 Jun 2011 06:22:23 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
No, we shouldn't have to adjust our hosting. Take a look at http://android.git.kernel.org/ where all the Android trees are hosted.
What does this mean for the hosting of Gerrit though. Does this mean that Gerrit has to be on a server with enough space to host all the trees that will be put through review? Is it one tree per-user?
This would take approved changes and attempt to merge them in to a staging tree. From there it would do a build test, and then ideally push the results through LAVA. If all of that is successful then it would replace the current LEB tip with the staging tree and start again?
Yup.
Ok, that sounds like the biggest chunk of work. Are there any standard extensions to Gerrit to drive some of this?
I'm not sure. This would be something to ask on repo-discuss@googlegroups.com or to Nasser at QC who's gone through this before.
"Grainawi, Nasser" nasserg@quicinc.com
To me it seems like we need:
* cron job/daemon to poll Gerrit for approved reviews * This does the test merges and leaves comments on Gerrit if something doesn't merge * It then triggers a test build on the build system and waits for the result. If it fails it leaves a comment on Gerrit linking to the build record. * Then we want to add LAVA in to the mix. I think this needs further discussion before we can include it in the plan as there would seem to be many open questions.
Sounds good.
On Tue, 14 Jun 2011 10:03:41 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 14 June 2011 07:52, James Westby james.westby@linaro.org wrote:
On Tue, 14 Jun 2011 06:22:23 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
No, we shouldn't have to adjust our hosting. Take a look at http://android.git.kernel.org/ where all the Android trees are hosted.
What does this mean for the hosting of Gerrit though. Does this mean that Gerrit has to be on a server with enough space to host all the trees that will be put through review? Is it one tree per-user?
This would take approved changes and attempt to merge them in to a staging tree. From there it would do a build test, and then ideally push the results through LAVA. If all of that is successful then it would replace the current LEB tip with the staging tree and start again?
Yup.
Ok, that sounds like the biggest chunk of work. Are there any standard extensions to Gerrit to drive some of this?
I'm not sure. This would be something to ask on repo-discuss@googlegroups.com or to Nasser at QC who's gone through this before.
I searched that group and it seems that most people are using something like the Jenkins Gerrit-trigger plugin to test each proposed change, rather than the tested merge that we are talking about.
http://code.google.com/p/gerrit/issues/detail?id=618
While we use Jenkins under the hood for the Android build service I don't think that this plugin is very useful to us at this stage given that we want to start with testing the merges before they happen.
I'll write up a spec on doing the tested merge involves.
Thanks,
James
Cool. Thanks James.
On 14 June 2011 16:32, James Westby james.westby@linaro.org wrote:
On Tue, 14 Jun 2011 10:03:41 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 14 June 2011 07:52, James Westby james.westby@linaro.org wrote:
On Tue, 14 Jun 2011 06:22:23 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
No, we shouldn't have to adjust our hosting. Take a look at http://android.git.kernel.org/ where all the Android trees are hosted.
What does this mean for the hosting of Gerrit though. Does this mean that Gerrit has to be on a server with enough space to host all the trees that will be put through review? Is it one tree per-user?
This would take approved changes and attempt to merge them in to a staging tree. From there it would do a build test, and then ideally push the results through LAVA. If all of that is successful then it would replace the current LEB tip with the staging tree and start again?
Yup.
Ok, that sounds like the biggest chunk of work. Are there any standard extensions to Gerrit to drive some of this?
I'm not sure. This would be something to ask on repo-discuss@googlegroups.com or to Nasser at QC who's gone through this before.
I searched that group and it seems that most people are using something like the Jenkins Gerrit-trigger plugin to test each proposed change, rather than the tested merge that we are talking about.
http://code.google.com/p/gerrit/issues/detail?id=618
While we use Jenkins under the hood for the Android build service I don't think that this plugin is very useful to us at this stage given that we want to start with testing the merges before they happen.
I'll write up a spec on doing the tested merge involves.
Thanks,
James
On Tue, 14 Jun 2011 17:32:59 -0400, James Westby james.westby@linaro.org wrote:
I'll write up a spec on doing the tested merge involves.
I've got the first draft of this at
https://wiki.linaro.org/Platform/Android/Specs/BuildTestedMerge
Please take a look at let me know any comments that you have and I'll incorporate them in to a second draft.
Thanks,
James
Looks pretty good.
I'm not sure about:
We wish to make this change to reduce the integration and testing burden near the release, which will make that time more stressful, and lead to more time being spent on development.
- We'll be doing a full CI loop so integration never stops
or
It is not about ensuring that everything always passes LAVA tests before it is accepted.
or
Out of scope Any integration with LAVA
- Do you mean this will be handled at a latter date?
I think LAVA and this task need to go hand in hand. Instead of spending time talking about how LAVA is out of scope we should consider both problems.
If we can get a patch set test merge and validation run on the result by 11.07 that'll be a big win.
-Zach
On 30 June 2011 17:51, James Westby james.westby@linaro.org wrote:
On Tue, 14 Jun 2011 17:32:59 -0400, James Westby james.westby@linaro.org wrote:
I'll write up a spec on doing the tested merge involves.
I've got the first draft of this at
https://wiki.linaro.org/Platform/Android/Specs/BuildTestedMerge
Please take a look at let me know any comments that you have and I'll incorporate them in to a second draft.
Thanks,
James
On Mon, 4 Jul 2011 00:39:20 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
We wish to make this change to reduce the integration and testing burden near the release, which will make that time more stressful, and lead to more time being spent on development.
- We'll be doing a full CI loop so integration never stops
Right, this was meant to say "there's no big integration effort required near release as it is done continuously." I'll clarify.
or
It is not about ensuring that everything always passes LAVA tests before it is accepted.
or
Out of scope Any integration with LAVA
- Do you mean this will be handled at a latter date?
Yes.
I think LAVA and this task need to go hand in hand. Instead of spending time talking about how LAVA is out of scope we should consider both problems.
No, we should break the task down in to manageable chunks so that we can get some benefit out earlier.
If we can get a patch set test merge and validation run on the result by 11.07 that'll be a big win.
I don't think we can. I don't have anyone free to work on this this month, and I think it's a bigger job than one month anyway.
Thanks,
James
On Mon, 13 Jun 2011 20:27:34 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
James,
Thanks for jumping on this. The need for Gerrit grows by the day.
The first thing I'd want to do would be to log in using my openid and upload my ssh key to it.
This should now be possible.
Everyone can now go to android.git.linaro.org and login by entering your LP profile URL, e.g.
https://launchpad.net/~james-w
(the form there is hardcoded to display those options which is unfortunate.)
You should then be able to add your ssh key.
The ssh server runs on port 29418 for your testing.
The next two steps I believe is something that you can do so I will leave it up to you. Let me know if there are other things that need configuration in Gerrit for these to proceed.
Thanks,
James
Second, I'd want to sync the Android-LEB and push a test change.
Third, I'd want to take the test change through the Gerrit lifecycle.
From there I'd want to hook up auto-merging and per-change build validation.
-Zach
On 13 June 2011 19:34, James Westby james.westby@linaro.org wrote:
Hi Zach,
We have a request in the queue to set up Gerrit for the Android team, and I know it's something that you consider very important. We haven't yet talked specifics of the configuration of Gerrit, and so I don't yet have a solid idea of what work there is for the Infrastructure team there. I'd like to rectify that and create an implementation plan for the first steps to where you want to go.
To that end, if we had a vanilla Gerrit instance up and running tomorrow, what would be the first things that you would want to do to it before it would be useful to you?
Thanks,
James
hi,
great news.
I think we should use a different hostname for gerrit. like review.android.linaro.org. With that we have the option to make a dedicated android git host using the android.git.l.o name eventually.
Will check with android team what hostname to use exactly and let you know. On Jun 24, 2011 10:05 PM, "James Westby" james.westby@linaro.org wrote:
On Mon, 13 Jun 2011 20:27:34 -0500, Zach Pfeffer zach.pfeffer@linaro.org
wrote:
James,
Thanks for jumping on this. The need for Gerrit grows by the day.
The first thing I'd want to do would be to log in using my openid and upload my ssh key to it.
This should now be possible.
Everyone can now go to android.git.linaro.org and login by entering your LP profile URL, e.g.
https://launchpad.net/~james-w
(the form there is hardcoded to display those options which is unfortunate.)
You should then be able to add your ssh key.
The ssh server runs on port 29418 for your testing.
The next two steps I believe is something that you can do so I will leave it up to you. Let me know if there are other things that need configuration in Gerrit for these to proceed.
Thanks,
James
Second, I'd want to sync the Android-LEB and push a test change.
Third, I'd want to take the test change through the Gerrit lifecycle.
From there I'd want to hook up auto-merging and per-change build
validation.
-Zach
On 13 June 2011 19:34, James Westby james.westby@linaro.org wrote:
Hi Zach,
We have a request in the queue to set up Gerrit for the Android team, and I know it's something that you consider very important. We haven't yet talked specifics of the configuration of Gerrit, and so I don't yet have a solid idea of what work there is for the Infrastructure team there. I'd like to rectify that and create an implementation plan for the first steps to where you want to go.
To that end, if we had a vanilla Gerrit instance up and running tomorrow, what would be the first things that you would want to do to
it
before it would be useful to you?
Thanks,
James
On Mon, 27 Jun 2011 11:25:59 +0200, Alexander Sack asac@linaro.org wrote:
hi,
great news.
I think we should use a different hostname for gerrit. like review.android.linaro.org. With that we have the option to make a dedicated android git host using the android.git.l.o name eventually.
I don't understand what this means. What's a "dedicated android git host" and why can't it co-exist with Gerrit?
Thanks,
James
On Mon, Jun 27, 2011 at 3:49 PM, James Westby james.westby@linaro.org wrote:
On Mon, 27 Jun 2011 11:25:59 +0200, Alexander Sack asac@linaro.org wrote:
hi,
great news.
I think we should use a different hostname for gerrit. like review.android.linaro.org. With that we have the option to make a dedicated android git host using the android.git.l.o name eventually.
I don't understand what this means. What's a "dedicated android git host" and why can't it co-exist with Gerrit?
android.git.linaro.org would be similar to https://git.linaro.org ... e.g. you go there and get a gitwebview for all the android trees we host.
you could put gerrit under android.git.linaro.org/gerrit, sure, but others don't do that; instead they have a top level domain "review.omapzoom.org" just for gerrit.
On Mon, 4 Jul 2011 10:28:36 +0200, Alexander Sack asac@linaro.org wrote:
android.git.linaro.org would be similar to https://git.linaro.org ... e.g. you go there and get a gitwebview for all the android trees we host.
you could put gerrit under android.git.linaro.org/gerrit, sure, but others don't do that; instead they have a top level domain "review.omapzoom.org" just for gerrit.
Please follow up to the ticket to request that change then.
Thanks,
James
On Fri, 24 Jun 2011 16:05:04 -0400 James Westby james.westby@linaro.org wrote:
Everyone can now go to android.git.linaro.org and login by entering your LP profile URL, e.g.
I keep forgetting this myself, so here's what James told me on IRC: the correct OpenID URL to use for login is https://login.launchpad.net .
-
Alexander Sack -
James Westby -
Patrik Ryd -
Paul Sokolovsky -
Zach Pfeffer