On Thu, Nov 14, 2013 at 03:43:03PM -0800, Vadim Bendebury (????) wrote: > On Thu, Nov 14, 2013 at 1: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 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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
