[Gta04-owner] [PATCH 00/11] DTS updates for GTA04

Dr. H. Nikolaus Schaller hns at goldelico.com
Wed Jan 7 20:04:26 CET 2015


Hi,

Am 07.01.2015 um 19:29 schrieb NeilBrown <neilb at suse.de>:

> On Tue, 6 Jan 2015 20:25:02 +0100 "Dr. H. Nikolaus Schaller"
> <hns at goldelico.com> wrote:
> 
>> Hi,
>> 
>> 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
>> process.
> 
> When you fix a bug, send the bug fix to the maintainer.  It is *that*
> *simple*.
> Then I can easily get access to it.

Yes. If the bug is fixed. In my experience it might take weeks or months until
it is fixed and then of course it is upstreamed. It is a matter of how continuoulsy
I can work on a topic.

So if I see that I don’t find time to work on it in the next days, I tend to commit
something which partially fixing things. I.e. by making small steps. This is why
the solution is sometimes scattered around multiple patches. Or I learn by
fixing something else that the fix was not the best approach.

But it is mature for upstream only if everything of an issue is fixed.

Sometimes we do it in the form of feature-branches. But sometimes the partially
working state is already much better than no patch. So it goes into 3.19-rc3 (or
whatever).

> 
> 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
> suspend.

Yes, that is the same we are working on and struggling with.

> 
>> 
>> 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.

Definitively.

> 
>> 
>>> 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
> process.
> edit, compile, test, debug, clean, edit,....
> (not quite that orderly of course).

We simply have put cleaning into a separate parallel process. So we do
edit, compile, test, debug, edit… and the other process does … clean ...

Like some JAVA interpreters are running garbage collection in a parallel
thread.

> 
>> 
>> 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
>  $EDITOR file.c
>  stg refresh
>  stg edit # if I want to change the commit comment at all
>  stg push -a

That looks interesting. I think my main issue with cleanup is that it needs tools
that are easy to use. And bare-bone git isn’t.

> 
> 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
> ready.

Ok, this is the key difference in our work style. I publish most of the silly mistakes,
because someone else might have a look at it and find out what is wrong where
I don’t see it. If that happens in practise is a different question (as you write below).

Sometimes I make a break on a topic for weeks/months. But since I don’t know
when I have tome to continue, it is a problem to have it sitting in a feature branch.
If I want to continue, I might have to rebase it to the current base version. And this
might need to fix unexpected conflicts.

On the other hand, having it in the 3.19-rc3 branch (even if known to be wrong and
buggy) means that merging 3.19-rc4 will show merge conflicts. And in my experience
it is much easier and less time consuming to upgrade something from 3.19-rc3 to rc4
than from 3.16-rc4 to 3.19-rc4.

> 
> 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 :-)

Well, there are cases where I don’t know at all how it should be done. So I can’t
even make a proposal. E.g. making the WiFi work faster (and fix power management
issues). Then, this strategy fails...

> 
> 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
> patches.
> 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.  

Yes, this is our common problem. We need more contributors to finish
the final upstreaming. It is just adding the missing 0.5% to Kernel.org
to perfectly support the GTA04. But still the 0.5% make the current kernels
unuseable as a daily phone. They are only good as demonstrators.

The 3.12 kernel is good enough to do the full the hw-test. I.e. all hw-modules
(except Ir/Torch) can be tested. And the test cases fail if the hardware
is broken.

With 3.19 we are still far away from this level of maturity. Only ~60% of the
hw-test passes. Even on a 100% good device. This is why the 100% feature
completeness is so important to me.

> 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.

Well, what I (together with Marek) am working on is always here:

http://projects.goldelico.com/p/gta04-kernel/issues/

It also tells what we have submitted upstream. For some patches we have
to ask for follow-up because they appear to have been forgotten. On the other
hand we have closed more issues than are still open. This gives hope.

And maybe some motivation for readers of this mail to support.

BR,
Nikolaus



More information about the Gta04-owner mailing list