On Sun, Sep 27, 2015 at 06:16:18PM +0200, H. Nikolaus Schaller wrote: > Hi, > > Am 25.09.2015 um 11:58 schrieb Neil Jerram <[email protected]>: > >> > >> * 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.
That sounds a bit like github pull-request based review, which doesn't work very well when people update commits (all inline review comments get lost), so people tend to add more changes to pull-request instead of fixing the issues in the pending commits which introduced them - that sounds very wrong to me and against the whole review idea which should ensure that every commit is correct, before it's merged. > 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. Why would you need git filter-branch? I find "git rebase -i" extremely helpful and not so difficult to use for updating my upstreaming queue. > 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. At work we're using gerrit for reviews instead of ML based review in e-mails, it helps a lot because it includes all necessary information in one place (actual change and all revisions of it, discussion, inline review comments, easy to get diffs between all revision, review "score"). But for some people it doesn't work well with their workflow and if they don't want to change workflow they usually despise whole gerrit idea (I did the same for first 3 months, now after 2 years using gerrit I really love doing reviews on gerrit and hate doing it in ML + Patchwork). > 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 > [email protected] > http://lists.goldelico.com/mailman/listinfo.cgi/community > http://www.openphoenux.org -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Community mailing list [email protected] http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.openphoenux.org
