Freddie Chopin wrote: >> Please read HACKING and post to Gerrit. I second this.
> Sorry, I don't have time to do so because: Sorry, noone has time to deal with your patch. > 1. The patch is trivial It might seem so, but actually it's not. It has multiple logical changes combined in a single commit, which is no good. Please separate the return error into it's own commit, with it's own clear commit message about how and why. > 2. I use git in Linux hosted in VitualBox, where emailing patches > kinda does not work Øyvind could have written "push" instead of "post", since commits go to Gerrit using git push, and not email. It's clear that you misunderstood this, and it's clear that you didn't even look into how commits would be sent to Gerrit, before arguing that you do not have time to do so because it is too complicated. Your VM needs network access. I guess it has that. On another note, it's absolutely not neccessary for you to work with OpenOCD source code in any particular operating system. If your prefered environment is Windows then Git can perform line ending translation for you, allowing you to use any Windows tools to work with any project codebase. > 3. My knowledge of Linux and Git is minimal That's not a problem. If your willingness to gain knowledge of Git is also minimal, *that* is a big problem, since you can notwork efficiently within the project then. Perhaps you realize that learning a little about Git makes a huge difference in productivity. It's of course impossible to discuss this with someone if they have already decided that they hate Git (you might be surprised how common this is) or that they otherwise don't want to learn the tool. I would see OpenOCD as an opportunity to learn more about Git, and I would be happy that I took the opportunity, since I can benefit from it also outside of OpenOCD. If you run into trouble then please do ask - there are several on the mailing list who are happy to help. > So basically I can say that Gerrit posting would NOT work in my > environment without some serious effort, The effort in all it's seriousness is documented in HACKING. But here are the steps again, summarized for your convenience: * acquiring any OpenID account (let me know if you can't get one) * registering on the Gerrit website * configuring a username on Gerrit website * (optional) uploading a public ssh key on Gerrit website * adding the commit hook in your local repo * re-committing your change (to get the Change-Id) * git config remote.origin.url with ssh or http URL to Gerrit * git push The next time you've made a commit you run git push again, to send commit(s) to Gerrit. I am confident that this is quite significantly simpler than whatever workflow you currently use with patch files and email software. > while you can just accept that trivial patch or post it there in > two seconds. Except that you can not get feedback then. Since it is your patch it is you who needs to push it to Gerrit. > I have got a lot on my head now and no time to spare. Yeah, it takes time to learn tools, but Gerrit is really not your enemy. > Make Gerrit accept patches via web interface (I see no reason why it > shouldn't allow to do so as it's web based) IMO that would be stupid. You already have the commit in Git, so it is really impossible to have a simpler interface than git push. > and I'll be happy to post anything there - now it's just like a > stone wall for me with milions of steps required See above, and HACKING, for the million steps that are required. > to send a patch once a year. Next year you do it with one command. Since your VM can not send email I know that you are not using git send-email, which would be similarly simple as git push to Gerrit; you must be creating patch files, and sending them manually in email. This is not efficient. There's really no reason to be inefficient about something, even if you only do it once a year, especially when the knowledge that allows you to work more efficiently can benefit you for a whole year in between. > For me - a user who sometimes patches simple stuff or adds config > files - Gerrit is an obstacle, nothing more. I think you should look at how Gerrit actually works, and re-evaluate your position. Of course, being required to even think about a new tool is a slight inconvenience for a new contributor, but hopefully you can help document the process, or suggest simplifications, instead of only complaining about how difficult it is before you have any experience. On the flip side, the value of Gerrit is significant. Commits can very quickly and easily come into Gerrit and go out of Gerrit into the public openocd.git repo. (You may have noticed the command line interface via SSH that Gerrit offers.) It's also very easy to make detailed comments on commits. Øyvind mentioned that Gerrit also brings a bit of quality assurance, for free, without human interaction. The slight added inconvenience is instantly amortized by the added value. > Sorry for the inconvenience. Don̈́'t apologize, just actually try Gerrit out before you complain. //Peter _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
