[U-Boot] u-boot gerrit server
Gentlemen, I have not forgotten our discussion regarding setting up a sample gerrit server for u-boot during the ELCE mini-summit. Sorry for this long and not very clear email, if there is any interest I will be glad to answer questions and address concerns to the best of my ability, and I am sure Simon (sjg@) will pitch in.
Gerrit is used for many different projects now, I spoke with coreboot maintainer who moved their process from email to gerrit - he said it involved a certain threshold effort, but after that the entire community was extremely pleased with the result - none of the patches were lost in more than a year after the transition. Of course coreboot is a much smaller project than u-boot, but both Android and Chrome OS also successfully use gerrit.
You can now see the sample u-boot gerrit server at https://u-boot-review.googlesource.com/#/q/status:open,n,z which is a code review interface to the actual gerrit based git server at u-boot.googlesource.com, which in turn is a mirror of the denx u-boot git reporsitory. This particular gerrit server runs on Google infrastructure, replicated in three different datacenters across the world, each having a 10GB/s uplink, with 99.999 reliability. But of course it could be set up on a dedicated server anywhere.
There is plenty of documentation available (just click on the 'Documentation' link in the top of the page). I will try to give just a brief description.
For the purposes of this demo the patches submitted for review were generated by a script I wrote. The script scrapes http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches from there and tries applying them. Not all patches apply cleanly (as some of them are for branches).
If the patch applies cleanly, the script adds two stanzas to the patch description
- Change-Id: generated by git - Patch-At: a reference to the patchwork page where the patch was downloaded from
and uploads the patch for review as the user named 'Gerrit Tester'. Each upload creates a new git branch just for review purposes.
Change-Id is required by gerrit as a universally unique identifier, which will allow to group together multiple versions of the same patch. When the patch with a known Change-ID is uploaded, the review server creates a revision and allows to see the differences between the revisions. Local modifications required to have git generate the Change-Id: stanza are described in https://gerrit-review.googlesource.com/Documentation/user-upload.html
Any one can upload patches to this server after creating an account on it. Any Google account will do, or if you don't want to have a Google based email you can create the account using your existing email. Follow the prompts after clicking on 'Sign in' link on the top right.
After signing up one should create a password for authentication with the server. Click on the little black triangle next to your name in the top right, then on 'Settings' and then on 'HTTP Password'. Save the lines generated by this in ~/.netrc (with permissions set to 0400) and you are good to go.
Now clone the repository using
git clone https://u-boot.googlesource.com/u-boot
(or just add it as a remote to your existing u-boot tree) and now you can upload patches using
git push https://u-boot.googlesource.com/u-boot HEAD:refs/for/master
=== How review process works ====
For an example comment/modification upload cycle I picked this change:
https://u-boot-review.googlesource.com/#/c/1146
Say the comment was that the definition in line 419 on https://u-boot-review.googlesource.com/#/c/1146/1/common/console.c shoudl use #if defined() instead of #ifdef
The reviewer double clicks on the line where he wants to leave a comment, a form opens, where the reviewer adds the comment. Then he submits the form, and the comment gets associated with the line. Once all comments are added, they can be published. As a result the author, all other reviewers and any configured mailing list receive the comments in the email:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv Vadim Bendebury has posted comments on this change.
Change subject: sandbox: Allow the console to work earlier ......................................................................
Patch Set 1:
(1 comment)
https://u-boot-review.googlesource.com/#/c/1146/1/common/console.c File common/console.c:
Line 419: #ifdef CONFIG_SANDBOX could this be #if defined() instead? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Let's say at this point the author can reply to the comment using the same web interface, and make a modification. After that
git commit --amend -s
will ensure that the new patch keeps the old Change-ID. After the change has been committed, it can be uploaded:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv $ git push https://u-boot.googlesource.com/u-boot HEAD:refs/for/master remote: Resolving deltas: 100% (8/8) remote: Processing changes: updated: 1, done remote: (W) ae78aca: commit message lines >70 characters; manually wrap lines remote: remote: Updated Changes: remote: https://u-boot-review.googlesource.com/1146 remote: To https://u-boot.googlesource.com/u-boot * [new branch] HEAD -> refs/for/master $ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now one can see two patch sets on this patch's page: https://u-boot-review.googlesource.com/#/c/1141/
Once the change has been reviewed and agreed upon, the custodian could cherry pick its latest version and submit to the master repository. In the most usual case the gerrit server would be that master repository - in that case all the custodian needs to do is to clikc on the 'publish' button.
This server is not configured yet, but in general gerrit allows for three levels of reviewers - those who can just comment, those who can assign a +1 rating to the change (an equivalent of an acked by) and those who can assign a +2 rating or push the change (the custodians). There is no point in setting these up on a mirror, but if so desired, it could be done.
I encourage any one to give this a try, try playing with it, upload patches, try commenting, sending reviews, upload new patch versions, etc.
From what I can see looking at other projects, is this is adopted, the
quality of and productivity of custodians/maintainers goes way up.
--vb
Hi Vadim,
On Nov 11, 2013 10:22 PM, "Vadim Bendebury (вб)" vbendeb@google.com wrote:
Gentlemen, I have not forgotten our discussion regarding setting up a sample gerrit server for u-boot during the ELCE mini-summit. Sorry for this long and not very clear email, if there is any interest I will be glad to answer questions and address concerns to the best of my ability, and I am sure Simon (sjg@) will pitch in.
Yes, but just to say (for now) thank you for setting this up and the detailed walkthrough.
Regards, Simon
Hi Vadim,
On Mon, 11 Nov 2013 21:21:27 -0800, Vadim Bendebury (вб) vbendeb@google.com wrote:
For the purposes of this demo the patches submitted for review were generated by a script I wrote. The script scrapes http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches from there and tries applying them. Not all patches apply cleanly (as some of them are for branches).
How do we intend to handle this? Will we move to a single repository, with each patch getting reviewers assigned based on which parts of the code it touches? Or move from repos to branches, one per current custodian repo? Or something else yet?
If the patch applies cleanly, the script adds two stanzas to the patch
- Change-Id: generated by git
- Patch-At: a reference to the patchwork page where the patch was
downloaded from
'Patch-At' seem ininformative to me. Why not 'Patchwork-URL'?
and uploads the patch for review as the user named 'Gerrit Tester'. Each upload creates a new git branch just for review purposes.
(I'm skipping the gerrit workflow description here as I have used gerrit extensively in my, ahem, previous job)
I'm fine with using gerrit and yes, it can be a useful tool, not only regarding review, but also for learning the whys and hows of code changes through the comments from both reviewers and submitters (and I am in strong favor of a policy that every reviewer comment must be addressed by a supmitter reply, even the default will-do one.
One drawback though: I cannot seem to be able to use my U-Boot mail address, even though it is a secondary address of my G+ account; gerrit only wants to see my gmail address. I sure hope that I am not required to use a gmail address to identify myself as the author of my own patches within the U-Boot project.
--vb
Amicalement,
On Tue, Nov 12, 2013 at 2:42 AM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Vadim,
On Mon, 11 Nov 2013 21:21:27 -0800, Vadim Bendebury (вб) vbendeb@google.com wrote:
For the purposes of this demo the patches submitted for review were generated by a script I wrote. The script scrapes http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches from there and tries applying them. Not all patches apply cleanly (as some of them are for branches).
How do we intend to handle this? Will we move to a single repository, with each patch getting reviewers assigned based on which parts of the code it touches? Or move from repos to branches, one per current custodian repo? Or something else yet?
Hi Albert,
I *think* the way to go is to create multiple projects, one per custodian, such that the upload URLs are different.
If the patch applies cleanly, the script adds two stanzas to the patch
- Change-Id: generated by git
- Patch-At: a reference to the patchwork page where the patch was
downloaded from
'Patch-At' seem ininformative to me. Why not 'Patchwork-URL'?
It should not be there at all, scraping the patchwork is just a means of seeding the server with patches to show how this looks.
In the proper use case each user will puth their patches to the server, so there is no need in the cross reference to patchwork.
and uploads the patch for review as the user named 'Gerrit Tester'. Each upload creates a new git branch just for review purposes.
(I'm skipping the gerrit workflow description here as I have used gerrit extensively in my, ahem, previous job)
I'm fine with using gerrit and yes, it can be a useful tool, not only regarding review, but also for learning the whys and hows of code changes through the comments from both reviewers and submitters (and I am in strong favor of a policy that every reviewer comment must be addressed by a supmitter reply, even the default will-do one.
exactly, this is the main advantage IMO also, keeping track of changes and comments becomes so much more robust.
Also, gerrit allows to see diffs between patches, this is what email based review system can not easily deliver.
One drawback though: I cannot seem to be able to use my U-Boot mail address, even though it is a secondary address of my G+ account; gerrit only wants to see my gmail address. I sure hope that I am not required to use a gmail address to identify myself as the author of my own patches within the U-Boot project.
This should not be the case, but there are some kinks with multiple accounts. Can you try opening an 'incognito' window and sign up through it?
--vb
--vb
Amicalement,
Albert.
Hi Vadim,
On Tue, 12 Nov 2013 08:33:46 -0800, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 2:42 AM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Vadim,
On Mon, 11 Nov 2013 21:21:27 -0800, Vadim Bendebury (вб) vbendeb@google.com wrote:
For the purposes of this demo the patches submitted for review were generated by a script I wrote. The script scrapes http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches from there and tries applying them. Not all patches apply cleanly (as some of them are for branches).
How do we intend to handle this? Will we move to a single repository, with each patch getting reviewers assigned based on which parts of the code it touches? Or move from repos to branches, one per current custodian repo? Or something else yet?
Hi Albert,
I *think* the way to go is to create multiple projects, one per custodian, such that the upload URLs are different.
If the patch applies cleanly, the script adds two stanzas to the patch
- Change-Id: generated by git
- Patch-At: a reference to the patchwork page where the patch was
downloaded from
'Patch-At' seem ininformative to me. Why not 'Patchwork-URL'?
It should not be there at all, scraping the patchwork is just a means of seeding the server with patches to show how this looks.
In the proper use case each user will puth their patches to the server, so there is no need in the cross reference to patchwork.
and uploads the patch for review as the user named 'Gerrit Tester'. Each upload creates a new git branch just for review purposes.
(I'm skipping the gerrit workflow description here as I have used gerrit extensively in my, ahem, previous job)
I'm fine with using gerrit and yes, it can be a useful tool, not only regarding review, but also for learning the whys and hows of code changes through the comments from both reviewers and submitters (and I am in strong favor of a policy that every reviewer comment must be addressed by a supmitter reply, even the default will-do one.
exactly, this is the main advantage IMO also, keeping track of changes and comments becomes so much more robust.
Also, gerrit allows to see diffs between patches, this is what email based review system can not easily deliver.
One drawback though: I cannot seem to be able to use my U-Boot mail address, even though it is a secondary address of my G+ account; gerrit only wants to see my gmail address. I sure hope that I am not required to use a gmail address to identify myself as the author of my own patches within the U-Boot project.
This should not be the case, but there are some kinks with multiple accounts. Can you try opening an 'incognito' window and sign up through it?
I did try anyway, but it did nothing, and that was quite predictable, and here's why: I didn't mean gerrit got mixed up between two of my Google+ accounts, as I only have one account, and can thus only log in with this one. But This account's main address i a gmail one, and my so-to-speak "U-Boot e-mail address", which I use for the ML, and in 'Copyright' lines in the U-Boot code base, and on Patchwork) is a secondary address of my Google+ account. And gerrit does not know of my secondary addresses, which make it unable to recognize me, once logged in, as the submitter of patches posted under my "U-Boot" address.
--vb
Amicalement,
On Tue, Nov 12, 2013 at 9:11 AM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Vadim,
On Tue, 12 Nov 2013 08:33:46 -0800, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 2:42 AM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Vadim,
On Mon, 11 Nov 2013 21:21:27 -0800, Vadim Bendebury (вб) vbendeb@google.com wrote:
For the purposes of this demo the patches submitted for review were generated by a script I wrote. The script scrapes http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches from there and tries applying them. Not all patches apply cleanly (as some of them are for branches).
How do we intend to handle this? Will we move to a single repository, with each patch getting reviewers assigned based on which parts of the code it touches? Or move from repos to branches, one per current custodian repo? Or something else yet?
Hi Albert,
I *think* the way to go is to create multiple projects, one per custodian, such that the upload URLs are different.
If the patch applies cleanly, the script adds two stanzas to the patch
- Change-Id: generated by git
- Patch-At: a reference to the patchwork page where the patch was
downloaded from
'Patch-At' seem ininformative to me. Why not 'Patchwork-URL'?
It should not be there at all, scraping the patchwork is just a means of seeding the server with patches to show how this looks.
In the proper use case each user will puth their patches to the server, so there is no need in the cross reference to patchwork.
and uploads the patch for review as the user named 'Gerrit Tester'. Each upload creates a new git branch just for review purposes.
(I'm skipping the gerrit workflow description here as I have used gerrit extensively in my, ahem, previous job)
I'm fine with using gerrit and yes, it can be a useful tool, not only regarding review, but also for learning the whys and hows of code changes through the comments from both reviewers and submitters (and I am in strong favor of a policy that every reviewer comment must be addressed by a supmitter reply, even the default will-do one.
exactly, this is the main advantage IMO also, keeping track of changes and comments becomes so much more robust.
Also, gerrit allows to see diffs between patches, this is what email based review system can not easily deliver.
One drawback though: I cannot seem to be able to use my U-Boot mail address, even though it is a secondary address of my G+ account; gerrit only wants to see my gmail address. I sure hope that I am not required to use a gmail address to identify myself as the author of my own patches within the U-Boot project.
This should not be the case, but there are some kinks with multiple accounts. Can you try opening an 'incognito' window and sign up through it?
I did try anyway, but it did nothing, and that was quite predictable, and here's why: I didn't mean gerrit got mixed up between two of my Google+ accounts, as I only have one account, and can thus only log in with this one. But This account's main address i a gmail one, and my so-to-speak "U-Boot e-mail address", which I use for the ML, and in 'Copyright' lines in the U-Boot code base, and on Patchwork) is a secondary address of my Google+ account. And gerrit does not know of my secondary addresses, which make it unable to recognize me, once logged in, as the submitter of patches posted under my "U-Boot" address.
Moving everybody to bcc so that we could sort this out without disturbing the rest.
Have you tried creating a new account from the incognito window? You should be able to create an account with any arbitrary email.
--v
--vb
Amicalement,
Albert.
Hello Vadim,
On Tue, Nov 12, 2013 at 3:21 AM, Vadim Bendebury (вб) vbendeb@google.com wrote:
Gentlemen, I have not forgotten our discussion regarding setting up a sample gerrit server for u-boot during the ELCE mini-summit. Sorry for this long and not very clear email, if there is any interest I will be glad to answer questions and address concerns to the best of my ability, and I am sure Simon (sjg@) will pitch in.
I support the idea about using Gerrit. I've been using it a lot for O.S. Systems products and it works very well.
Once I saw this announcement I thought the same thing as Albert: how custodians will have their trees there?
I think just doing auto-assignment of patches would work quite well.
On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador otavio@ossystems.com.br wrote:
Hello Vadim,
On Tue, Nov 12, 2013 at 3:21 AM, Vadim Bendebury (вб) vbendeb@google.com wrote:
Gentlemen, I have not forgotten our discussion regarding setting up a sample gerrit server for u-boot during the ELCE mini-summit. Sorry for this long and not very clear email, if there is any interest I will be glad to answer questions and address concerns to the best of my ability, and I am sure Simon (sjg@) will pitch in.
Hello Ottavio,
I support the idea about using Gerrit. I've been using it a lot for O.S. Systems products and it works very well.
exactly, it certainly is very different from what's in use now, but offers many advantages and results in highly improved productivity.
Once I saw this announcement I thought the same thing as Albert: how custodians will have their trees there?
It is easy to create multiple projects, one per custodian.
--vb
I think just doing auto-assignment of patches would work quite well.
-- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador otavio@ossystems.com.br wrote:
Once I saw this announcement I thought the same thing as Albert: how custodians will have their trees there?
It is easy to create multiple projects, one per custodian.
Yes but than Tom would need to send another branch for review or directly push into master?
Besides, how people will 'transfer' one patch from one tree to another? This will happen quite often as someone mistakenly sending a patch for the wrong tree or custodians wanting the set to go together in a single merge...
On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador otavio@ossystems.com.br wrote:
Once I saw this announcement I thought the same thing as Albert: how custodians will have their trees there?
It is easy to create multiple projects, one per custodian.
Yes but than Tom would need to send another branch for review or directly push into master?
I am not sure what would be the best way of doing it, but the bottom line is that there still would be multiple git repos with chunks of code going upstream once accepted by custodians.
Besides, how people will 'transfer' one patch from one tree to another? This will happen quite often as someone mistakenly sending a patch for the wrong tree or custodians wanting the set to go together in a single merge...
How is it handled today? Gerrit is after all just a means of keeping track of patches in a more efficient way, the rest could be similar to what is in use now, or enhanced using gerrit's features.
--vb
-- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador otavio@ossystems.com.br wrote:
Once I saw this announcement I thought the same thing as Albert: how custodians will have their trees there?
It is easy to create multiple projects, one per custodian.
Yes but than Tom would need to send another branch for review or directly push into master?
I am not sure what would be the best way of doing it, but the bottom line is that there still would be multiple git repos with chunks of code going upstream once accepted by custodians.
Besides, how people will 'transfer' one patch from one tree to another? This will happen quite often as someone mistakenly sending a patch for the wrong tree or custodians wanting the set to go together in a single merge...
How is it handled today? Gerrit is after all just a means of keeping track of patches in a more efficient way, the rest could be similar to what is in use now, or enhanced using gerrit's features.
Currently it is just reassigned in Patchwork; using multiple trees will complicate this.
Don't get me wrong, I enjoy Gerrit, I am just trying to bring up the problems/issues we need to find solutions to be able to use/try it.
On Tue, Nov 12, 2013 at 9:00 AM, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador otavio@ossystems.com.br wrote:
Once I saw this announcement I thought the same thing as Albert: how custodians will have their trees there?
It is easy to create multiple projects, one per custodian.
Yes but than Tom would need to send another branch for review or directly push into master?
I am not sure what would be the best way of doing it, but the bottom line is that there still would be multiple git repos with chunks of code going upstream once accepted by custodians.
Besides, how people will 'transfer' one patch from one tree to another? This will happen quite often as someone mistakenly sending a patch for the wrong tree or custodians wanting the set to go together in a single merge...
How is it handled today? Gerrit is after all just a means of keeping track of patches in a more efficient way, the rest could be similar to what is in use now, or enhanced using gerrit's features.
Currently it is just reassigned in Patchwork; using multiple trees will complicate this.
Don't get me wrong, I enjoy Gerrit, I am just trying to bring up the problems/issues we need to find solutions to be able to use/try it.
Ottavio, these all are certainly very good questions to ask. Admittedly, I am not very much involved in the u-boot review process, so I am sure there are details to figure out.
It is just a question of buying into a web/GUI based review system, once that decision is made the details could be sorted out in more ways than one.
--v
-- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
On Tue, Nov 12, 2013 at 3:07 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 9:00 AM, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador otavio@ossystems.com.br wrote:
Once I saw this announcement I thought the same thing as Albert: how custodians will have their trees there?
It is easy to create multiple projects, one per custodian.
Yes but than Tom would need to send another branch for review or directly push into master?
I am not sure what would be the best way of doing it, but the bottom line is that there still would be multiple git repos with chunks of code going upstream once accepted by custodians.
Besides, how people will 'transfer' one patch from one tree to another? This will happen quite often as someone mistakenly sending a patch for the wrong tree or custodians wanting the set to go together in a single merge...
How is it handled today? Gerrit is after all just a means of keeping track of patches in a more efficient way, the rest could be similar to what is in use now, or enhanced using gerrit's features.
Currently it is just reassigned in Patchwork; using multiple trees will complicate this.
Don't get me wrong, I enjoy Gerrit, I am just trying to bring up the problems/issues we need to find solutions to be able to use/try it.
Ottavio, these all are certainly very good questions to ask. Admittedly, I am not very much involved in the u-boot review process, so I am sure there are details to figure out.
It is just a question of buying into a web/GUI based review system, once that decision is made the details could be sorted out in more ways than one.
Sorry but this is not that simple.
Personally I dislike the idea of multiple U-Boot trees (when it comes to Gerrit workflow).
What I think it'd be possible to get working would be:
Custodians would have Submit rights Custodians would have +2 review rights "Normal" people would have +1 review rights CI system could have the +1 for verified Single tree
So essentially custodians could be assigned using some keyword, file matching and other clever heuristics, but it'd give freedom for them to 'drop' their review need or add someone else. Once they submit a change it goes straight to 'master' branch.
This easy the merging of stuff but this ends with the sub-trees.
On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote: [snip]
What I think it'd be possible to get working would be:
Custodians would have Submit rights Custodians would have +2 review rights "Normal" people would have +1 review rights CI system could have the +1 for verified Single tree
So essentially custodians could be assigned using some keyword, file matching and other clever heuristics, but it'd give freedom for them to 'drop' their review need or add someone else. Once they submit a change it goes straight to 'master' branch.
This easy the merging of stuff but this ends with the sub-trees.
This sounds like a first good step to me. It's important that things get reviewed and everyone seems to be able to see the difference between "this is a small change to $subsystem driver for $soc, $soc custodian can just push it" and "this is a big change, $subsystem custodian should speak up too". But I still want a final say on when things are able to be merged into master
On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote: [snip]
What I think it'd be possible to get working would be:
Custodians would have Submit rights Custodians would have +2 review rights "Normal" people would have +1 review rights CI system could have the +1 for verified Single tree
So essentially custodians could be assigned using some keyword, file matching and other clever heuristics, but it'd give freedom for them to 'drop' their review need or add someone else. Once they submit a change it goes straight to 'master' branch.
This easy the merging of stuff but this ends with the sub-trees.
This sounds like a first good step to me. It's important that things get reviewed and everyone seems to be able to see the difference between "this is a small change to $subsystem driver for $soc, $soc custodian can just push it" and "this is a big change, $subsystem custodian should speak up too". But I still want a final say on when things are able to be merged into master
In this case, you could be the only one with 'submit' rights. So everything would be just 'awaiting' for submit.
On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote: [snip]
What I think it'd be possible to get working would be:
Custodians would have Submit rights Custodians would have +2 review rights "Normal" people would have +1 review rights CI system could have the +1 for verified Single tree
So essentially custodians could be assigned using some keyword, file matching and other clever heuristics, but it'd give freedom for them to 'drop' their review need or add someone else. Once they submit a change it goes straight to 'master' branch.
This easy the merging of stuff but this ends with the sub-trees.
This sounds like a first good step to me. It's important that things get reviewed and everyone seems to be able to see the difference between "this is a small change to $subsystem driver for $soc, $soc custodian can just push it" and "this is a big change, $subsystem custodian should speak up too". But I still want a final say on when things are able to be merged into master
In this case, you could be the only one with 'submit' rights. So everything would be just 'awaiting' for submit.
And custodian should still be able to easily pull together a list of stuff they're happy with, change sets I guess?
On Thu, Nov 14, 2013 at 6:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote: [snip]
What I think it'd be possible to get working would be:
Custodians would have Submit rights Custodians would have +2 review rights "Normal" people would have +1 review rights CI system could have the +1 for verified Single tree
So essentially custodians could be assigned using some keyword, file matching and other clever heuristics, but it'd give freedom for them to 'drop' their review need or add someone else. Once they submit a change it goes straight to 'master' branch.
This easy the merging of stuff but this ends with the sub-trees.
This sounds like a first good step to me. It's important that things get reviewed and everyone seems to be able to see the difference between "this is a small change to $subsystem driver for $soc, $soc custodian can just push it" and "this is a big change, $subsystem custodian should speak up too". But I still want a final say on when things are able to be merged into master
In this case, you could be the only one with 'submit' rights. So everything would be just 'awaiting' for submit.
And custodian should still be able to easily pull together a list of stuff they're happy with, change sets I guess?
You can pull the 'patchsets' but the workflow I often see is that when the changes are approved they go to 'master' right away.
The main drawback I see is that the 'custodian' gets the power to merge stuff direct in master. At same time, we get a more 'complete' master and this avoids subsystems being tested late in the release cycle.
I think it radically change the workflow but I've been using it for a while in internal projects, customers and partners and it works quite well.
On Thu, Nov 14, 2013 at 06:30:00PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 6:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote: [snip]
What I think it'd be possible to get working would be:
Custodians would have Submit rights Custodians would have +2 review rights "Normal" people would have +1 review rights CI system could have the +1 for verified Single tree
So essentially custodians could be assigned using some keyword, file matching and other clever heuristics, but it'd give freedom for them to 'drop' their review need or add someone else. Once they submit a change it goes straight to 'master' branch.
This easy the merging of stuff but this ends with the sub-trees.
This sounds like a first good step to me. It's important that things get reviewed and everyone seems to be able to see the difference between "this is a small change to $subsystem driver for $soc, $soc custodian can just push it" and "this is a big change, $subsystem custodian should speak up too". But I still want a final say on when things are able to be merged into master
In this case, you could be the only one with 'submit' rights. So everything would be just 'awaiting' for submit.
And custodian should still be able to easily pull together a list of stuff they're happy with, change sets I guess?
You can pull the 'patchsets' but the workflow I often see is that when the changes are approved they go to 'master' right away.
The main drawback I see is that the 'custodian' gets the power to merge stuff direct in master. At same time, we get a more 'complete' master and this avoids subsystems being tested late in the release cycle.
I think it radically change the workflow but I've been using it for a while in internal projects, customers and partners and it works quite well.
So long as we can plug a reasonable mount of CI in, this might not be too bad, honestly. The big problems I find with custodian PRs are "oh, when I threw this through the everything-matrix, $board broke that you didn't try".
On Thu, Nov 14, 2013 at 6:58 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 06:30:00PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 6:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote: [snip]
What I think it'd be possible to get working would be:
Custodians would have Submit rights Custodians would have +2 review rights "Normal" people would have +1 review rights CI system could have the +1 for verified Single tree
So essentially custodians could be assigned using some keyword, file matching and other clever heuristics, but it'd give freedom for them to 'drop' their review need or add someone else. Once they submit a change it goes straight to 'master' branch.
This easy the merging of stuff but this ends with the sub-trees.
This sounds like a first good step to me. It's important that things get reviewed and everyone seems to be able to see the difference between "this is a small change to $subsystem driver for $soc, $soc custodian can just push it" and "this is a big change, $subsystem custodian should speak up too". But I still want a final say on when things are able to be merged into master
In this case, you could be the only one with 'submit' rights. So everything would be just 'awaiting' for submit.
And custodian should still be able to easily pull together a list of stuff they're happy with, change sets I guess?
You can pull the 'patchsets' but the workflow I often see is that when the changes are approved they go to 'master' right away.
The main drawback I see is that the 'custodian' gets the power to merge stuff direct in master. At same time, we get a more 'complete' master and this avoids subsystems being tested late in the release cycle.
I think it radically change the workflow but I've been using it for a while in internal projects, customers and partners and it works quite well.
So long as we can plug a reasonable mount of CI in, this might not be too bad, honestly. The big problems I find with custodian PRs are "oh, when I threw this through the everything-matrix, $board broke that you didn't try".
In fact I think every commit could be 'forced' to have the 'Verified' vote set by the CI. So we couldn't push anything which fail.
On Thu, Nov 14, 2013 at 07:00:09PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 6:58 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 06:30:00PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 6:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote: [snip]
> What I think it'd be possible to get working would be: > > Custodians would have Submit rights > Custodians would have +2 review rights > "Normal" people would have +1 review rights > CI system could have the +1 for verified > Single tree > > So essentially custodians could be assigned using some keyword, file > matching and other clever heuristics, but it'd give freedom for them > to 'drop' their review need or add someone else. Once they submit a > change it goes straight to 'master' branch. > > This easy the merging of stuff but this ends with the sub-trees.
This sounds like a first good step to me. It's important that things get reviewed and everyone seems to be able to see the difference between "this is a small change to $subsystem driver for $soc, $soc custodian can just push it" and "this is a big change, $subsystem custodian should speak up too". But I still want a final say on when things are able to be merged into master
In this case, you could be the only one with 'submit' rights. So everything would be just 'awaiting' for submit.
And custodian should still be able to easily pull together a list of stuff they're happy with, change sets I guess?
You can pull the 'patchsets' but the workflow I often see is that when the changes are approved they go to 'master' right away.
The main drawback I see is that the 'custodian' gets the power to merge stuff direct in master. At same time, we get a more 'complete' master and this avoids subsystems being tested late in the release cycle.
I think it radically change the workflow but I've been using it for a while in internal projects, customers and partners and it works quite well.
So long as we can plug a reasonable mount of CI in, this might not be too bad, honestly. The big problems I find with custodian PRs are "oh, when I threw this through the everything-matrix, $board broke that you didn't try".
In fact I think every commit could be 'forced' to have the 'Verified' vote set by the CI. So we couldn't push anything which fail.
True. But can we also setup levels of CI? Make everything pass the 1 ARM 1 PowerPC, 1 MIPS, x86, sandbox build-test, optionally make others (the merge request equivalents) have to build all ARM, all PowerPC, all MIPS, etc, etc.
On Thu, Nov 14, 2013 at 12:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote: [snip]
What I think it'd be possible to get working would be:
Custodians would have Submit rights Custodians would have +2 review rights "Normal" people would have +1 review rights CI system could have the +1 for verified Single tree
So essentially custodians could be assigned using some keyword, file matching and other clever heuristics, but it'd give freedom for them to 'drop' their review need or add someone else. Once they submit a change it goes straight to 'master' branch.
This easy the merging of stuff but this ends with the sub-trees.
This sounds like a first good step to me. It's important that things get reviewed and everyone seems to be able to see the difference between "this is a small change to $subsystem driver for $soc, $soc custodian can just push it" and "this is a big change, $subsystem custodian should speak up too". But I still want a final say on when things are able to be merged into master
In this case, you could be the only one with 'submit' rights. So everything would be just 'awaiting' for submit.
And custodian should still be able to easily pull together a list of stuff they're happy with, change sets I guess?
Presumably the custodians will have their own copy of their branch, they could upload patches to the master branch for merging into master.
-- Tom
On Thu, Nov 14, 2013 at 7:13 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Thu, Nov 14, 2013 at 12:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote: [snip]
What I think it'd be possible to get working would be:
Custodians would have Submit rights Custodians would have +2 review rights "Normal" people would have +1 review rights CI system could have the +1 for verified Single tree
So essentially custodians could be assigned using some keyword, file matching and other clever heuristics, but it'd give freedom for them to 'drop' their review need or add someone else. Once they submit a change it goes straight to 'master' branch.
This easy the merging of stuff but this ends with the sub-trees.
This sounds like a first good step to me. It's important that things get reviewed and everyone seems to be able to see the difference between "this is a small change to $subsystem driver for $soc, $soc custodian can just push it" and "this is a big change, $subsystem custodian should speak up too". But I still want a final say on when things are able to be merged into master
In this case, you could be the only one with 'submit' rights. So everything would be just 'awaiting' for submit.
And custodian should still be able to easily pull together a list of stuff they're happy with, change sets I guess?
Presumably the custodians will have their own copy of their branch, they could upload patches to the master branch for merging into master.
I understand this is the closer we can get of our /current/ workflow but I do believe it'd be sub-optimal.
On Thu, Nov 14, 2013 at 01:13:37PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 12:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote: [snip]
What I think it'd be possible to get working would be:
Custodians would have Submit rights Custodians would have +2 review rights "Normal" people would have +1 review rights CI system could have the +1 for verified Single tree
So essentially custodians could be assigned using some keyword, file matching and other clever heuristics, but it'd give freedom for them to 'drop' their review need or add someone else. Once they submit a change it goes straight to 'master' branch.
This easy the merging of stuff but this ends with the sub-trees.
This sounds like a first good step to me. It's important that things get reviewed and everyone seems to be able to see the difference between "this is a small change to $subsystem driver for $soc, $soc custodian can just push it" and "this is a big change, $subsystem custodian should speak up too". But I still want a final say on when things are able to be merged into master
In this case, you could be the only one with 'submit' rights. So everything would be just 'awaiting' for submit.
And custodian should still be able to easily pull together a list of stuff they're happy with, change sets I guess?
Presumably the custodians will have their own copy of their branch, they could upload patches to the master branch for merging into master.
Sorry for not being clear. I'm thinking of the single-tree approach where custodians don't have separate trees per-se but provide changesets they want merged or some other mechanism to include the N changes they're happy with and have reviewed.
Hi Otavio,
On Tue, 12 Nov 2013 15:00:06 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador otavio@ossystems.com.br wrote:
Once I saw this announcement I thought the same thing as Albert: how custodians will have their trees there?
It is easy to create multiple projects, one per custodian.
Yes but than Tom would need to send another branch for review or directly push into master?
I am not sure what would be the best way of doing it, but the bottom line is that there still would be multiple git repos with chunks of code going upstream once accepted by custodians.
Besides, how people will 'transfer' one patch from one tree to another? This will happen quite often as someone mistakenly sending a patch for the wrong tree or custodians wanting the set to go together in a single merge...
How is it handled today? Gerrit is after all just a means of keeping track of patches in a more efficient way, the rest could be similar to what is in use now, or enhanced using gerrit's features.
Currently it is just reassigned in Patchwork; using multiple trees will complicate this.
How about one branch per custodian? At my previous job we had a couple branches, one per distinct "product".
Don't get me wrong, I enjoy Gerrit, I am just trying to bring up the problems/issues we need to find solutions to be able to use/try it.
Amicalement,
Hello Albert,
On Tue, Nov 12, 2013 at 3:13 PM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
On Tue, 12 Nov 2013 15:00:06 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador otavio@ossystems.com.br wrote:
Besides, how people will 'transfer' one patch from one tree to another? This will happen quite often as someone mistakenly sending a patch for the wrong tree or custodians wanting the set to go together in a single merge...
How is it handled today? Gerrit is after all just a means of keeping track of patches in a more efficient way, the rest could be similar to what is in use now, or enhanced using gerrit's features.
Currently it is just reassigned in Patchwork; using multiple trees will complicate this.
How about one branch per custodian? At my previous job we had a couple branches, one per distinct "product".
I am not aware of a way to 'transfer' a patch from one branch to another.
Hi Otavio,
On Tue, 12 Nov 2013 15:16:15 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
Hello Albert,
On Tue, Nov 12, 2013 at 3:13 PM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
On Tue, 12 Nov 2013 15:00:06 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador otavio@ossystems.com.br wrote:
Besides, how people will 'transfer' one patch from one tree to another? This will happen quite often as someone mistakenly sending a patch for the wrong tree or custodians wanting the set to go together in a single merge...
How is it handled today? Gerrit is after all just a means of keeping track of patches in a more efficient way, the rest could be similar to what is in use now, or enhanced using gerrit's features.
Currently it is just reassigned in Patchwork; using multiple trees will complicate this.
How about one branch per custodian? At my previous job we had a couple branches, one per distinct "product".
I am not aware of a way to 'transfer' a patch from one branch to another.
There would not be such transfers -- we don't do this right now with our trees. We do merge requests, which means pulling two custodian repos into the same working repo, doing a merge between what are now two custodian branches, and pushing the result back onto one of the custodian trees.
So here, if there is one branch per custodian, what we would need is the ability to merge one custodian branch into another.
Amicalement,
On Tue, Nov 12, 2013 at 3:30 PM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Otavio,
On Tue, 12 Nov 2013 15:16:15 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
Hello Albert,
On Tue, Nov 12, 2013 at 3:13 PM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
On Tue, 12 Nov 2013 15:00:06 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador otavio@ossystems.com.br wrote:
Besides, how people will 'transfer' one patch from one tree to another? This will happen quite often as someone mistakenly sending a patch for the wrong tree or custodians wanting the set to go together in a single merge...
How is it handled today? Gerrit is after all just a means of keeping track of patches in a more efficient way, the rest could be similar to what is in use now, or enhanced using gerrit's features.
Currently it is just reassigned in Patchwork; using multiple trees will complicate this.
How about one branch per custodian? At my previous job we had a couple branches, one per distinct "product".
I am not aware of a way to 'transfer' a patch from one branch to another.
There would not be such transfers -- we don't do this right now with our trees. We do merge requests, which means pulling two custodian repos into the same working repo, doing a merge between what are now two custodian branches, and pushing the result back onto one of the custodian trees.
So here, if there is one branch per custodian, what we would need is the ability to merge one custodian branch into another.
Right but currently you are not 'denied' to review a patch someone didn't put for you. The custodians as done 'on-the-fly' as each custodian takes his duties and process the patches and apply them, later updating patchwork.
On the 'new Gerrit' workflow, if it is assigned for a branch/tree and this is mistakenly done, how it will be done?
On Tue, Nov 12, 2013 at 10:07 AM, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 3:30 PM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Otavio,
On Tue, 12 Nov 2013 15:16:15 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
Hello Albert,
On Tue, Nov 12, 2013 at 3:13 PM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
On Tue, 12 Nov 2013 15:00:06 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador otavio@ossystems.com.br wrote: > Besides, how people will 'transfer' one patch from one tree to > another? This will happen quite often as someone mistakenly sending a > patch for the wrong tree or custodians wanting the set to go together > in a single merge... >
How is it handled today? Gerrit is after all just a means of keeping track of patches in a more efficient way, the rest could be similar to what is in use now, or enhanced using gerrit's features.
Currently it is just reassigned in Patchwork; using multiple trees will complicate this.
How about one branch per custodian? At my previous job we had a couple branches, one per distinct "product".
I am not aware of a way to 'transfer' a patch from one branch to another.
There would not be such transfers -- we don't do this right now with our trees. We do merge requests, which means pulling two custodian repos into the same working repo, doing a merge between what are now two custodian branches, and pushing the result back onto one of the custodian trees.
So here, if there is one branch per custodian, what we would need is the ability to merge one custodian branch into another.
Right but currently you are not 'denied' to review a patch someone didn't put for you. The custodians as done 'on-the-fly' as each custodian takes his duties and process the patches and apply them, later updating patchwork.
On the 'new Gerrit' workflow, if it is assigned for a branch/tree and this is mistakenly done, how it will be done?
the patch can always be abandoned on gerrit, so no problem there. As for moving it to the right tree - either the original submitter could resubmit it, or the custodian could cherry pick it, does not seem to be the problem either way.
--v
-- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
On Tue, 2013-11-12 at 10:24 -0800, Vadim Bendebury wrote:
On Tue, Nov 12, 2013 at 10:07 AM, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 3:30 PM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Otavio,
On Tue, 12 Nov 2013 15:16:15 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
Hello Albert,
On Tue, Nov 12, 2013 at 3:13 PM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
On Tue, 12 Nov 2013 15:00:06 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) vbendeb@google.com wrote: > On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador > otavio@ossystems.com.br wrote: >> Besides, how people will 'transfer' one patch from one tree to >> another? This will happen quite often as someone mistakenly sending a >> patch for the wrong tree or custodians wanting the set to go together >> in a single merge... >> > > How is it handled today? Gerrit is after all just a means of keeping > track of patches in a more efficient way, the rest could be similar to > what is in use now, or enhanced using gerrit's features.
Currently it is just reassigned in Patchwork; using multiple trees will complicate this.
How about one branch per custodian? At my previous job we had a couple branches, one per distinct "product".
I am not aware of a way to 'transfer' a patch from one branch to another.
There would not be such transfers -- we don't do this right now with our trees. We do merge requests, which means pulling two custodian repos into the same working repo, doing a merge between what are now two custodian branches, and pushing the result back onto one of the custodian trees.
So here, if there is one branch per custodian, what we would need is the ability to merge one custodian branch into another.
Right but currently you are not 'denied' to review a patch someone didn't put for you. The custodians as done 'on-the-fly' as each custodian takes his duties and process the patches and apply them, later updating patchwork.
On the 'new Gerrit' workflow, if it is assigned for a branch/tree and this is mistakenly done, how it will be done?
the patch can always be abandoned on gerrit, so no problem there. As for moving it to the right tree - either the original submitter could resubmit it,
And the custodians would have to carefully check that it was actually the same patch that the previous custodian acked to go through the second custodian's tree...
-Scott
Hi Otavio,
On Tue, 12 Nov 2013 16:07:41 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 3:30 PM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Otavio,
On Tue, 12 Nov 2013 15:16:15 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
Hello Albert,
On Tue, Nov 12, 2013 at 3:13 PM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
On Tue, 12 Nov 2013 15:00:06 -0200, Otavio Salvador otavio@ossystems.com.br wrote:
On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) vbendeb@google.com wrote:
On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador otavio@ossystems.com.br wrote: > Besides, how people will 'transfer' one patch from one tree to > another? This will happen quite often as someone mistakenly sending a > patch for the wrong tree or custodians wanting the set to go together > in a single merge... >
How is it handled today? Gerrit is after all just a means of keeping track of patches in a more efficient way, the rest could be similar to what is in use now, or enhanced using gerrit's features.
Currently it is just reassigned in Patchwork; using multiple trees will complicate this.
How about one branch per custodian? At my previous job we had a couple branches, one per distinct "product".
I am not aware of a way to 'transfer' a patch from one branch to another.
There would not be such transfers -- we don't do this right now with our trees. We do merge requests, which means pulling two custodian repos into the same working repo, doing a merge between what are now two custodian branches, and pushing the result back onto one of the custodian trees.
So here, if there is one branch per custodian, what we would need is the ability to merge one custodian branch into another.
Right but currently you are not 'denied' to review a patch someone didn't put for you. The custodians as done 'on-the-fly' as each custodian takes his duties and process the patches and apply them, later updating patchwork.
IIRC, gerrit roles are orthogonal to branches, or can be made so at least, so custodians would not be barred from reviewing patches on other branches. The problem would be information: how does a custodian learn that a change set ( gerritspeak coming back :) ) on another branch requires his/her attention?
On the 'new Gerrit' workflow, if it is assigned for a branch/tree and this is mistakenly done, how it will be done?
If you're asking how we would make sure the patches go to the right branch... I have no idea.
Amicalement,
Dear Albert,
In message 20131112181315.3dfe4531@lilith you wrote:
Currently it is just reassigned in Patchwork; using multiple trees will complicate this.
How about one branch per custodian? At my previous job we had a couple branches, one per distinct "product".
This does not solve the problem of reassigning a patch to someone else. I think we canot (easily, on a regular base, as part of the standard work flow) move commits from one branch to another one.
Best regards,
Wolfgang Denk
Dear Vadim,
In message CAC3GErHOF06DVZqGGnd89hW00GNjU=wg8cfyoGgCbEB1martsw@mail.gmail.com you wrote:
Gentlemen, I have not forgotten our discussion regarding setting up a sample gerrit server for u-boot during the ELCE mini-summit. Sorry for this long and not very clear email, if there is any interest I will be glad to answer questions and address concerns to the best of my ability, and I am sure Simon (sjg@) will pitch in.
Thanks for the efforts.
I have a few questions:
For the purposes of this demo the patches submitted for review were generated by a script I wrote. The script scrapes http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches from there and tries applying them. Not all patches apply cleanly (as some of them are for branches).
Can you not pick up the patches directly from the mailing list? I mean, we know of the problems patchwork has (like silently dropping certain base64 / utf8 encoded messages), so we should rather try and get a more reliable feed for the patches?
Any one can upload patches to this server after creating an account on it. Any Google account will do, or if you don't want to have a Google based email you can create the account using your existing email. Follow the prompts after clicking on 'Sign in' link on the top right.
Is my understanding correct that I have to use or create a google account in any case to participate in this type of work? What if I am not willing to accept Google's Terms of Service, or to register an account with google for other reasons?
After signing up one should create a password for authentication with the server. Click on the little black triangle next to your name in the top right, then on 'Settings' and then on 'HTTP Password'. Save the lines generated by this in ~/.netrc (with permissions set to 0400) and you are good to go.
For me nothing happens when I click on "settings". I just see for a fraction of a second as small pop-up "working", and then nothing.
This server is not configured yet, but in general gerrit allows for three levels of reviewers - those who can just comment, those who can assign a +1 rating to the change (an equivalent of an acked by) and those who can assign a +2 rating or push the change (the custodians). There is no point in setting these up on a mirror, but if so desired, it could be done.
How can we arrange to keep the mailing list in sync?
Best regards,
Wolfgang Denk
Hello Wolfgang,
On Tue, Nov 12, 2013 at 11:26 AM, Wolfgang Denk wd@denx.de wrote:
Dear Vadim,
In message CAC3GErHOF06DVZqGGnd89hW00GNjU=wg8cfyoGgCbEB1martsw@mail.gmail.com you wrote:
Gentlemen, I have not forgotten our discussion regarding setting up a sample gerrit server for u-boot during the ELCE mini-summit. Sorry for this long and not very clear email, if there is any interest I will be glad to answer questions and address concerns to the best of my ability, and I am sure Simon (sjg@) will pitch in.
Thanks for the efforts.
I have a few questions:
For the purposes of this demo the patches submitted for review were generated by a script I wrote. The script scrapes http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches from there and tries applying them. Not all patches apply cleanly (as some of them are for branches).
Can you not pick up the patches directly from the mailing list? I mean, we know of the problems patchwork has (like silently dropping certain base64 / utf8 encoded messages), so we should rather try and get a more reliable feed for the patches?
this is the thing: picking up patches from patchwork is not something you'd do regularly - this is just my way of populating the review site from a single test account.
If this workflow were adopted, each user would push their patch to the gerrit server, creating a new review branch for that particular patch. In general, gerrit view of the branch matches the submitter's view of the branch - if the submitter has several patches in one branch, they will all be uploaded by gerrit to the same separate branch, maintaining the relationship between the patches.
Any one can upload patches to this server after creating an account on it. Any Google account will do, or if you don't want to have a Google based email you can create the account using your existing email. Follow the prompts after clicking on 'Sign in' link on the top right.
Is my understanding correct that I have to use or create a google account in any case to participate in this type of work? What if I am not willing to accept Google's Terms of Service, or to register an account with google for other reasons?
This is correct, if you decide to use the google infrastructure based server. But you don't have to, gerrit is a stand alone application which can be easily installed on the same server or on a different server in the same location where the master u-boot git server is, with you (denx.de) having full control over it.
Google hosting has advantages of providing extremely high bandwidth and reliability, but google's version of gerrit (distributed and replicated) is not a requirement, as i said, gerrit could be hosted on a linux machine.
After signing up one should create a password for authentication with the server. Click on the little black triangle next to your name in the top right, then on 'Settings' and then on 'HTTP Password'. Save the lines generated by this in ~/.netrc (with permissions set to 0400) and you are good to go.
For me nothing happens when I click on "settings". I just see for a fraction of a second as small pop-up "working", and then nothing.
This is odd, can you maybe send me a screenshot of this browser window with the `settings' link displayed, before and after you click on it?
This server is not configured yet, but in general gerrit allows for three levels of reviewers - those who can just comment, those who can assign a +1 rating to the change (an equivalent of an acked by) and those who can assign a +2 rating or push the change (the custodians). There is no point in setting these up on a mirror, but if so desired, it could be done.
How can we arrange to keep the mailing list in sync?
This is a big question for which there is no good answer. Gerrit will send submitted patches in emails (limited to a configurable max patch size), but it will not accept email based reviews. So, this would involve a change in the way things done, I am just suggesting this as an alternative for consideration.
--vb
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Our management frequently gets lost in thought. That's because it's unfamiliar territory.
On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote:
Hello Wolfgang,
[snip]
Can you not pick up the patches directly from the mailing list? I mean, we know of the problems patchwork has (like silently dropping certain base64 / utf8 encoded messages), so we should rather try and get a more reliable feed for the patches?
this is the thing: picking up patches from patchwork is not something you'd do regularly - this is just my way of populating the review site from a single test account.
If this workflow were adopted, each user would push their patch to the gerrit server, creating a new review branch for that particular patch. In general, gerrit view of the branch matches the submitter's view of the branch - if the submitter has several patches in one branch, they will all be uploaded by gerrit to the same separate branch, maintaining the relationship between the patches.
This is my biggest concern. On the one-off to infrequent contribution side (and we do have some of that), I worry about the infrastucture hurdle here.
On the other side, what is the gerrit equivalent of 'git send-email --compose ...', and I'm focusing on the compose side here. Or is it just another mental switch the project makes, from that to push to gerrit / compose email saying "hey, look at this"
Any one can upload patches to this server after creating an account on it. Any Google account will do, or if you don't want to have a Google based email you can create the account using your existing email. Follow the prompts after clicking on 'Sign in' link on the top right.
Is my understanding correct that I have to use or create a google account in any case to participate in this type of work? What if I am not willing to accept Google's Terms of Service, or to register an account with google for other reasons?
This is correct, if you decide to use the google infrastructure based server. But you don't have to, gerrit is a stand alone application which can be easily installed on the same server or on a different server in the same location where the master u-boot git server is, with you (denx.de) having full control over it.
Google hosting has advantages of providing extremely high bandwidth and reliability, but google's version of gerrit (distributed and replicated) is not a requirement, as i said, gerrit could be hosted on a linux machine.
Well, how much help and tweaking can we get, if we go with Google hosting? My views are perhaps biased based on using gerrit earlier in Android's life, but, I can't imagine us having the time to deal with admining and upgrading a server later on. And of course, given ${insert ones favorite now defunct google service} what might happen down the line if the Google hosting goes away?
[snip]
This server is not configured yet, but in general gerrit allows for three levels of reviewers - those who can just comment, those who can assign a +1 rating to the change (an equivalent of an acked by) and those who can assign a +2 rating or push the change (the custodians). There is no point in setting these up on a mirror, but if so desired, it could be done.
How can we arrange to keep the mailing list in sync?
This is a big question for which there is no good answer. Gerrit will send submitted patches in emails (limited to a configurable max patch size), but it will not accept email based reviews. So, this would involve a change in the way things done, I am just suggesting this as an alternative for consideration.
Can we at least get all reviews sent to the ML?
On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote:
Hello Wolfgang,
[snip]
Can you not pick up the patches directly from the mailing list? I mean, we know of the problems patchwork has (like silently dropping certain base64 / utf8 encoded messages), so we should rather try and get a more reliable feed for the patches?
this is the thing: picking up patches from patchwork is not something you'd do regularly - this is just my way of populating the review site from a single test account.
If this workflow were adopted, each user would push their patch to the gerrit server, creating a new review branch for that particular patch. In general, gerrit view of the branch matches the submitter's view of the branch - if the submitter has several patches in one branch, they will all be uploaded by gerrit to the same separate branch, maintaining the relationship between the patches.
This is my biggest concern. On the one-off to infrequent contribution side (and we do have some of that), I worry about the infrastucture hurdle here.
Sorry, I am not sure i understand what the biggest concern is: that the users would push their own patches? Why is this a problem - the patches would go into their own branches until reviewed and merged. Or did you mean something else?
On the other side, what is the gerrit equivalent of 'git send-email --compose ...', and I'm focusing on the compose side here. Or is it just another mental switch the project makes, from that to push to gerrit / compose email saying "hey, look at this"
This is how we usually do this:
- upload all patches to gerrit - go to the web interface of the first patch in the series (by this time gerrit would have a stack of patches showing their dependencies), click on "review" - at this point gerrit would open a form to type the cover message in - once you finish composing the message you click on "publish comments" and it gets sent to everybody who was picked as the reviewer, and to default addresses, if any are configured (which of course could be u-boot@lists.denx.de, for instance)
Once thing I have to mention: gerrit is notorious for sending tons of email, while this is being worked on, in the meantime some more rigorous email filtering might be very useful.
Any one can upload patches to this server after creating an account on it. Any Google account will do, or if you don't want to have a Google based email you can create the account using your existing email. Follow the prompts after clicking on 'Sign in' link on the top right.
Is my understanding correct that I have to use or create a google account in any case to participate in this type of work? What if I am not willing to accept Google's Terms of Service, or to register an account with google for other reasons?
This is correct, if you decide to use the google infrastructure based server. But you don't have to, gerrit is a stand alone application which can be easily installed on the same server or on a different server in the same location where the master u-boot git server is, with you (denx.de) having full control over it.
Google hosting has advantages of providing extremely high bandwidth and reliability, but google's version of gerrit (distributed and replicated) is not a requirement, as i said, gerrit could be hosted on a linux machine.
Well, how much help and tweaking can we get, if we go with Google hosting? My views are perhaps biased based on using gerrit earlier in Android's life, but, I can't imagine us having the time to deal with admining and upgrading a server later on.
Well, if you use google hosteg gerrit, you won't have a problem with upgrading or managing the server. Some one would need to get admin rights and set it up properly (create branches per custodian, set up user groups and group permissions, etc.). I am not going to be able to do this, but I sure could help pushing issues through the Gerrit-On-Google folks, they are pretty accommodating and responsive.
And of course, given ${insert ones favorite now defunct google service} what might happen down the line if the Google hosting goes away?
This is a very valid concern and there is no guarantees. But if push comes to shove, gerrit is an open source product and it can be installed on a stand alone server (which of course would be a pain).
[snip]
This server is not configured yet, but in general gerrit allows for three levels of reviewers - those who can just comment, those who can assign a +1 rating to the change (an equivalent of an acked by) and those who can assign a +2 rating or push the change (the custodians). There is no point in setting these up on a mirror, but if so desired, it could be done.
How can we arrange to keep the mailing list in sync?
This is a big question for which there is no good answer. Gerrit will send submitted patches in emails (limited to a configurable max patch size), but it will not accept email based reviews. So, this would involve a change in the way things done, I am just suggesting this as an alternative for consideration.
Can we at least get all reviews sent to the ML?
The problem with this is that when reviews are sent to the mailing list, they are for different custodians, trees, etc. It looks like appx. half of them applies cleanly to the master branch, the rest do not. Is there a way to tell what branch the patch is detined to by looking at the email?
A much more robust approach is to have users push patches directly, and set up branches/projects on the server, as required.
--vb
-- Tom
On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote:
Hello Wolfgang,
[snip]
Can you not pick up the patches directly from the mailing list? I mean, we know of the problems patchwork has (like silently dropping certain base64 / utf8 encoded messages), so we should rather try and get a more reliable feed for the patches?
this is the thing: picking up patches from patchwork is not something you'd do regularly - this is just my way of populating the review site from a single test account.
If this workflow were adopted, each user would push their patch to the gerrit server, creating a new review branch for that particular patch. In general, gerrit view of the branch matches the submitter's view of the branch - if the submitter has several patches in one branch, they will all be uploaded by gerrit to the same separate branch, maintaining the relationship between the patches.
This is my biggest concern. On the one-off to infrequent contribution side (and we do have some of that), I worry about the infrastucture hurdle here.
Sorry, I am not sure i understand what the biggest concern is: that the users would push their own patches? Why is this a problem - the patches would go into their own branches until reviewed and merged. Or did you mean something else?
I mean, it's a higher hurdle to clear. Looking at other non-Android projects, I know some folks have said "bah, not worth the effort" to push trivial things, if it must come via gerrit. So some way to scrape the ML for things that don't come in via gerrit to start with would be handy.
On the other side, what is the gerrit equivalent of 'git send-email --compose ...', and I'm focusing on the compose side here. Or is it just another mental switch the project makes, from that to push to gerrit / compose email saying "hey, look at this"
This is how we usually do this:
- upload all patches to gerrit
- go to the web interface of the first patch in the series (by this
time gerrit would have a stack of patches showing their dependencies), click on "review" - at this point gerrit would open a form to type the cover message in
- once you finish composing the message you click on "publish
comments" and it gets sent to everybody who was picked as the reviewer, and to default addresses, if any are configured (which of course could be u-boot@lists.denx.de, for instance)
Right, and at that point we've mixed discussion of a concept with discussion of a particular change, and we're in web-only for writes. I guess (pending see below) one could just write the 0/N email separate, or in-reply-to 1/N, so that the concept discussion stays on the list and in the archives and so on.
Once thing I have to mention: gerrit is notorious for sending tons of email, while this is being worked on, in the meantime some more rigorous email filtering might be very useful.
Just how hard is it likely to be to filter things so that only: 1) new patches 2) reviews get sent to the ML?
Any one can upload patches to this server after creating an account on it. Any Google account will do, or if you don't want to have a Google based email you can create the account using your existing email. Follow the prompts after clicking on 'Sign in' link on the top right.
Is my understanding correct that I have to use or create a google account in any case to participate in this type of work? What if I am not willing to accept Google's Terms of Service, or to register an account with google for other reasons?
This is correct, if you decide to use the google infrastructure based server. But you don't have to, gerrit is a stand alone application which can be easily installed on the same server or on a different server in the same location where the master u-boot git server is, with you (denx.de) having full control over it.
Google hosting has advantages of providing extremely high bandwidth and reliability, but google's version of gerrit (distributed and replicated) is not a requirement, as i said, gerrit could be hosted on a linux machine.
Well, how much help and tweaking can we get, if we go with Google hosting? My views are perhaps biased based on using gerrit earlier in Android's life, but, I can't imagine us having the time to deal with admining and upgrading a server later on.
Well, if you use google hosteg gerrit, you won't have a problem with upgrading or managing the server. Some one would need to get admin rights and set it up properly (create branches per custodian, set up user groups and group permissions, etc.). I am not going to be able to do this, but I sure could help pushing issues through the Gerrit-On-Google folks, they are pretty accommodating and responsive.
Right, I'm saying the Google doing back-end management is a plus to using Gerrit, and possibly a requirement of us using gerrit. Self-hosted seems likely to be resource intensive.
And of course, given ${insert ones favorite now defunct google service} what might happen down the line if the Google hosting goes away?
This is a very valid concern and there is no guarantees. But if push comes to shove, gerrit is an open source product and it can be installed on a stand alone server (which of course would be a pain).
And can data be extracted?
[snip]
This server is not configured yet, but in general gerrit allows for three levels of reviewers - those who can just comment, those who can assign a +1 rating to the change (an equivalent of an acked by) and those who can assign a +2 rating or push the change (the custodians). There is no point in setting these up on a mirror, but if so desired, it could be done.
How can we arrange to keep the mailing list in sync?
This is a big question for which there is no good answer. Gerrit will send submitted patches in emails (limited to a configurable max patch size), but it will not accept email based reviews. So, this would involve a change in the way things done, I am just suggesting this as an alternative for consideration.
Can we at least get all reviews sent to the ML?
The problem with this is that when reviews are sent to the mailing list, they are for different custodians, trees, etc. It looks like appx. half of them applies cleanly to the master branch, the rest do not. Is there a way to tell what branch the patch is detined to by looking at the email?
A much more robust approach is to have users push patches directly, and set up branches/projects on the server, as required.
Right. But the biggest concern with this approach is that you limit reviews to everyone who knows to be interested in $foo, rather than everyone who is subscribed seeing (a hopefully useful subject in the) patch that changes $foo, and deciding to take a peek. This is why it's vital to have some way to keep the ML apprised of when new patches come in.
Pushing patches won't be hard to adapt to. Doing the reviews on a web page might noe be too hard to adapt to (I don't like that "all unified" spits out N tabs, rather than a single page with all unified diffs, but I adapted to reading one source file changes at a time pretty quick). But shifting to everyone must have notifiations and alerts or whatever setup to find out about new changes they might care about, will suck.
On Thu, Nov 14, 2013 at 7:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote:
Hello Wolfgang,
[snip]
Can you not pick up the patches directly from the mailing list? I mean, we know of the problems patchwork has (like silently dropping certain base64 / utf8 encoded messages), so we should rather try and get a more reliable feed for the patches?
this is the thing: picking up patches from patchwork is not something you'd do regularly - this is just my way of populating the review site from a single test account.
If this workflow were adopted, each user would push their patch to the gerrit server, creating a new review branch for that particular patch. In general, gerrit view of the branch matches the submitter's view of the branch - if the submitter has several patches in one branch, they will all be uploaded by gerrit to the same separate branch, maintaining the relationship between the patches.
This is my biggest concern. On the one-off to infrequent contribution side (and we do have some of that), I worry about the infrastucture hurdle here.
Sorry, I am not sure i understand what the biggest concern is: that the users would push their own patches? Why is this a problem - the patches would go into their own branches until reviewed and merged. Or did you mean something else?
I mean, it's a higher hurdle to clear. Looking at other non-Android projects, I know some folks have said "bah, not worth the effort" to push trivial things, if it must come via gerrit. So some way to scrape the ML for things that don't come in via gerrit to start with would be handy.
I think this is something one of 'known' developers will end doing and applying it to Gerrit.
On the other side, what is the gerrit equivalent of 'git send-email --compose ...', and I'm focusing on the compose side here. Or is it just another mental switch the project makes, from that to push to gerrit / compose email saying "hey, look at this"
This is how we usually do this:
- upload all patches to gerrit
- go to the web interface of the first patch in the series (by this
time gerrit would have a stack of patches showing their dependencies), click on "review" - at this point gerrit would open a form to type the cover message in
- once you finish composing the message you click on "publish
comments" and it gets sent to everybody who was picked as the reviewer, and to default addresses, if any are configured (which of course could be u-boot@lists.denx.de, for instance)
Right, and at that point we've mixed discussion of a concept with discussion of a particular change, and we're in web-only for writes. I guess (pending see below) one could just write the 0/N email separate, or in-reply-to 1/N, so that the concept discussion stays on the list and in the archives and so on.
Once thing I have to mention: gerrit is notorious for sending tons of email, while this is being worked on, in the meantime some more rigorous email filtering might be very useful.
Just how hard is it likely to be to filter things so that only:
- new patches
- reviews
get sent to the ML?
Any one can upload patches to this server after creating an account on it. Any Google account will do, or if you don't want to have a Google based email you can create the account using your existing email. Follow the prompts after clicking on 'Sign in' link on the top right.
Is my understanding correct that I have to use or create a google account in any case to participate in this type of work? What if I am not willing to accept Google's Terms of Service, or to register an account with google for other reasons?
This is correct, if you decide to use the google infrastructure based server. But you don't have to, gerrit is a stand alone application which can be easily installed on the same server or on a different server in the same location where the master u-boot git server is, with you (denx.de) having full control over it.
Google hosting has advantages of providing extremely high bandwidth and reliability, but google's version of gerrit (distributed and replicated) is not a requirement, as i said, gerrit could be hosted on a linux machine.
Well, how much help and tweaking can we get, if we go with Google hosting? My views are perhaps biased based on using gerrit earlier in Android's life, but, I can't imagine us having the time to deal with admining and upgrading a server later on.
Well, if you use google hosteg gerrit, you won't have a problem with upgrading or managing the server. Some one would need to get admin rights and set it up properly (create branches per custodian, set up user groups and group permissions, etc.). I am not going to be able to do this, but I sure could help pushing issues through the Gerrit-On-Google folks, they are pretty accommodating and responsive.
Right, I'm saying the Google doing back-end management is a plus to using Gerrit, and possibly a requirement of us using gerrit. Self-hosted seems likely to be resource intensive.
And of course, given ${insert ones favorite now defunct google service} what might happen down the line if the Google hosting goes away?
This is a very valid concern and there is no guarantees. But if push comes to shove, gerrit is an open source product and it can be installed on a stand alone server (which of course would be a pain).
And can data be extracted?
[snip]
This server is not configured yet, but in general gerrit allows for three levels of reviewers - those who can just comment, those who can assign a +1 rating to the change (an equivalent of an acked by) and those who can assign a +2 rating or push the change (the custodians). There is no point in setting these up on a mirror, but if so desired, it could be done.
How can we arrange to keep the mailing list in sync?
This is a big question for which there is no good answer. Gerrit will send submitted patches in emails (limited to a configurable max patch size), but it will not accept email based reviews. So, this would involve a change in the way things done, I am just suggesting this as an alternative for consideration.
Can we at least get all reviews sent to the ML?
The problem with this is that when reviews are sent to the mailing list, they are for different custodians, trees, etc. It looks like appx. half of them applies cleanly to the master branch, the rest do not. Is there a way to tell what branch the patch is detined to by looking at the email?
A much more robust approach is to have users push patches directly, and set up branches/projects on the server, as required.
Right. But the biggest concern with this approach is that you limit reviews to everyone who knows to be interested in $foo, rather than everyone who is subscribed seeing (a hopefully useful subject in the) patch that changes $foo, and deciding to take a peek. This is why it's vital to have some way to keep the ML apprised of when new patches come in.
Pushing patches won't be hard to adapt to. Doing the reviews on a web page might noe be too hard to adapt to (I don't like that "all unified" spits out N tabs, rather than a single page with all unified diffs, but I adapted to reading one source file changes at a time pretty quick). But shifting to everyone must have notifiations and alerts or whatever setup to find out about new changes they might care about, will suck.
Agreed.
On Thu, Nov 14, 2013 at 07:22:23PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 7:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote:
Hello Wolfgang,
[snip]
Can you not pick up the patches directly from the mailing list? I mean, we know of the problems patchwork has (like silently dropping certain base64 / utf8 encoded messages), so we should rather try and get a more reliable feed for the patches?
this is the thing: picking up patches from patchwork is not something you'd do regularly - this is just my way of populating the review site from a single test account.
If this workflow were adopted, each user would push their patch to the gerrit server, creating a new review branch for that particular patch. In general, gerrit view of the branch matches the submitter's view of the branch - if the submitter has several patches in one branch, they will all be uploaded by gerrit to the same separate branch, maintaining the relationship between the patches.
This is my biggest concern. On the one-off to infrequent contribution side (and we do have some of that), I worry about the infrastucture hurdle here.
Sorry, I am not sure i understand what the biggest concern is: that the users would push their own patches? Why is this a problem - the patches would go into their own branches until reviewed and merged. Or did you mean something else?
I mean, it's a higher hurdle to clear. Looking at other non-Android projects, I know some folks have said "bah, not worth the effort" to push trivial things, if it must come via gerrit. So some way to scrape the ML for things that don't come in via gerrit to start with would be handy.
I think this is something one of 'known' developers will end doing and applying it to Gerrit.
I suspect you're right, and that it would end up being me. So I'm fishing for something else, at least a little bit longer.
On Thu, Nov 14, 2013 at 1:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote:
Hello Wolfgang,
[snip]
Can you not pick up the patches directly from the mailing list? I mean, we know of the problems patchwork has (like silently dropping certain base64 / utf8 encoded messages), so we should rather try and get a more reliable feed for the patches?
this is the thing: picking up patches from patchwork is not something you'd do regularly - this is just my way of populating the review site from a single test account.
If this workflow were adopted, each user would push their patch to the gerrit server, creating a new review branch for that particular patch. In general, gerrit view of the branch matches the submitter's view of the branch - if the submitter has several patches in one branch, they will all be uploaded by gerrit to the same separate branch, maintaining the relationship between the patches.
This is my biggest concern. On the one-off to infrequent contribution side (and we do have some of that), I worry about the infrastucture hurdle here.
Sorry, I am not sure i understand what the biggest concern is: that the users would push their own patches? Why is this a problem - the patches would go into their own branches until reviewed and merged. Or did you mean something else?
I mean, it's a higher hurdle to clear. Looking at other non-Android projects, I know some folks have said "bah, not worth the effort" to push trivial things, if it must come via gerrit. So some way to scrape the ML for things that don't come in via gerrit to start with would be handy.
I guess if the submitters are still expected to do both, ML and gerrit, then yes, but the idea is that gerrit is the way to go, mailing list is whatever gerrit generates. This way sending an email to the mailing list or running 'git push' require pretty much similar efforts
and BTW, I should have mentioned this earlier, there is a linux command line based utility to manipulate patch states on the gerrit server, I put its help output here: http://pastie.org/8481244
On the other side, what is the gerrit equivalent of 'git send-email --compose ...', and I'm focusing on the compose side here. Or is it just another mental switch the project makes, from that to push to gerrit / compose email saying "hey, look at this"
This is how we usually do this:
- upload all patches to gerrit
- go to the web interface of the first patch in the series (by this
time gerrit would have a stack of patches showing their dependencies), click on "review" - at this point gerrit would open a form to type the cover message in
- once you finish composing the message you click on "publish
comments" and it gets sent to everybody who was picked as the reviewer, and to default addresses, if any are configured (which of course could be u-boot@lists.denx.de, for instance)
Right, and at that point we've mixed discussion of a concept with discussion of a particular change, and we're in web-only for writes. I guess (pending see below) one could just write the 0/N email separate, or in-reply-to 1/N, so that the concept discussion stays on the list and in the archives and so on.
Once thing I have to mention: gerrit is notorious for sending tons of email, while this is being worked on, in the meantime some more rigorous email filtering might be very useful.
Just how hard is it likely to be to filter things so that only:
- new patches
- reviews
get sent to the ML?
It is not hard, it's just a pain that it has to be done by every recipient (as opposed to cutting the emails on the server). We are working with gerrit community on that, but it goes quite slow.
Any one can upload patches to this server after creating an account on it. Any Google account will do, or if you don't want to have a Google based email you can create the account using your existing email. Follow the prompts after clicking on 'Sign in' link on the top right.
Is my understanding correct that I have to use or create a google account in any case to participate in this type of work? What if I am not willing to accept Google's Terms of Service, or to register an account with google for other reasons?
This is correct, if you decide to use the google infrastructure based server. But you don't have to, gerrit is a stand alone application which can be easily installed on the same server or on a different server in the same location where the master u-boot git server is, with you (denx.de) having full control over it.
Google hosting has advantages of providing extremely high bandwidth and reliability, but google's version of gerrit (distributed and replicated) is not a requirement, as i said, gerrit could be hosted on a linux machine.
Well, how much help and tweaking can we get, if we go with Google hosting? My views are perhaps biased based on using gerrit earlier in Android's life, but, I can't imagine us having the time to deal with admining and upgrading a server later on.
Well, if you use google hosteg gerrit, you won't have a problem with upgrading or managing the server. Some one would need to get admin rights and set it up properly (create branches per custodian, set up user groups and group permissions, etc.). I am not going to be able to do this, but I sure could help pushing issues through the Gerrit-On-Google folks, they are pretty accommodating and responsive.
Right, I'm saying the Google doing back-end management is a plus to using Gerrit, and possibly a requirement of us using gerrit. Self-hosted seems likely to be resource intensive.
Agreed. But using google services would involve creating google accounts (even when using existing email addresses).
And of course, given ${insert ones favorite now defunct google service} what might happen down the line if the Google hosting goes away?
This is a very valid concern and there is no guarantees. But if push comes to shove, gerrit is an open source product and it can be installed on a stand alone server (which of course would be a pain).
And can data be extracted?
The merged patches are in their appropriate branches, presumably there is a master git server somewhere which periodically syncs up with gerrit server, and it is the trusted source.
The emails with comments would have been emailed at review time, lost would be patches in flight and abandoned or modified patches from earlier reviews, is this acceptable.
[snip]
This server is not configured yet, but in general gerrit allows for three levels of reviewers - those who can just comment, those who can assign a +1 rating to the change (an equivalent of an acked by) and those who can assign a +2 rating or push the change (the custodians). There is no point in setting these up on a mirror, but if so desired, it could be done.
How can we arrange to keep the mailing list in sync?
This is a big question for which there is no good answer. Gerrit will send submitted patches in emails (limited to a configurable max patch size), but it will not accept email based reviews. So, this would involve a change in the way things done, I am just suggesting this as an alternative for consideration.
Can we at least get all reviews sent to the ML?
The problem with this is that when reviews are sent to the mailing list, they are for different custodians, trees, etc. It looks like appx. half of them applies cleanly to the master branch, the rest do not. Is there a way to tell what branch the patch is detined to by looking at the email?
A much more robust approach is to have users push patches directly, and set up branches/projects on the server, as required.
Right. But the biggest concern with this approach is that you limit reviews to everyone who knows to be interested in $foo, rather than everyone who is subscribed seeing (a hopefully useful subject in the) patch that changes $foo, and deciding to take a peek. This is why it's vital to have some way to keep the ML apprised of when new patches come in.
But the gerrit server will be sending all patches out, one of the destinations would be the group mailing list - is this not good enough?
Pushing patches won't be hard to adapt to. Doing the reviews on a web page might noe be too hard to adapt to (I don't like that "all unified" spits out N tabs, rather than a single page with all unified diffs, but I adapted to reading one source file changes at a time pretty quick).
What I usually do when I need to review a chain of related patches on gerrit is go to the top patch in the chain, and then clock on the 'pull' tab in the download box. This generates a command line which, if run locally, would bring the entire chain of patches to your git repository. Than one can examine all patches together locally and comment on gerrit.
But shifting to everyone must have notifiations and alerts or whatever setup to find out about new changes they might care about, will suck.
again, the notifications with patch descriptions and diffs (to a certain extent) would be sent to the list, this should be enough, right?
--vb
-- Tom
Is there an existing mailing list for some other open source project that uses a gerrit server in something like what would be a model for the way U-Boot would use it?
It might be instructive to watch that list to see how the interaction with the developers goes.
Thanks, Jim
On 11/14/2013 03:43 PM, Vadim Bendebury (вб) wrote:
On Thu, Nov 14, 2013 at 1:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote:
Hello Wolfgang,
[snip]
Can you not pick up the patches directly from the mailing list? I mean, we know of the problems patchwork has (like silently dropping certain base64 / utf8 encoded messages), so we should rather try and get a more reliable feed for the patches?
this is the thing: picking up patches from patchwork is not something you'd do regularly - this is just my way of populating the review site from a single test account.
If this workflow were adopted, each user would push their patch to the gerrit server, creating a new review branch for that particular patch. In general, gerrit view of the branch matches the submitter's view of the branch - if the submitter has several patches in one branch, they will all be uploaded by gerrit to the same separate branch, maintaining the relationship between the patches.
This is my biggest concern. On the one-off to infrequent contribution side (and we do have some of that), I worry about the infrastucture hurdle here.
Sorry, I am not sure i understand what the biggest concern is: that the users would push their own patches? Why is this a problem - the patches would go into their own branches until reviewed and merged. Or did you mean something else?
I mean, it's a higher hurdle to clear. Looking at other non-Android projects, I know some folks have said "bah, not worth the effort" to push trivial things, if it must come via gerrit. So some way to scrape the ML for things that don't come in via gerrit to start with would be handy.
I guess if the submitters are still expected to do both, ML and gerrit, then yes, but the idea is that gerrit is the way to go, mailing list is whatever gerrit generates. This way sending an email to the mailing list or running 'git push' require pretty much similar efforts
and BTW, I should have mentioned this earlier, there is a linux command line based utility to manipulate patch states on the gerrit server, I put its help output here: http://pastie.org/8481244
On the other side, what is the gerrit equivalent of 'git send-email --compose ...', and I'm focusing on the compose side here. Or is it just another mental switch the project makes, from that to push to gerrit / compose email saying "hey, look at this"
This is how we usually do this:
- upload all patches to gerrit
- go to the web interface of the first patch in the series (by this
time gerrit would have a stack of patches showing their dependencies), click on "review" - at this point gerrit would open a form to type the cover message in
- once you finish composing the message you click on "publish
comments" and it gets sent to everybody who was picked as the reviewer, and to default addresses, if any are configured (which of course could be u-boot@lists.denx.de, for instance)
Right, and at that point we've mixed discussion of a concept with discussion of a particular change, and we're in web-only for writes. I guess (pending see below) one could just write the 0/N email separate, or in-reply-to 1/N, so that the concept discussion stays on the list and in the archives and so on.
Once thing I have to mention: gerrit is notorious for sending tons of email, while this is being worked on, in the meantime some more rigorous email filtering might be very useful.
Just how hard is it likely to be to filter things so that only:
- new patches
- reviews
get sent to the ML?
It is not hard, it's just a pain that it has to be done by every recipient (as opposed to cutting the emails on the server). We are working with gerrit community on that, but it goes quite slow.
> Any one can upload patches to this server after creating an account on > it. Any Google account will do, or if you don't want to have a Google > based email you can create the account using your existing email. > Follow the prompts after clicking on 'Sign in' link on the top right.
Is my understanding correct that I have to use or create a google account in any case to participate in this type of work? What if I am not willing to accept Google's Terms of Service, or to register an account with google for other reasons?
This is correct, if you decide to use the google infrastructure based server. But you don't have to, gerrit is a stand alone application which can be easily installed on the same server or on a different server in the same location where the master u-boot git server is, with you (denx.de) having full control over it.
Google hosting has advantages of providing extremely high bandwidth and reliability, but google's version of gerrit (distributed and replicated) is not a requirement, as i said, gerrit could be hosted on a linux machine.
Well, how much help and tweaking can we get, if we go with Google hosting? My views are perhaps biased based on using gerrit earlier in Android's life, but, I can't imagine us having the time to deal with admining and upgrading a server later on.
Well, if you use google hosteg gerrit, you won't have a problem with upgrading or managing the server. Some one would need to get admin rights and set it up properly (create branches per custodian, set up user groups and group permissions, etc.). I am not going to be able to do this, but I sure could help pushing issues through the Gerrit-On-Google folks, they are pretty accommodating and responsive.
Right, I'm saying the Google doing back-end management is a plus to using Gerrit, and possibly a requirement of us using gerrit. Self-hosted seems likely to be resource intensive.
Agreed. But using google services would involve creating google accounts (even when using existing email addresses).
And of course, given ${insert ones favorite now defunct google service} what might happen down the line if the Google hosting goes away?
This is a very valid concern and there is no guarantees. But if push comes to shove, gerrit is an open source product and it can be installed on a stand alone server (which of course would be a pain).
And can data be extracted?
The merged patches are in their appropriate branches, presumably there is a master git server somewhere which periodically syncs up with gerrit server, and it is the trusted source.
The emails with comments would have been emailed at review time, lost would be patches in flight and abandoned or modified patches from earlier reviews, is this acceptable.
[snip]
> This server is not configured yet, but in general gerrit allows for > three levels of reviewers - those who can just comment, those who can > assign a +1 rating to the change (an equivalent of an acked by) and > those who can assign a +2 rating or push the change (the custodians). > There is no point in setting these up on a mirror, but if so desired, > it could be done.
How can we arrange to keep the mailing list in sync?
This is a big question for which there is no good answer. Gerrit will send submitted patches in emails (limited to a configurable max patch size), but it will not accept email based reviews. So, this would involve a change in the way things done, I am just suggesting this as an alternative for consideration.
Can we at least get all reviews sent to the ML?
The problem with this is that when reviews are sent to the mailing list, they are for different custodians, trees, etc. It looks like appx. half of them applies cleanly to the master branch, the rest do not. Is there a way to tell what branch the patch is detined to by looking at the email?
A much more robust approach is to have users push patches directly, and set up branches/projects on the server, as required.
Right. But the biggest concern with this approach is that you limit reviews to everyone who knows to be interested in $foo, rather than everyone who is subscribed seeing (a hopefully useful subject in the) patch that changes $foo, and deciding to take a peek. This is why it's vital to have some way to keep the ML apprised of when new patches come in.
But the gerrit server will be sending all patches out, one of the destinations would be the group mailing list - is this not good enough?
Pushing patches won't be hard to adapt to. Doing the reviews on a web page might noe be too hard to adapt to (I don't like that "all unified" spits out N tabs, rather than a single page with all unified diffs, but I adapted to reading one source file changes at a time pretty quick).
What I usually do when I need to review a chain of related patches on gerrit is go to the top patch in the chain, and then clock on the 'pull' tab in the download box. This generates a command line which, if run locally, would bring the entire chain of patches to your git repository. Than one can examine all patches together locally and comment on gerrit.
But shifting to everyone must have notifiations and alerts or whatever setup to find out about new changes they might care about, will suck.
again, the notifications with patch descriptions and diffs (to a certain extent) would be sent to the list, this should be enough, right?
--vb
-- Tom
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 15-11-13 14:55, James Chargin wrote:
Is there an existing mailing list for some other open source project that uses a gerrit server in something like what would be a model for the way U-Boot would use it?
Coreboot?
oliver
It might be instructive to watch that list to see how the interaction with the developers goes.
Thanks, Jim
On 11/14/2013 03:43 PM, Vadim Bendebury (вб) wrote:
On Thu, Nov 14, 2013 at 1:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote:
Hello Wolfgang,
[snip]
> Can you not pick up the patches directly from the mailing list? I > mean, we know of the problems patchwork has (like silently dropping > certain base64 / utf8 encoded messages), so we should rather try and > get a more reliable feed for the patches? >
this is the thing: picking up patches from patchwork is not something you'd do regularly - this is just my way of populating the review site from a single test account.
If this workflow were adopted, each user would push their patch to the gerrit server, creating a new review branch for that particular patch. In general, gerrit view of the branch matches the submitter's view of the branch - if the submitter has several patches in one branch, they will all be uploaded by gerrit to the same separate branch, maintaining the relationship between the patches.
This is my biggest concern. On the one-off to infrequent contribution side (and we do have some of that), I worry about the infrastucture hurdle here.
Sorry, I am not sure i understand what the biggest concern is: that the users would push their own patches? Why is this a problem - the patches would go into their own branches until reviewed and merged. Or did you mean something else?
I mean, it's a higher hurdle to clear. Looking at other non-Android projects, I know some folks have said "bah, not worth the effort" to push trivial things, if it must come via gerrit. So some way to scrape the ML for things that don't come in via gerrit to start with would be handy.
I guess if the submitters are still expected to do both, ML and gerrit, then yes, but the idea is that gerrit is the way to go, mailing list is whatever gerrit generates. This way sending an email to the mailing list or running 'git push' require pretty much similar efforts
and BTW, I should have mentioned this earlier, there is a linux command line based utility to manipulate patch states on the gerrit server, I put its help output here: http://pastie.org/8481244
On the other side, what is the gerrit equivalent of 'git send-email --compose ...', and I'm focusing on the compose side here. Or is it just another mental switch the project makes, from that to push to gerrit / compose email saying "hey, look at this"
This is how we usually do this:
- upload all patches to gerrit
- go to the web interface of the first patch in the series (by this
time gerrit would have a stack of patches showing their dependencies), click on "review" - at this point gerrit would open a form to type the cover message in
- once you finish composing the message you click on "publish
comments" and it gets sent to everybody who was picked as the reviewer, and to default addresses, if any are configured (which of course could be u-boot@lists.denx.de, for instance)
Right, and at that point we've mixed discussion of a concept with discussion of a particular change, and we're in web-only for writes. I guess (pending see below) one could just write the 0/N email separate, or in-reply-to 1/N, so that the concept discussion stays on the list and in the archives and so on.
Once thing I have to mention: gerrit is notorious for sending tons of email, while this is being worked on, in the meantime some more rigorous email filtering might be very useful.
Just how hard is it likely to be to filter things so that only:
- new patches
- reviews
get sent to the ML?
It is not hard, it's just a pain that it has to be done by every recipient (as opposed to cutting the emails on the server). We are working with gerrit community on that, but it goes quite slow.
>> Any one can upload patches to this server after creating an >> account on >> it. Any Google account will do, or if you don't want to have a >> Google >> based email you can create the account using your existing email. >> Follow the prompts after clicking on 'Sign in' link on the top >> right. > > Is my understanding correct that I have to use or create a google > account in any case to participate in this type of work? What if > I am > not willing to accept Google's Terms of Service, or to register an > account with google for other reasons? >
This is correct, if you decide to use the google infrastructure based server. But you don't have to, gerrit is a stand alone application which can be easily installed on the same server or on a different server in the same location where the master u-boot git server is, with you (denx.de) having full control over it.
Google hosting has advantages of providing extremely high bandwidth and reliability, but google's version of gerrit (distributed and replicated) is not a requirement, as i said, gerrit could be hosted on a linux machine.
Well, how much help and tweaking can we get, if we go with Google hosting? My views are perhaps biased based on using gerrit earlier in Android's life, but, I can't imagine us having the time to deal with admining and upgrading a server later on.
Well, if you use google hosteg gerrit, you won't have a problem with upgrading or managing the server. Some one would need to get admin rights and set it up properly (create branches per custodian, set up user groups and group permissions, etc.). I am not going to be able to do this, but I sure could help pushing issues through the Gerrit-On-Google folks, they are pretty accommodating and responsive.
Right, I'm saying the Google doing back-end management is a plus to using Gerrit, and possibly a requirement of us using gerrit. Self-hosted seems likely to be resource intensive.
Agreed. But using google services would involve creating google accounts (even when using existing email addresses).
And of course, given ${insert ones favorite now defunct google service} what might happen down the line if the Google hosting goes away?
This is a very valid concern and there is no guarantees. But if push comes to shove, gerrit is an open source product and it can be installed on a stand alone server (which of course would be a pain).
And can data be extracted?
The merged patches are in their appropriate branches, presumably there is a master git server somewhere which periodically syncs up with gerrit server, and it is the trusted source.
The emails with comments would have been emailed at review time, lost would be patches in flight and abandoned or modified patches from earlier reviews, is this acceptable.
[snip]
>> This server is not configured yet, but in general gerrit allows for >> three levels of reviewers - those who can just comment, those >> who can >> assign a +1 rating to the change (an equivalent of an acked by) and >> those who can assign a +2 rating or push the change (the >> custodians). >> There is no point in setting these up on a mirror, but if so >> desired, >> it could be done. > > How can we arrange to keep the mailing list in sync? >
This is a big question for which there is no good answer. Gerrit will send submitted patches in emails (limited to a configurable max patch size), but it will not accept email based reviews. So, this would involve a change in the way things done, I am just suggesting this as an alternative for consideration.
Can we at least get all reviews sent to the ML?
The problem with this is that when reviews are sent to the mailing list, they are for different custodians, trees, etc. It looks like appx. half of them applies cleanly to the master branch, the rest do not. Is there a way to tell what branch the patch is detined to by looking at the email?
A much more robust approach is to have users push patches directly, and set up branches/projects on the server, as required.
Right. But the biggest concern with this approach is that you limit reviews to everyone who knows to be interested in $foo, rather than everyone who is subscribed seeing (a hopefully useful subject in the) patch that changes $foo, and deciding to take a peek. This is why it's vital to have some way to keep the ML apprised of when new patches come in.
But the gerrit server will be sending all patches out, one of the destinations would be the group mailing list - is this not good enough?
Pushing patches won't be hard to adapt to. Doing the reviews on a web page might noe be too hard to adapt to (I don't like that "all unified" spits out N tabs, rather than a single page with all unified diffs, but I adapted to reading one source file changes at a time pretty quick).
What I usually do when I need to review a chain of related patches on gerrit is go to the top patch in the chain, and then clock on the 'pull' tab in the download box. This generates a command line which, if run locally, would bring the entire chain of patches to your git repository. Than one can examine all patches together locally and comment on gerrit.
But shifting to everyone must have notifiations and alerts or whatever setup to find out about new changes they might care about, will suck.
again, the notifications with patch descriptions and diffs (to a certain extent) would be sent to the list, this should be enough, right?
--vb
-- Tom
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Il 15/11/2013 15:12, Oliver Schinagl ha scritto:
On 15-11-13 14:55, James Chargin wrote:
Is there an existing mailing list for some other open source project that uses a gerrit server in something like what would be a model for the way U-Boot would use it?
Coreboot?
OpenOCD
oliver
It might be instructive to watch that list to see how the interaction with the developers goes.
Thanks, Jim
On 11/14/2013 03:43 PM, Vadim Bendebury (вб) wrote:
On Thu, Nov 14, 2013 at 1:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote:
> Hello Wolfgang, [snip] >> Can you not pick up the patches directly from the mailing list? I >> mean, we know of the problems patchwork has (like silently >> dropping >> certain base64 / utf8 encoded messages), so we should rather >> try and >> get a more reliable feed for the patches? >> > > this is the thing: picking up patches from patchwork is not > something > you'd do regularly - this is just my way of populating the review > site > from a single test account. > > If this workflow were adopted, each user would push their patch to > the > gerrit server, creating a new review branch for that particular > patch. > In general, gerrit view of the branch matches the submitter's > view of > the branch - if the submitter has several patches in one branch, > they > will all be uploaded by gerrit to the same separate branch, > maintaining the relationship between the patches.
This is my biggest concern. On the one-off to infrequent contribution side (and we do have some of that), I worry about the infrastucture hurdle here.
Sorry, I am not sure i understand what the biggest concern is: that the users would push their own patches? Why is this a problem - the patches would go into their own branches until reviewed and merged. Or did you mean something else?
I mean, it's a higher hurdle to clear. Looking at other non-Android projects, I know some folks have said "bah, not worth the effort" to push trivial things, if it must come via gerrit. So some way to scrape the ML for things that don't come in via gerrit to start with would be handy.
I guess if the submitters are still expected to do both, ML and gerrit, then yes, but the idea is that gerrit is the way to go, mailing list is whatever gerrit generates. This way sending an email to the mailing list or running 'git push' require pretty much similar efforts
and BTW, I should have mentioned this earlier, there is a linux command line based utility to manipulate patch states on the gerrit server, I put its help output here: http://pastie.org/8481244
On the other side, what is the gerrit equivalent of 'git send-email --compose ...', and I'm focusing on the compose side here. Or is it just another mental switch the project makes, from that to push to gerrit / compose email saying "hey, look at this"
This is how we usually do this:
- upload all patches to gerrit
- go to the web interface of the first patch in the series (by this
time gerrit would have a stack of patches showing their dependencies), click on "review" - at this point gerrit would open a form to type the cover message in
- once you finish composing the message you click on "publish
comments" and it gets sent to everybody who was picked as the reviewer, and to default addresses, if any are configured (which of course could be u-boot@lists.denx.de, for instance)
Right, and at that point we've mixed discussion of a concept with discussion of a particular change, and we're in web-only for writes. I guess (pending see below) one could just write the 0/N email separate, or in-reply-to 1/N, so that the concept discussion stays on the list and in the archives and so on.
Once thing I have to mention: gerrit is notorious for sending tons of email, while this is being worked on, in the meantime some more rigorous email filtering might be very useful.
Just how hard is it likely to be to filter things so that only:
- new patches
- reviews
get sent to the ML?
It is not hard, it's just a pain that it has to be done by every recipient (as opposed to cutting the emails on the server). We are working with gerrit community on that, but it goes quite slow.
>>> Any one can upload patches to this server after creating an >>> account on >>> it. Any Google account will do, or if you don't want to have a >>> Google >>> based email you can create the account using your existing email. >>> Follow the prompts after clicking on 'Sign in' link on the top >>> right. >> >> Is my understanding correct that I have to use or create a google >> account in any case to participate in this type of work? What if >> I am >> not willing to accept Google's Terms of Service, or to register an >> account with google for other reasons? >> > > This is correct, if you decide to use the google infrastructure > based > server. But you don't have to, gerrit is a stand alone application > which can be easily installed on the same server or on a different > server in the same location where the master u-boot git server is, > with you (denx.de) having full control over it. > > Google hosting has advantages of providing extremely high bandwidth > and reliability, but google's version of gerrit (distributed and > replicated) is not a requirement, as i said, gerrit could be > hosted on > a linux machine.
Well, how much help and tweaking can we get, if we go with Google hosting? My views are perhaps biased based on using gerrit earlier in Android's life, but, I can't imagine us having the time to deal with admining and upgrading a server later on.
Well, if you use google hosteg gerrit, you won't have a problem with upgrading or managing the server. Some one would need to get admin rights and set it up properly (create branches per custodian, set up user groups and group permissions, etc.). I am not going to be able to do this, but I sure could help pushing issues through the Gerrit-On-Google folks, they are pretty accommodating and responsive.
Right, I'm saying the Google doing back-end management is a plus to using Gerrit, and possibly a requirement of us using gerrit. Self-hosted seems likely to be resource intensive.
Agreed. But using google services would involve creating google accounts (even when using existing email addresses).
And of course, given ${insert ones favorite now defunct google service} what might happen down the line if the Google hosting goes away?
This is a very valid concern and there is no guarantees. But if push comes to shove, gerrit is an open source product and it can be installed on a stand alone server (which of course would be a pain).
And can data be extracted?
The merged patches are in their appropriate branches, presumably there is a master git server somewhere which periodically syncs up with gerrit server, and it is the trusted source.
The emails with comments would have been emailed at review time, lost would be patches in flight and abandoned or modified patches from earlier reviews, is this acceptable.
[snip] >>> This server is not configured yet, but in general gerrit >>> allows for >>> three levels of reviewers - those who can just comment, those >>> who can >>> assign a +1 rating to the change (an equivalent of an acked >>> by) and >>> those who can assign a +2 rating or push the change (the >>> custodians). >>> There is no point in setting these up on a mirror, but if so >>> desired, >>> it could be done. >> >> How can we arrange to keep the mailing list in sync? >> > > This is a big question for which there is no good answer. Gerrit > will > send submitted patches in emails (limited to a configurable max > patch > size), but it will not accept email based reviews. So, this would > involve a change in the way things done, I am just suggesting > this as > an alternative for consideration.
Can we at least get all reviews sent to the ML?
The problem with this is that when reviews are sent to the mailing list, they are for different custodians, trees, etc. It looks like appx. half of them applies cleanly to the master branch, the rest do not. Is there a way to tell what branch the patch is detined to by looking at the email?
A much more robust approach is to have users push patches directly, and set up branches/projects on the server, as required.
Right. But the biggest concern with this approach is that you limit reviews to everyone who knows to be interested in $foo, rather than everyone who is subscribed seeing (a hopefully useful subject in the) patch that changes $foo, and deciding to take a peek. This is why it's vital to have some way to keep the ML apprised of when new patches come in.
But the gerrit server will be sending all patches out, one of the destinations would be the group mailing list - is this not good enough?
Pushing patches won't be hard to adapt to. Doing the reviews on a web page might noe be too hard to adapt to (I don't like that "all unified" spits out N tabs, rather than a single page with all unified diffs, but I adapted to reading one source file changes at a time pretty quick).
What I usually do when I need to review a chain of related patches on gerrit is go to the top patch in the chain, and then clock on the 'pull' tab in the download box. This generates a command line which, if run locally, would bring the entire chain of patches to your git repository. Than one can examine all patches together locally and comment on gerrit.
But shifting to everyone must have notifiations and alerts or whatever setup to find out about new changes they might care about, will suck.
again, the notifications with patch descriptions and diffs (to a certain extent) would be sent to the list, this should be enough, right?
--vb
-- Tom
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Thu, Nov 14, 2013 at 03:43:03PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 1:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote:
Hello Wolfgang,
[snip]
Can you not pick up the patches directly from the mailing list? I mean, we know of the problems patchwork has (like silently dropping certain base64 / utf8 encoded messages), so we should rather try and get a more reliable feed for the patches?
this is the thing: picking up patches from patchwork is not something you'd do regularly - this is just my way of populating the review site from a single test account.
If this workflow were adopted, each user would push their patch to the gerrit server, creating a new review branch for that particular patch. In general, gerrit view of the branch matches the submitter's view of the branch - if the submitter has several patches in one branch, they will all be uploaded by gerrit to the same separate branch, maintaining the relationship between the patches.
This is my biggest concern. On the one-off to infrequent contribution side (and we do have some of that), I worry about the infrastucture hurdle here.
Sorry, I am not sure i understand what the biggest concern is: that the users would push their own patches? Why is this a problem - the patches would go into their own branches until reviewed and merged. Or did you mean something else?
I mean, it's a higher hurdle to clear. Looking at other non-Android projects, I know some folks have said "bah, not worth the effort" to push trivial things, if it must come via gerrit. So some way to scrape the ML for things that don't come in via gerrit to start with would be handy.
I guess if the submitters are still expected to do both, ML and gerrit, then yes, but the idea is that gerrit is the way to go, mailing list is whatever gerrit generates. This way sending an email to the mailing list or running 'git push' require pretty much similar efforts
No, what I mean is, for the casual developer, having to setup a few things just to post a patch might be too high a hurdle to bother with. I suspect as Otavio suggested, people that post patches and don't have a gerrit account (in other words, the occasional or lone bugfix contributor), we'll just have to pick up, integrate it by hand, into gerrit.
> Any one can upload patches to this server after creating an account on > it. Any Google account will do, or if you don't want to have a Google > based email you can create the account using your existing email. > Follow the prompts after clicking on 'Sign in' link on the top right.
Is my understanding correct that I have to use or create a google account in any case to participate in this type of work? What if I am not willing to accept Google's Terms of Service, or to register an account with google for other reasons?
This is correct, if you decide to use the google infrastructure based server. But you don't have to, gerrit is a stand alone application which can be easily installed on the same server or on a different server in the same location where the master u-boot git server is, with you (denx.de) having full control over it.
Google hosting has advantages of providing extremely high bandwidth and reliability, but google's version of gerrit (distributed and replicated) is not a requirement, as i said, gerrit could be hosted on a linux machine.
Well, how much help and tweaking can we get, if we go with Google hosting? My views are perhaps biased based on using gerrit earlier in Android's life, but, I can't imagine us having the time to deal with admining and upgrading a server later on.
Well, if you use google hosteg gerrit, you won't have a problem with upgrading or managing the server. Some one would need to get admin rights and set it up properly (create branches per custodian, set up user groups and group permissions, etc.). I am not going to be able to do this, but I sure could help pushing issues through the Gerrit-On-Google folks, they are pretty accommodating and responsive.
Right, I'm saying the Google doing back-end management is a plus to using Gerrit, and possibly a requirement of us using gerrit. Self-hosted seems likely to be resource intensive.
Agreed. But using google services would involve creating google accounts (even when using existing email addresses).
So, to be clear, if we go google hosted, the auth must be done via google?
[snip]
> This server is not configured yet, but in general gerrit allows for > three levels of reviewers - those who can just comment, those who can > assign a +1 rating to the change (an equivalent of an acked by) and > those who can assign a +2 rating or push the change (the custodians). > There is no point in setting these up on a mirror, but if so desired, > it could be done.
How can we arrange to keep the mailing list in sync?
This is a big question for which there is no good answer. Gerrit will send submitted patches in emails (limited to a configurable max patch size), but it will not accept email based reviews. So, this would involve a change in the way things done, I am just suggesting this as an alternative for consideration.
Can we at least get all reviews sent to the ML?
The problem with this is that when reviews are sent to the mailing list, they are for different custodians, trees, etc. It looks like appx. half of them applies cleanly to the master branch, the rest do not. Is there a way to tell what branch the patch is detined to by looking at the email?
A much more robust approach is to have users push patches directly, and set up branches/projects on the server, as required.
Right. But the biggest concern with this approach is that you limit reviews to everyone who knows to be interested in $foo, rather than everyone who is subscribed seeing (a hopefully useful subject in the) patch that changes $foo, and deciding to take a peek. This is why it's vital to have some way to keep the ML apprised of when new patches come in.
But the gerrit server will be sending all patches out, one of the destinations would be the group mailing list - is this not good enough?
No, true, I guess that should cover it.
Pushing patches won't be hard to adapt to. Doing the reviews on a web page might noe be too hard to adapt to (I don't like that "all unified" spits out N tabs, rather than a single page with all unified diffs, but I adapted to reading one source file changes at a time pretty quick).
What I usually do when I need to review a chain of related patches on gerrit is go to the top patch in the chain, and then clock on the 'pull' tab in the download box. This generates a command line which, if run locally, would bring the entire chain of patches to your git repository. Than one can examine all patches together locally and comment on gerrit.
But that's a step backwards. Is there a feature request for gerrit somewhere I can go star for "show all Unified in single window" somehow? It's actually a disadvantage if I can't just see as I'm reviewing along how a symbol is used and I need to tab around between windows, or bring everything locally, git log -p to read, then fire up gerrit for the real review.
On 15 November 2013 21:08, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 03:43:03PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 1:17 PM, Tom Rini trini@ti.com wrote:
On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury (????) wrote:
On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote:
Hello Wolfgang,
[snip]
> Can you not pick up the patches directly from the mailing list? I > mean, we know of the problems patchwork has (like silently dropping > certain base64 / utf8 encoded messages), so we should rather try and > get a more reliable feed for the patches? >
this is the thing: picking up patches from patchwork is not something you'd do regularly - this is just my way of populating the review site from a single test account.
If this workflow were adopted, each user would push their patch to the gerrit server, creating a new review branch for that particular patch. In general, gerrit view of the branch matches the submitter's view of the branch - if the submitter has several patches in one branch, they will all be uploaded by gerrit to the same separate branch, maintaining the relationship between the patches.
This is my biggest concern. On the one-off to infrequent contribution side (and we do have some of that), I worry about the infrastucture hurdle here.
Sorry, I am not sure i understand what the biggest concern is: that the users would push their own patches? Why is this a problem - the patches would go into their own branches until reviewed and merged. Or did you mean something else?
I mean, it's a higher hurdle to clear. Looking at other non-Android projects, I know some folks have said "bah, not worth the effort" to push trivial things, if it must come via gerrit. So some way to scrape the ML for things that don't come in via gerrit to start with would be handy.
I guess if the submitters are still expected to do both, ML and gerrit, then yes, but the idea is that gerrit is the way to go, mailing list is whatever gerrit generates. This way sending an email to the mailing list or running 'git push' require pretty much similar efforts
No, what I mean is, for the casual developer, having to setup a few things just to post a patch might be too high a hurdle to bother with. I suspect as Otavio suggested, people that post patches and don't have a gerrit account (in other words, the occasional or lone bugfix contributor), we'll just have to pick up, integrate it by hand, into gerrit.
You need patch(1) to generate a patch and subscribe to mailing list to post it.
To upload to gerrit you need git and subscribe to gerrit.
Two things one way or the other.
Michal
On Fri, Nov 15, 2013 at 10:00:00PM +0100, Michal Suchanek wrote:
On 15 November 2013 21:08, Tom Rini trini@ti.com wrote:
[snip]
No, what I mean is, for the casual developer, having to setup a few things just to post a patch might be too high a hurdle to bother with. I suspect as Otavio suggested, people that post patches and don't have a gerrit account (in other words, the occasional or lone bugfix contributor), we'll just have to pick up, integrate it by hand, into gerrit.
You need patch(1) to generate a patch and subscribe to mailing list to post it.
To upload to gerrit you need git and subscribe to gerrit.
Two things one way or the other.
If you have a git clone of the repo (like most folks I think), you just need to send it. non-spam from non-subscribers are approved. To use gerrit you need to subscribe, which means you need to create a login or use your google login, which some folks object to, on various grounds. Or we need to run the gerrit server, allow for other auth, but have the time (which we don't have) to run another bit of infrastucture.
I'm not saying it's an insurmountable hurdle, and if we take the approach that people doing more than a one-off submission need to use gerrit, we would probably survive.
Dear Tom,
In message 20131115213415.GM420@bill-the-cat you wrote:
I'm not saying it's an insurmountable hurdle, and if we take the approach that people doing more than a one-off submission need to use gerrit, we would probably survive.
Are any of the Linux sub-trees managed by gerrit?
Best regards,
Wolfgang Denk
Wolfgang,
On Fri, Nov 15, 2013 at 9:21 PM, Wolfgang Denk wd@denx.de wrote:
In message 20131115213415.GM420@bill-the-cat you wrote:
I'm not saying it's an insurmountable hurdle, and if we take the approach that people doing more than a one-off submission need to use gerrit, we would probably survive.
Are any of the Linux sub-trees managed by gerrit?
I don't think it is the right comparison. We are not discussing if Gerrit is good or bad; or even who uses it. Our focus must be: does Gerrit workflow work for /most/ of us? In case the answer is true, we can adopt it. Otherwise, no.
Dear Otavio,
In message CAP9ODKox=e6j3UYdDJbgdxn+j8Orh+F15FeW5f17tgwLn8i68Q@mail.gmail.com you wrote:
Are any of the Linux sub-trees managed by gerrit?
I don't think it is the right comparison. We are not discussing if Gerrit is good or bad; or even who uses it. Our focus must be: does Gerrit workflow work for /most/ of us? In case the answer is true, we can adopt it. Otherwise, no.
I was interested in existing experience with this tool. It seems it's something we cannot run for testing in parallel with the normal mailing list method, so we should be really sure that it works for the type of tasks we have to do.
In other situations we've always looked at what the Linux kernel guys are doing - assuming they have a very similar sort of taks, just at an even much higher scale.
So I think it would be very intersting information to learn if some of the Linux subsystems are using Gerrit, what their experience is, and how they organized their work flow around it.
Best regards,
Wolfgang Denk
On Sun, Nov 17, 2013 at 05:51:20PM +0100, Wolfgang Denk wrote:
Dear Otavio,
In message CAP9ODKox=e6j3UYdDJbgdxn+j8Orh+F15FeW5f17tgwLn8i68Q@mail.gmail.com you wrote:
Are any of the Linux sub-trees managed by gerrit?
I don't think it is the right comparison. We are not discussing if Gerrit is good or bad; or even who uses it. Our focus must be: does Gerrit workflow work for /most/ of us? In case the answer is true, we can adopt it. Otherwise, no.
I was interested in existing experience with this tool. It seems it's something we cannot run for testing in parallel with the normal mailing list method, so we should be really sure that it works for the type of tasks we have to do.
In other situations we've always looked at what the Linux kernel guys are doing - assuming they have a very similar sort of taks, just at an even much higher scale.
So I think it would be very intersting information to learn if some of the Linux subsystems are using Gerrit, what their experience is, and how they organized their work flow around it.
I think in this case we won't find anyone (outside of "Android" subsystem) usnig it, in public. I know in private that companies use it for their review process, and it relatively works. I know the TI case the is much the same discussion we have between old school and new school reviewers.
Hi All,
You do all realise that we are going about this, to use some British vernacular, arse-about-tit
Everyone agrees that the current U-Boot review workflow 'has issues' (and has had issues for quite some time). The first attempt at overcoming these issues was Patchwork. I personally think that that ended up being far less successful than we hoped
Then Simon Glass wrote some truly excellent 'developer side' tools (patman and buildman) which I think we can all agree has help lighten the load be improving the quality of the patch submissions (not the patch code necessarily, but the submission process)
And now we are looking at gerrit and, to be honest, we have one side of the fence trying to bang a square peg into a round hole, and on the other, the hole keeps changing shape.
Implementing gerrit will force a significant change to the workflow of everyone involved in U-Boot (developers and maintainers).
Question is - is the _workflow_ so broken that it needs such a drastic change, or does it just need a few more tools to 'grease the axle' so to speak. Or has U-Boot outgrown the current workflow model to such an extent that we need to change it? If the workflow is really that broken, then, unfortunately for some, there will be a rather painful transition to a new one.
We've identified that there is a problem, but nobody has yet to qualify and quantify exactly what the problem is. You can't fix a rattle with a screwdriver if the problem is a loose nut :)
Regards,
Graeme
On Mon, Nov 18, 2013 at 11:07:59AM +1100, Graeme Russ wrote:
Hi All,
You do all realise that we are going about this, to use some British vernacular, arse-about-tit
Everyone agrees that the current U-Boot review workflow 'has issues' (and has had issues for quite some time). The first attempt at overcoming these issues was Patchwork. I personally think that that ended up being far less successful than we hoped
Maybe it's time to swing around back and talk about what's wrong with our current tools then.
What I don't like about patchwork: - Some patches just don't make it in. - Sometimes discussions can be a bit hard to follow there, but that's what real mail list archives are for.
That's it. The queue can get unwieldy if you don't check the unassigned patches daily, but I don't see how another tool is going to fix the underlying problem of people not using the tool frequently.
What I like about patchwork: - Bundles. - Everything is mailbox format / git am'able.
Hello Tom,
Am 18.11.2013 17:00, schrieb Tom Rini:
On Mon, Nov 18, 2013 at 11:07:59AM +1100, Graeme Russ wrote:
Hi All,
You do all realise that we are going about this, to use some British vernacular, arse-about-tit
Everyone agrees that the current U-Boot review workflow 'has issues' (and has had issues for quite some time). The first attempt at overcoming these issues was Patchwork. I personally think that that ended up being far less successful than we hoped
Maybe it's time to swing around back and talk about what's wrong with our current tools then.
Thanks!
What I don't like about patchwork:
- Some patches just don't make it in.
- Sometimes discussions can be a bit hard to follow there, but that's what real mail list archives are for.
Yep.
What I miss in patchwork:
- It would be great, if patchwork could detect newer version from patches and mark the old patches superseeded ... but maybe this is not trivial for all patches... and have somewhere in the new patch website a link to the superseeded patch, so I can easy find the old patch and can look in it.
- If a custodian change the state of a patch, send at least a EMail to the owner of the patch with the info of the state changes.
- Maybe a cmdline interface to change the state of a patch, so I do not need to open a webbrowser (not necessary, would just nice ;-)
That's it. The queue can get unwieldy if you don't check the unassigned patches daily, but I don't see how another tool is going to fix the underlying problem of people not using the tool frequently.
Yes, full ack.
What I like about patchwork:
- Bundles.
- Everything is mailbox format / git am'able.
- Patchwork collects the Acked-by, Tested-by,... for a patch - The custodians ToDo list! I see on one site, what I have ToDo, nice.
bye, Heiko
Dear Heiko,
In message 528AE93D.2080805@denx.de you wrote:
- Maybe a cmdline interface to change the state of a patch, so I do not need to open a webbrowser (not necessary, would just nice ;-)
This can be done using existing tools. "pwclient update" can be used to update the status.
A minor problem here is identifying the patch when you don't want to use the web interface at all. If you have the original e-mail message stored locally (I'm using exmh / nmh as MUA, so each message is a file for me anyway), then you can use pwparser to compute the hash of the message and use this as an index, like that:
----------- snip ----------- #!/bin/bash
[ $# -ge 1 ] || { echo "Usage: $0 patch ..." >&2 ; exit 1 ; }
for PATCH in $* do HASH=$(/home/wd/bin/pwparser.py --hash <$PATCH) if [ -z "$HASH" ] then echo "ERROR: $PATCH - no such entry in PatchWork" >&2 continue fi
if pwclient git-am -h $HASH then pwclient update -s 'Accepted' -h $HASH fi done ----------- snip -----------
Best regards,
Wolfgang Denk
Hello Wolfgang,
Am 19.11.2013 08:12, schrieb Wolfgang Denk:
Dear Heiko,
In message528AE93D.2080805@denx.de you wrote:
- Maybe a cmdline interface to change the state of a patch, so I do not need to open a webbrowser (not necessary, would just nice ;-)
This can be done using existing tools. "pwclient update" can be used to update the status.
Oh... I look into this.
A minor problem here is identifying the patch when you don't want to use the web interface at all. If you have the original e-mail message stored locally (I'm using exmh / nmh as MUA, so each message is a file for me anyway), then you can use pwparser to compute the hash of the message and use this as an index, like that:
----------- snip ----------- #!/bin/bash
[ $# -ge 1 ] || { echo "Usage: $0 patch ...">&2 ; exit 1 ; }
for PATCH in $* do HASH=$(/home/wd/bin/pwparser.py --hash<$PATCH) if [ -z "$HASH" ] then echo "ERROR: $PATCH - no such entry in PatchWork">&2 continue fi
if pwclient git-am -h $HASH then pwclient update -s 'Accepted' -h $HASH fi done ----------- snip -----------
Great, thanks!
bye, Heiko
On Tue, Nov 19, 2013 at 05:29:49AM +0100, Heiko Schocher wrote:
Hello Tom,
Am 18.11.2013 17:00, schrieb Tom Rini:
On Mon, Nov 18, 2013 at 11:07:59AM +1100, Graeme Russ wrote:
Hi All,
You do all realise that we are going about this, to use some British vernacular, arse-about-tit
Everyone agrees that the current U-Boot review workflow 'has issues' (and has had issues for quite some time). The first attempt at overcoming these issues was Patchwork. I personally think that that ended up being far less successful than we hoped
Maybe it's time to swing around back and talk about what's wrong with our current tools then.
Thanks!
What I don't like about patchwork:
- Some patches just don't make it in.
- Sometimes discussions can be a bit hard to follow there, but that's what real mail list archives are for.
Yep.
What I miss in patchwork:
- It would be great, if patchwork could detect newer version from patches and mark the old patches superseeded ... but maybe this is not trivial for all patches... and have somewhere in the new patch website a link to the superseeded patch, so I can easy find the old patch and can look in it.
This isn't as easy as it sounds I think. And honestly, it's not hard to handle manually, if you get in the habit. And...
- If a custodian change the state of a patch, send at least a EMail to the owner of the patch with the info of the state changes.
Wishlisting, I'd like to see the reverse, known project custodian saying "Applied to" or "NAK" causing Accepted (or Awaiting Upstream, this is a little complex..) or Rejected to happen automatically. This could save on sending out the applied messages, but that's what bundles give me. Open it up in mutt, reply, find/paste/save-for-later, repeat.
- Maybe a cmdline interface to change the state of a patch, so I do not need to open a webbrowser (not necessary, would just nice ;-)
As Wolfgang pointed out, there is a cli suite (doesn't like SOCKS, iirc, tho). So it's scriptable to different levels. With Wolfgang's setup, you could just for loop over the old series and it goes automagically.
Hello Tom,
Am 19.11.2013 16:10, schrieb Tom Rini:
On Tue, Nov 19, 2013 at 05:29:49AM +0100, Heiko Schocher wrote:
Hello Tom,
Am 18.11.2013 17:00, schrieb Tom Rini:
On Mon, Nov 18, 2013 at 11:07:59AM +1100, Graeme Russ wrote:
Hi All,
You do all realise that we are going about this, to use some British vernacular, arse-about-tit
Everyone agrees that the current U-Boot review workflow 'has issues' (and has had issues for quite some time). The first attempt at overcoming these issues was Patchwork. I personally think that that ended up being far less successful than we hoped
Maybe it's time to swing around back and talk about what's wrong with our current tools then.
Thanks!
What I don't like about patchwork:
- Some patches just don't make it in.
- Sometimes discussions can be a bit hard to follow there, but that's what real mail list archives are for.
Yep.
What I miss in patchwork:
- It would be great, if patchwork could detect newer version from patches and mark the old patches superseeded ... but maybe this is not trivial for all patches... and have somewhere in the new patch website a link to the superseeded patch, so I can easy find the old patch and can look in it.
This isn't as easy as it sounds I think. And honestly, it's not hard to handle manually, if you get in the habit. And...
Yes, but we just collect things we want/miss/dont like ... so it is a point I want, not a must, as I can handle this manually.
- If a custodian change the state of a patch, send at least a EMail to the owner of the patch with the info of the state changes.
Wishlisting, I'd like to see the reverse, known project custodian saying "Applied to" or "NAK" causing Accepted (or Awaiting Upstream, this is a little complex..) or Rejected to happen automatically. This could save on sending out the applied messages, but that's what bundles give me. Open it up in mutt, reply, find/paste/save-for-later, repeat.
- Maybe a cmdline interface to change the state of a patch, so I do not need to open a webbrowser (not necessary, would just nice ;-)
As Wolfgang pointed out, there is a cli suite (doesn't like SOCKS, iirc, tho). So it's scriptable to different levels. With Wolfgang's setup, you could just for loop over the old series and it goes automagically.
Yes, I look into the cmdline interface... thanks!
bye, Heiko
Dear Michal,
In message CAOMqctTQUYpmEerVY1gFwvJ=S83G6VNA2MUQc7duLhLfXkmGrw@mail.gmail.com you wrote:
You need patch(1) to generate a patch and subscribe to mailing list to post it.
No. You can send mail even if not subscribed. The mail will be moderated then, but usually this is just a minor delay - typically less than an hour before it shows up on the mailing list.
To upload to gerrit you need git and subscribe to gerrit.
You have to register a google account. You have to accept google terms & conditions.
Two things one way or the other.
Maybe - but things of pretty different weight.
Best regards,
Wolfgang Denk
On 16 November 2013 00:20, Wolfgang Denk wd@denx.de wrote:
Dear Michal,
In message CAOMqctTQUYpmEerVY1gFwvJ=S83G6VNA2MUQc7duLhLfXkmGrw@mail.gmail.com you wrote:
You need patch(1) to generate a patch and subscribe to mailing list to post it.
No. You can send mail even if not subscribed. The mail will be moderated then, but usually this is just a minor delay - typically less than an hour before it shows up on the mailing list.
To upload to gerrit you need git and subscribe to gerrit.
You have to register a google account. You have to accept google terms & conditions.
Two things one way or the other.
Maybe - but things of pretty different weight.
Indeed, if adopting gerrit means giving up control over user authorization and ToS that's quite some weight.
Thanks
Michal
Dear Vadim Bendebury (вб),
In message CAC3GErFfUaLUZryxW+A1J3yrmgPWWzcMfoVkP8b=Yj7ksznUDw@mail.gmail.com you wrote:
- upload all patches to gerrit
- go to the web interface of the first patch in the series (by this
time gerrit would have a stack of patches showing their dependencies), click on "review" - at this point gerrit would open a form to type the cover message in
- once you finish composing the message you click on "publish
comments" and it gets sent to everybody who was picked as the reviewer, and to default addresses, if any are configured (which of course could be u-boot@lists.denx.de, for instance)
Basically this means _all_ new tools. Instead of using your well-known editor of choice with all the tons of provate macros and keyboard shortcuts you have build in your whole professional life you start filling out forms. Instead of using your well-known mail-tool with all the customizations you have added to help you to do what you are used to do you have something new.
And all is web driven - or is it?
Is any of this scriptable? Or can it be controlled by e-mail messages?
Once thing I have to mention: gerrit is notorious for sending tons of email, while this is being worked on, in the meantime some more rigorous email filtering might be very useful.
My initial touch of a feeling of indisposition in the stomach appears to be growing into some more severe sicknes :-(
Can we at least get all reviews sent to the ML?
The problem with this is that when reviews are sent to the mailing list, they are for different custodians, trees, etc. It looks like appx. half of them applies cleanly to the master branch, the rest do not. Is there a way to tell what branch the patch is detined to by looking at the email?
A much more robust approach is to have users push patches directly, and set up branches/projects on the server, as required.
So this means gerrit is a make-or-break conversion. Is there no way to allow old die-hards (like me) to stick to their well-known and highly optimized work to work environment?
My understanding from your description is that we cannot even try this out for some time while running the old way in parallel - we have to do either this or that, and as soon as we switch to gerrit there is not even a smooth way back - at least not without losing all the activities done in gerrit?
Best regards,
Wolfgang Denk
On Fri, Nov 15, 2013 at 08:18:43PM +0100, Wolfgang Denk wrote:
Dear Vadim Bendebury (????),
In message CAC3GErFfUaLUZryxW+A1J3yrmgPWWzcMfoVkP8b=Yj7ksznUDw@mail.gmail.com you wrote:
- upload all patches to gerrit
- go to the web interface of the first patch in the series (by this
time gerrit would have a stack of patches showing their dependencies), click on "review" - at this point gerrit would open a form to type the cover message in
- once you finish composing the message you click on "publish
comments" and it gets sent to everybody who was picked as the reviewer, and to default addresses, if any are configured (which of course could be u-boot@lists.denx.de, for instance)
Basically this means _all_ new tools. Instead of using your well-known editor of choice with all the tons of provate macros and keyboard shortcuts you have build in your whole professional life you start filling out forms. Instead of using your well-known mail-tool with all the customizations you have added to help you to do what you are used to do you have something new.
Depends on your macros. If you use FireFox, the plugin "It's all Text!" lets you throw any input field into $EDITOR. Some of the saftey features of Chrome dis-allow this type of plugin, sadly. So some things are different (you don't quote the code hunk in question), but some are not. So, it's different.
And all is web driven - or is it?
Is any of this scriptable? Or can it be controlled by e-mail messages?
So, in another message Vadim pointed out a cli tool for gerrit that can do certain things. You cannot do the code reviews via CLI or e-mail. You can do other things like mark as verified (so a CI could come along and whack that in, automatically), inspect (I don't know if that means grab to local git branch so you can see or open a browser window with the item in question or what) and a few other things.
Once thing I have to mention: gerrit is notorious for sending tons of email, while this is being worked on, in the meantime some more rigorous email filtering might be very useful.
My initial touch of a feeling of indisposition in the stomach appears to be growing into some more severe sicknes :-(
Yes. I think that for the emails, for example, we would have to have something in the middle and some procmail or similar rules.
Can we at least get all reviews sent to the ML?
The problem with this is that when reviews are sent to the mailing list, they are for different custodians, trees, etc. It looks like appx. half of them applies cleanly to the master branch, the rest do not. Is there a way to tell what branch the patch is detined to by looking at the email?
A much more robust approach is to have users push patches directly, and set up branches/projects on the server, as required.
So this means gerrit is a make-or-break conversion. Is there no way to allow old die-hards (like me) to stick to their well-known and highly optimized work to work environment?
Depends on which part of the flow? You stopped using CVS at some point. And many of us have switched from bk or other tools, to git. So turning "git send-email ..." into "git push ..." will only suck for a bit. Turning review from mail to web, well, that's different. I say, look at https://u-boot-review.googlesource.com/#/c/1221/ and see how you would have reviewed and commented there, rather than on the ML.
My understanding from your description is that we cannot even try this out for some time while running the old way in parallel - we have to do either this or that, and as soon as we switch to gerrit there is not even a smooth way back - at least not without losing all the activities done in gerrit?
Depends on the activity a bit, I think, and how much we filter the messages. What I was asking about would be how we might migrate from a google-gerrit to a local-gerrit, should the service go away.
Dear Tom,
In message 20131115194059.GI420@bill-the-cat you wrote:
Depends on which part of the flow? You stopped using CVS at some point. And many of us have switched from bk or other tools, to git. So turning "git send-email ..." into "git push ..." will only suck for a bit.
Agreed. This is the least problem.
Turning review from mail to web, well, that's different. I say, look at https://u-boot-review.googlesource.com/#/c/1221/ and see how you would have reviewed and commented there, rather than on the ML.
Here is my key problem. I cannot even figure out what to do with this page. I cannot display it in a format I am used to, not can I process it in a way I'm used to. I'm totally lost with that.
And I don't even see a way to work around that :-(
Best regards,
Wolfgang Denk
On Sat, Nov 16, 2013 at 12:16:17AM +0100, Wolfgang Denk wrote:
Dear Tom,
In message 20131115194059.GI420@bill-the-cat you wrote:
Depends on which part of the flow? You stopped using CVS at some point. And many of us have switched from bk or other tools, to git. So turning "git send-email ..." into "git push ..." will only suck for a bit.
Agreed. This is the least problem.
Turning review from mail to web, well, that's different. I say, look at https://u-boot-review.googlesource.com/#/c/1221/ and see how you would have reviewed and commented there, rather than on the ML.
Here is my key problem. I cannot even figure out what to do with this page. I cannot display it in a format I am used to, not can I process it in a way I'm used to. I'm totally lost with that.
Scroll down to patch set 1, click on unified and you get: https://u-boot-review.googlesource.com/#/c/1221/1/common/cmd_nvedit.c,unifie... and that's a "fancy" unified diff (tabs denoted, line numbers added, highlighting on the changes within a line). Some of that is pretty useful, but I would like to know if you can tweak that once logged in.
Dear Tom,
In message 20131116013913.GN420@bill-the-cat you wrote:
Here is my key problem. I cannot even figure out what to do with this page. I cannot display it in a format I am used to, not can I process it in a way I'm used to. I'm totally lost with that.
Scroll down to patch set 1, click on unified and you get: https://u-boot-review.googlesource.com/#/c/1221/1/common/cmd_nvedit.c,unifie... and that's a "fancy" unified diff (tabs denoted, line numbers added, highlighting on the changes within a line). Some of that is pretty useful, but I would like to know if you can tweak that once logged in.
Well, some might find this cool, but for me it is utterly useless. I cannot do anything with this format. I started working in UNIX environments about 30 years ago, and what I need is a text file. I'm using nmh / exmh as MUA< so each message on the mailing list is a separate text file. This is what I need, as I can _work_ with the data, using standard tools.
I can grep for basic information (like for other patches that touch similar code), I can run the message through checkpatch or other scripts, I can check if it applies to the source tree. I can open it in an editor and use standard tools like ctags etc. to get additional nformation about the source context, related files, definitions in header files and all that.
With Gerrit, I can do none of this. I am dumbed and blindfolded and restricted to tactile senses.
Yes, I guess I can download the patch and process it then, and then switch tools again to type a comment in an unwieldy and unchangable environment.
Yes, gerrit provides search tools (see [1]) - but compare this against plain old grep and the rest of the text processing tools in Unix...
To me, gerrit appears to be the type of tool used in Big Organizations style of work - capable of organizing the work and enforcing adherence to certain procedures and processes for big teams of engineers. Gerrit describes itself as "web based code review and project management for Git based projects". I think this is correct.
Maybe I'm wrong, but my understanding was that we were not primarily interested in introducing better project management tools, but in reducing the work load on the maintainers, making our work more efficient.
I have to admit that I have zero practical experience with gerrit (meaning I have never used it as core tool in any real-life project, and did only very limited and very basic testing - and the learning curve apears to be long and arduous!), but from what I've seen so far I see feel that indeed helps to better organize the work, but at the cose of considerable restrictions to in the tooling and interfaces, resulting (at least for me) in lower efficiency.
I've tried to find discussions of using gerrit in Linux kernel development. I found little - see [2]. I find statements like "git needs an friendly UI, web based is the future." not exactly convincing. There were a number discussions at the last Linux Conference / ELCE about maintainers' efficiency and scaling problems with the always growing work load. There are so many really excellent engineers in the Linxu project - but apparently none of them uses (or talks about considering to use) gerrit. Is it just lack of information, or intuition, fear of changing the well-known processes - or do they have good reasons?
I see a lot of open questions here...
[1] https://review.openstack.org/Documentation/user-search.html [2] http://lkml.indiana.edu/hypermail/linux/kernel/1003.0/00687.html
Best regards,
Wolfgang Denk
On 17 November 2013 20:31, Wolfgang Denk wd@denx.de wrote:
Dear Tom,
In message 20131116013913.GN420@bill-the-cat you wrote:
Here is my key problem. I cannot even figure out what to do with this page. I cannot display it in a format I am used to, not can I process it in a way I'm used to. I'm totally lost with that.
Scroll down to patch set 1, click on unified and you get: https://u-boot-review.googlesource.com/#/c/1221/1/common/cmd_nvedit.c,unifie... and that's a "fancy" unified diff (tabs denoted, line numbers added, highlighting on the changes within a line). Some of that is pretty useful, but I would like to know if you can tweak that once logged in.
Well, some might find this cool, but for me it is utterly useless. I cannot do anything with this format. I started working in UNIX environments about 30 years ago, and what I need is a text file. I'm using nmh / exmh as MUA< so each message on the mailing list is a separate text file. This is what I need, as I can _work_ with the data, using standard tools.
I can grep for basic information (like for other patches that touch similar code), I can run the message through checkpatch or other scripts, I can check if it applies to the source tree. I can open it in an editor and use standard tools like ctags etc. to get additional nformation about the source context, related files, definitions in header files and all that.
With Gerrit, I can do none of this. I am dumbed and blindfolded and restricted to tactile senses.
Yes, I guess I can download the patch and process it then, and then switch tools again to type a comment in an unwieldy and unchangable environment.
You need not download the patches one by one. You can fetch the gerrit branches into a git repo which makes them into text files you can work with - almost.
Unfortunately, git stores some data in packages and generally does not present the data in reasonable form.
This can be fixed - I can imagine something like fuse filesystem that presents pretty much what gitweb does, except in a usable form. Unfortunately, I know no such solution that can be readily used.
I find the inability to look at multiple branches without checking out multiple copies of a repository very limiting when working in git.
Thanks
Michal
Dear Michal Suchanek,
In message CAOMqctQxCjQedw94nhR5_VmKL3_tkBhcdZe+GAND9ZxBMSN70g@mail.gmail.com you wrote:
Yes, I guess I can download the patch and process it then, and then switch tools again to type a comment in an unwieldy and unchangable environment.
You need not download the patches one by one. You can fetch the gerrit branches into a git repo which makes them into text files you can work with - almost.
Well yes - but when I have the files locally, then I cannot use these to actually generate the feedback for gerrit, right? I have to switch back to the web interface then, and use copy & paste from my text windows?
Best regards,
Wolfgang Denk
On Mon, Nov 18, 2013 at 05:13:39PM +0100, Wolfgang Denk wrote:
Dear Michal Suchanek,
In message CAOMqctQxCjQedw94nhR5_VmKL3_tkBhcdZe+GAND9ZxBMSN70g@mail.gmail.com you wrote:
Yes, I guess I can download the patch and process it then, and then switch tools again to type a comment in an unwieldy and unchangable environment.
You need not download the patches one by one. You can fetch the gerrit branches into a git repo which makes them into text files you can work with - almost.
Well yes - but when I have the files locally, then I cannot use these to actually generate the feedback for gerrit, right? I have to switch back to the web interface then, and use copy & paste from my text windows?
Well, depending on $EDITOR and $BROWSER, there's some games you can play, but, Yes, and I'm not 100% down with that change either.
e
On Sun, Nov 17, 2013 at 11:31 AM, Wolfgang Denk wd@denx.de wrote:
Dear Wolfgang,
[snip..] Maybe I'm wrong, but my understanding was that we were not primarily interested in introducing better project management tools, but in reducing the work load on the maintainers, making our work more efficient.
Having worked with email based reviews and with gerrit, I would say that gerrit has overwhelming advantage when it comes to reviewing complex changes, especially when multiple patch versions are required due to review comments.
These are the major advantages IMO:
- the side-by side display of the changes makes it easier to understand what is going on - the entire source file is at the reviewer's disposal if he wants to see a larger context - it is very easy to see what changed between patch versions - it is easy to pull entire patch series into a local tree if one wants to try a change
So, if one wants to optimize for complex cases, gerrit is advantageous (again, IMO, of course). But I totally understand your concerns wrt the need to change the work flow and the need to have an account to post even a small patch (I am not sure, but there might be a way around this).
I have to admit that I have zero practical experience with gerrit (meaning I have never used it as core tool in any real-life project, and did only very limited and very basic testing - and the learning curve apears to be long and arduous!), but from what I've seen so far I see feel that indeed helps to better organize the work, but at the cose of considerable restrictions to in the tooling and interfaces, resulting (at least for me) in lower efficiency.
I've tried to find discussions of using gerrit in Linux kernel development. I found little - see [2]. I find statements like "git needs an friendly UI, web based is the future." not exactly convincing. There were a number discussions at the last Linux Conference / ELCE about maintainers' efficiency and scaling problems with the always growing work load. There are so many really excellent engineers in the Linxu project - but apparently none of them uses (or talks about considering to use) gerrit. Is it just lack of information, or intuition, fear of changing the well-known processes - or do they have good reasons?
I see a lot of open questions here...
Gerrit, of course, is an open source project (quite big and complicated, but still), they are open to suggestions and would definitely consider patches, but this is probably a very long shot, as Java, Prologue and JavaScript require a very different skill and experience set than the typical u-boot developer possesses :)
Of course it is up to you to decide, I am sure the status quo will keep working for another (maybe long) while.
regards, --vb
[1] https://review.openstack.org/Documentation/user-search.html [2] http://lkml.indiana.edu/hypermail/linux/kernel/1003.0/00687.html
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke
Hi Vadim,
On Wed, Nov 20, 2013 at 4:21 AM, Vadim Bendebury (вб) vbendeb@google.comwrote:
e
On Sun, Nov 17, 2013 at 11:31 AM, Wolfgang Denk wd@denx.de wrote:
Dear Wolfgang,
[snip..] Maybe I'm wrong, but my understanding was that we were not primarily interested in introducing better project management tools, but in reducing the work load on the maintainers, making our work more efficient.
Having worked with email based reviews and with gerrit, I would say that gerrit has overwhelming advantage when it comes to reviewing complex changes, especially when multiple patch versions are required due to review comments.
These are the major advantages IMO:
- the side-by side display of the changes makes it easier to
understand what is going on
- the entire source file is at the reviewer's disposal if he wants to
see a larger context
- it is very easy to see what changed between patch versions
- it is easy to pull entire patch series into a local tree if one
wants to try a change
Emphasising the pros and cons of this tool versus that tool is the wrong way to go about this. This is how salespeople convince you to buy things you don't need - 'Let me show you how good it is at doing xyx'. Before you know it, you've bought a fancy do-da that does a million things, but you only end up using it for the things you _need_ to do anyway, and your come to the realisation that your old do-da did a perfectly fine job already and you end up using it instead because it's smaller and faster.
gerrit is a great tool. I've seen it in action and I like it a lot.
BUT - what is it we NEED. Where are the bottlenecks in the existing U-Boot workflow? Where do things fall over? What REALLY annoys you about how we do things now?
Don't look at features of existing tools. The biggest trap you will fall into is selecting a tool that does a whole heap of nifty stuff you never even thought of, and you'll forget the one thing that troubles you the most.
Maybe we could put the discussion on the Wiki. Or we could add a 'Wishlist' document to the git repo - that way we can discuss each wish on the ML individually, add it when it's sufficiently fleshed out, and remove it when it's implemented.
Figure out the problem first, then look for a solution.
Regards,
Graeme
On Tue, Nov 19, 2013 at 11:42 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Vadim,
On Wed, Nov 20, 2013 at 4:21 AM, Vadim Bendebury (вб) vbendeb@google.com wrote:
e
On Sun, Nov 17, 2013 at 11:31 AM, Wolfgang Denk wd@denx.de wrote:
Dear Wolfgang,
[snip..] Maybe I'm wrong, but my understanding was that we were not primarily interested in introducing better project management tools, but in reducing the work load on the maintainers, making our work more efficient.
Having worked with email based reviews and with gerrit, I would say that gerrit has overwhelming advantage when it comes to reviewing complex changes, especially when multiple patch versions are required due to review comments.
These are the major advantages IMO:
- the side-by side display of the changes makes it easier to
understand what is going on
- the entire source file is at the reviewer's disposal if he wants to
see a larger context
- it is very easy to see what changed between patch versions
- it is easy to pull entire patch series into a local tree if one
wants to try a change
Hello Graeme,
Emphasising the pros and cons of this tool versus that tool is the wrong way to go about this. This is how salespeople convince you to buy things you don't need - 'Let me show you how good it is at doing xyx'. Before you know it, you've bought a fancy do-da that does a million things, but you only end up using it for the things you _need_ to do anyway, and your come to the realisation that your old do-da did a perfectly fine job already and you end up using it instead because it's smaller and faster.
for Christ's sake, I am not selling anything. In fact I am quite unlikely to be contributing into u-boot in the near future, as the projects I have been working on have moved away from this bootloader. This u-boot replica was set up in my spare time and is using my employer's resources which it is willing to provide for the open source community. It is not guaranteed to be available forever.
gerrit is a great tool. I've seen it in action and I like it a lot.
BUT - what is it we NEED. Where are the bottlenecks in the existing U-Boot workflow? Where do things fall over? What REALLY annoys you about how we do things now?
Don't look at features of existing tools. The biggest trap you will fall into is selecting a tool that does a whole heap of nifty stuff you never even thought of, and you'll forget the one thing that troubles you the most.
Maybe we could put the discussion on the Wiki. Or we could add a 'Wishlist' document to the git repo - that way we can discuss each wish on the ML individually, add it when it's sufficiently fleshed out, and remove it when it's implemented.
Figure out the problem first, then look for a solution.
To me the problem clearly is the complexity of reviewing large patches in unified diff format. I certainly understand historical reasons for using email based unidiffs, even ten years ago there were no alternatives. But now there are, all I am trying to do is to show this community that there are other ways. It is perfectly possible that these other ways do not look that appealing/convincing to the rest of the community, or the entry threshold (as in changing the process) is prohibitively high, we all can just move on.
Wolfgang et al, please let me know if you are certain that this is not necessary, I'll shut it down then, it should be possible to set it up again later if the sentiment changes.
regards, --vb
Regards,
Graeme
participants (14)
-
Albert ARIBAUD -
Graeme Russ -
Heiko Schocher -
James Chargin -
Luca Ellero -
Michal Suchanek -
Oliver Schinagl -
Otavio Salvador -
Scott Wood -
Simon Glass -
Tom Rini -
Vadim Bendebury -
Vadim Bendebury (вб) -
Wolfgang Denk