[Community] About cost and business models for community hardware
martin.jansa at gmail.com
Tue Sep 29 14:02:15 CEST 2015
On Sun, Sep 27, 2015 at 06:16:18PM +0200, H. Nikolaus Schaller wrote:
> Am 25.09.2015 um 11:58 schrieb Neil Jerram <neil at 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.
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).
> Community mailing list
> Community at openphoenux.org
Martin 'JaMa' Jansa jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the Community