[Gta04-owner] [PATCH 00/11] DTS updates for GTA04
neilb at suse.de
Wed Jan 7 19:29:38 CET 2015
On Tue, 6 Jan 2015 20:25:02 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:
> Am 06.01.2015 um 19:58 schrieb NeilBrown <neilb at suse.de>:
> > On Mon, 5 Jan 2015 23:24:46 +0100 Belisko Marek <marek.belisko at gmail.com>
> > wrote:
> >> Hi Neil,
> >> On Mon, Jan 5, 2015 at 8:59 PM, NeilBrown <neilb at suse.de> wrote:
> >>> Hi Marek,
> >>> the following 11 patches fix some problems and add some enhancements
> >>> in the GTA04 DTS file. They all relate to features that are already
> >>> supported by the upstream kernel. The patches apply to Linus'
> >>> v3.19-rc2 kernel.
> >> Thanks for patches. I did check patches compared to existing in gta04
> >> kernel tree and some of patches are already present
> >> in that tree. Can you please ad to those patches: Signed-off-by: H.
> >> Nikolaus Schaller <hns at goldelico.com>
> >> All of them was done by Nikolaus.
> > No. Those patches that I sent you were written by me.
> > It is very likely that Nikolaus has written identical patches.
> Obviously. Which shows that we waste efforts if you spend time on solving
> things that I already have solved quite some time ago (and most likely
> vice versa). This is why I personally would prefer that we pile up everything
> on a shared gta04-kernel repository. And if bugs are fixed, we do the upstream
When you fix a bug, send the bug fix to the maintainer. It is *that*
Then I can easily get access to it.
But none of this "duplication" of effort wasted more than an hour or two -
tops. Most of my time goes in to much more obscure things, like why wifi
isn't powering on properly, or why the UART doesn't recover from run-time
> The side effect would be that there is a kernel that is *ahead* of linus/master.
> And in theory we should be able to get both: 100% feature complete and bug
> free and ahead of linus. Then we only have to convince Linus to take all our
> changes - and can finish the kernel development (except for testing for regressions).
Don't forget "fixing regressions". About half my time (at least) goes to
fixing regressions. My current main focus (when I get some time) is suspend
power usage, which is a regression over 3.7. Probably several regressions.
> > If you would
> > rather send the patches that he wrote upstream I am perfectly happy with that.
> I would be happy if we both are named as authors - if we came to the same
> solution (even if independently) because then it must be the right one.
> >> Here is a list:
> >> Patch | git rev in gta04 kernel | Author
> >> 001 - 8d932e94 - H. Nikolaus Schaller
> >> 002 - 061f0323 - H. Nikolaus Schaller
> >> 005 - 061f0323 - H. Nikolaus Schaller
> >> 006 - c94de56f - H. Nikolaus Schaller
> >> 007 - d26794c0 - H. Nikolaus Schaller
> >> 008 - 58f0a3e8 - H. Nikolaus Schaller
> > This list very effectively shows what I don't like about this tree.
> > Only one of those patches is really ready to go upstream.
> It is not intended that these patches are “ready to go upstream”.
> > That is the last
> > one (58f0a3e8). It was written in March 2014 and still hasn't been sent
> > upstream.
> Maybe it was simply missed because we had focussed on something else.
> > All all the rest (except d26794c0 which seems to be in the list by mistake)
> > are a mixture of different things with incomplete justification. So they are
> > not ready of sending upstream.
> But the tree defines what we want to see long-term in linus/master.
> We simply have a different development model. The general problem is that
> during development one tries this and that and fixes things here or there. And
> sometimes has to revert. Or develops in “steps”.
> But Linus wants to see so called “clean” patches (which is ok) which hide much
> of this upfront work. In the end he will have an identical tree - just different
> history how to get there.
> So there must necessarily be some “cleaning stage”.
For me there isn't a "cleaning stage". "cleaning" is part of the on-going
edit, compile, test, debug, clean, edit,....
(not quite that orderly of course).
> Now, there are two approaches:
> 1. the individual developer hides all these deviations and wrong paths from the public and ends up in a set of “clean” patches only
> 2. all changes are applied and documented to a public tree and at the end of the pipeline there is a “cleaning” process to get well tested and good things upstream
> Both approaches are shown to work.
> The problem I have with 1. is that it does not allow collaboration (at least I have
> no idea how it could work).
> Only a single developer can work with this approach because he is either done
> (no work left over for anyone else) or intermediate steps are not available (nobody
> knows where work is going on). And there is no way for the single developer to
> say “hello, I need help here or there” because then the risk is that someone answers
> with non-clean patches.
> What I wonder is if you are able to write clean patches right from the beginning (i.e.
> doing the cleaning process before typing) or if you also reformat/split/change/clean
> up patches from time to time.
I certainly *try* to write perfect patches from the start, but it doesn't
often work out that way.
Some bugs are fixed while I am typing, some are fixed after the compiler
complains, some are fixed during testing etc. So when I create a patch it
usually at least compiles. Some times I discover problems while writing the
commit comment, and so go and fix them.
I use 'stgit', so it is very easy to go back to a previous commit and modify
it if I discover a problem or want to re-factor or re-arrange or something.
It is as simple as:
stg goto $patchname
stg edit # if I want to change the commit comment at all
stg push -a
All of this is completely private. You don't get to see all my silly
mistakes (of which there are many).
When I think they are ready I post them to the relevant maintainer and lists.
This might be because I think they are ready to merge, or because I need help
improving the patches. I usually present it as through they are completely
There is a strange bit of psychology here. Some people seem much
more willing to spend time saying "no, you are wrong, this is how it should
be done", then providing help that is asked for.
So if I want to know how a thing should be done I don't ask "How should this
thing be done" because often no-one will answer. Instead I say "This thing
needs to be done and we should do it like this!". Then people will happily
say "No, that won't work, this other way makes much more sense". And now I
have my answer :-)
If I get feedback that requires a change (or if I discover a problem myself),
I go back and edit the commit with stg. I might then repost the set of
So the old version is lost from the git history - but it still appears in the
archives of the email lists. You can often find multiple versions of patch
sets in mail archives where on the final version appears in git.
If a problem is found after a maintainer has accepted a patch but before they
have forwarded it on, then how it is fixed depends on the maintainer. Some
maintainers will be happy to take an updated version of the patch. Some
maintainers would prefer to get an incremental patch to fix the problem. I
tend to prefer the first, but I do whatever the maintainer wants.
If the bug gets beyond the first maintainer, then it is frozen and will be
forever in the git history and can only be fixed by a separate patch.
So I think the reality is a mixture of your '1' and '2'. Some bugs and wrong
paths are certainly hidden. Some are discussed on mailing lists but don't
make it into the git history. Others are enshrined forever in git.
Collaboration happens via email on open lists. It just requires the
developer to post and other people to respond. I don't often post on
technical issues on this list because I don't see other people doing it and I
don't perceive that there are many who would contribute. I do occasionally
say "I'm working on this or that", and never get "I'd like to look at that
too - can you tell me where you are up to" or anything like that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 811 bytes
Desc: OpenPGP digital signature
More information about the Gta04-owner