Hi, Am 25.09.2015 um 11:58 schrieb Neil Jerram <n...@ossau.homelinux.net>: >> >> * Upstreaming is tough (you have to convince maintainers and accept that >> they try to enforce different - and sometimes conflicting - goals). > > With respect, I think that a little more humility and patience is needed > here. I have recently been upstreaming various changes into OpenStack, which > I think is a broadly similar project and culture to the kernel. > > My experience has been that one gets a lot of feedback, and initially some of > it seems to be unhelpful, some seems to be pointlessly nitpicking, some seems > to be contradicting other feedback, and so on. But I have found that if I > just address things step by step - and have a lot of patience! - that > everything eventually resolves, and the things that appeared to be pointless > actually do have a point. Try to be neutral - i.e. open as to the 'how' - on > everything other than the fact that you do want a particular piece of > function to work. And if you do get two upstream developers who appear to be > contradicting each other, just describe that, while addressing both of them, > and they'll probably sort it out.
after thinking about it, I have found out why I see it as a tough process: tools and process. The way how upstreaming works (submitting patches and running through a clean up discussion process) is quite inefficient. Compared to just pulling the current version, edit, commit and push. Unless you have efficient tools and know how to efficiently use them to edit patch sets instead of source files,, this is tough. The typical result of a review is that people go through the patch you have submitted and suggest a space or empty line here, rename this variable there, etc. Now, the most efficient way to do that would be if reviewers wouldn't write what they want to have changed in prosa in some e-mail reply - but change it directly in source code... And make another git patch on top of mine. The result will be exactly what they want to see. And I have no additional work with nitpicking. But the way it is handled, I get the additional work of being source file editor for them - until the patch looks like they want to have it. So I have an additional burden to decipher how to change the source files until it is git-formatted into a form they like. Functionality will rarely change. They just look more tidy (to reviewers, not necessarily me). Unfortunately, editing patch series is quite complicated (requires use of git rebase -i, git filter-branch or stgit) and is more difficult than simply editing source files, pile up commits, compile, test. Especially as the resulting source tree is the same. Only the patch history differs. It took me some years to learn how to become faster for modifying patch sets on top of some base version. So the reason why it is "tough" IMHO is that in some cases you get comments and have no idea how to implement them because you are not proficient enough with the git tools... Well, there is a good reason why the Linux upstream process is doing it the way it is done. By editing a patch set (and not source files) until it appears "clean" requires: a) discussion b) finding consensus c) don't clutter the discussion by intermediate steps d) have a clear responsibility who is applying proposed changes e) mainline source code always compiles (well only in theory - official 4.3-rc1 didn't compile if some configs were added beyond omap_defconfig) So it is though because it needs different tools which must be learned first and the whole process appears inefficient because you have to be editor commanded by prosa e-mails. But maybe it also must be that tough or the project would end in chaos. I don't know. Therefore we need better patch series editing tools (I am working on my own and it already helps a lot in such work). BR, Nikolaus _______________________________________________ Community mailing list Community@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.openphoenux.org
