On Thu, Nov 14, 2013 at 7:17 PM, Tom Rini <tr...@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 <tr...@ti.com> wrote: >> > On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote: >> > >> >> Hello Wolfgang, >> > [snip] >> >> > Can you not pick up the patches directly from the mailing list? I >> >> > mean, we know of the problems patchwork has (like silently dropping >> >> > certain base64 / utf8 encoded messages), so we should rather try and >> >> > get a more reliable feed for the patches? >> >> > >> >> >> >> this is the thing: picking up patches from patchwork is not something >> >> you'd do regularly - this is just my way of populating the review site >> >> from a single test account. >> >> >> >> If this workflow were adopted, each user would push their patch to the >> >> gerrit server, creating a new review branch for that particular patch. >> >> In general, gerrit view of the branch matches the submitter's view of >> >> the branch - if the submitter has several patches in one branch, they >> >> will all be uploaded by gerrit to the same separate branch, >> >> maintaining the relationship between the patches. >> > >> > This is my biggest concern. On the one-off to infrequent contribution >> > side (and we do have some of that), I worry about the infrastucture >> > hurdle here. >> > >> >> Sorry, I am not sure i understand what the biggest concern is: that >> the users would push their own patches? Why is this a problem - the >> patches would go into their own branches until reviewed and merged. Or >> did you mean something else? > > I mean, it's a higher hurdle to clear. Looking at other non-Android > projects, I know some folks have said "bah, not worth the effort" to > push trivial things, if it must come via gerrit. So some way to scrape > the ML for things that don't come in via gerrit to start with would be > handy.
I think this is something one of 'known' developers will end doing and applying it to Gerrit. >> > On the other side, what is the gerrit equivalent of 'git send-email >> > --compose ...', and I'm focusing on the compose side here. Or is it >> > just another mental switch the project makes, from that to push to >> > gerrit / compose email saying "hey, look at this" >> > >> >> This is how we usually do this: >> >> - upload all patches to gerrit >> - go to the web interface of the first patch in the series (by this >> time gerrit would have a stack of patches showing their dependencies), >> click on "review" - at this point gerrit would open a form to type the >> cover message in >> - once you finish composing the message you click on "publish >> comments" and it gets sent to everybody who was picked as the >> reviewer, and to default addresses, if any are configured (which of >> course could be u-boot@lists.denx.de, for instance) > > Right, and at that point we've mixed discussion of a concept with > discussion of a particular change, and we're in web-only for writes. I > guess (pending see below) one could just write the 0/N email separate, > or in-reply-to 1/N, so that the concept discussion stays on the list and > in the archives and so on. > >> Once thing I have to mention: gerrit is notorious for sending tons of >> email, while this is being worked on, in the meantime some more >> rigorous email filtering might be very useful. > > Just how hard is it likely to be to filter things so that only: > 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot