[U-Boot] u-boot gerrit server

[Tom Rini <trini@ti.com>]

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>