[U-Boot] u-boot gerrit server

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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.

[U-Boot] u-boot gerrit server

[Simon Glass]

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

[U-Boot] u-boot gerrit server

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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.

-- 
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

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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.

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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...

-- 
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

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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.

-- 
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

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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

[U-Boot] u-boot gerrit server

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] u-boot gerrit server

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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.

-- 
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

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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.

-- 
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

[U-Boot] u-boot gerrit server

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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.

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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?

-- 
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

[U-Boot] u-boot gerrit server

[Vadim Bendebury]

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

[U-Boot] u-boot gerrit server

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] u-boot gerrit server

[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

-- 
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 at denx.de
Our management frequently gets lost in thought.   That's because it's
unfamiliar territory.

[U-Boot] u-boot gerrit server

[Wolfgang Denk]

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

-- 
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 at denx.de
"Just think, with VLSI we can have 100 ENIACS on a chip!"
- Alan Perlis

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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 at denx.de
> Our management frequently gets lost in thought.   That's because it's
> unfamiliar territory.

[U-Boot] u-boot gerrit server

[Scott Wood]

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

[U-Boot] u-boot gerrit server

[Tom Rini]

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131114/a034fae4/attachment.pgp>

[U-Boot] u-boot gerrit server

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131114/96e47752/attachment.pgp>

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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.

-- 
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

[U-Boot] u-boot gerrit server

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131114/30c22d22/attachment.pgp>

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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.

-- 
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

[U-Boot] u-boot gerrit server

[Tom Rini]

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".

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131114/1aa06ae0/attachment.pgp>

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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 at 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

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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.

-- 
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

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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

[U-Boot] u-boot gerrit server

[Tom Rini]

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 at 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131114/28652181/attachment-0001.pgp>

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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.

-- 
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

[U-Boot] u-boot gerrit server

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131114/47a4e192/attachment.pgp>

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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 at 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.

Agreed.

-- 
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

[U-Boot] u-boot gerrit server

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131114/04f24bd0/attachment.pgp>

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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 at 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?
>

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] u-boot gerrit server

[James Chargin]

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 at 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?
>>
>
> 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>

-- 
Jim Chargin
AJA Video Systems                       jimc at aja.com
(530) 271-3334                          http://www.aja.com

[U-Boot] u-boot gerrit server

[Oliver Schinagl]

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 at 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?
>>>
>>
>> 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 at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>>
>

[U-Boot] u-boot gerrit server

[Luca Ellero]

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 at 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?
>>>>
>>>
>>> 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 at lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>
>>>
>>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot gerrit server

[Wolfgang Denk]

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 at 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

-- 
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 at denx.de
Any technology distinguishable from magic is insufficiently advanced.

[U-Boot] u-boot gerrit server

[Tom Rini]

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 at 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131115/c4cc8bc3/attachment.pgp>

[U-Boot] u-boot gerrit server

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131115/b32136e7/attachment.pgp>

[U-Boot] u-boot gerrit server

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131115/db8f37e6/attachment.pgp>

[U-Boot] u-boot gerrit server

[Michal Suchanek]

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

[U-Boot] u-boot gerrit server

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131115/dd8ae60d/attachment.pgp>

[U-Boot] u-boot gerrit server

[Wolfgang Denk]

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

-- 
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 at denx.de
Die meisten Menschen pflegen im Kindesalter vom Zeigen auf Gegenst?n-
de (Mausbewegung) und "ga" sagen  (Mausklick)  abzukommen,  zugunsten
eines  m?chtigeren  und langwierig zu erlernenden Tools (Sprache).
                             -- Achim Linder in de.comp.os.linux.misc

[U-Boot] u-boot gerrit server

[Wolfgang Denk]

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

-- 
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 at denx.de
"May your future be limited only by your dreams."
- Christa McAuliffe

[U-Boot] u-boot gerrit server

[Wolfgang Denk]

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

-- 
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 at denx.de
Every revolutionary idea - in science, politics, art, or  whatever  -
evokes three stages of reaction in a hearer:
  1. It is completely impossible - don't waste my time.
  2. It is possible, but it is not worth doing.
  3. I said it was a good idea all along.

[U-Boot] u-boot gerrit server

[Otavio Salvador]

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.

-- 
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

[U-Boot] u-boot gerrit server

[Tom Rini]

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,unified
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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131115/a14bf6cb/attachment.pgp>

[U-Boot] u-boot gerrit server

[Michal Suchanek]

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

[U-Boot] u-boot gerrit server

[Wolfgang Denk]

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

-- 
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 at denx.de
Old programmers never die, they just become managers.

[U-Boot] u-boot gerrit server

[Wolfgang Denk]

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,unified
> 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

-- 
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

[U-Boot] u-boot gerrit server

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131117/754feddb/attachment.pgp>

[U-Boot] u-boot gerrit server

[Graeme Russ]

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

[U-Boot] u-boot gerrit server

[Michal Suchanek]

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,unified
>> 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

[U-Boot] u-boot gerrit server

[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.

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131118/463264cf/attachment.pgp>

[U-Boot] u-boot gerrit server

[Wolfgang Denk]

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

-- 
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 at denx.de
You don't get paid for the hour. You get paid for the value you bring
to the hour.                                               - Jim Rohn

[U-Boot] u-boot gerrit server

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131118/9318f51a/attachment.pgp>

[U-Boot] u-boot gerrit server

[Heiko Schocher]

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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] u-boot gerrit server

[Wolfgang Denk]

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

-- 
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 at denx.de
There's an old proverb that says just about whatever you want it to.

[U-Boot] u-boot gerrit server

[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...

> - 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131119/4ae1c0f1/attachment.pgp>

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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 at denx.de
> Any sufficiently advanced technology is indistinguishable from magic.
>                                                    - Arthur C. Clarke

[U-Boot] u-boot gerrit server

[Heiko Schocher]

Hello Wolfgang,

Am 19.11.2013 08:12, schrieb Wolfgang Denk:
> 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.

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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] u-boot gerrit server

[Heiko Schocher]

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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] u-boot gerrit server

[Graeme Russ]

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
>

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

[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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
>
>