[U-Boot] [PATCH v3] powerpc: Restore core of mpc8xx

[Christophe LEROY]

Dear Wolfgang,

Le 23/06/2017 à 14:11, Wolfgang Denk a écrit :
> Dear Christophe,
> 
> In message <71d351cb-2c42-99a0-0b4b-64cfa74ec254 at c-s.fr> you wrote:
>>
>> Ok, noted. Please take care to not remove anything that is common with
>> 8xx before 8xx is back.
> 
> 8xx is gone.  Please get used to that fact.

Yes he is gone by accident, lets get it back as some orphan boards need it.

> 
>> Yes I realised that after Tom suggested to perform a travis-CI build,
>> I'm working on it, should probably get something early next week, maybe
>> tonight
> 
> Please don't hurry.  You lose nothing by doing things right instead
> of in a rush.  On contrary.

I agree, but see below

> 
>>> Make a list of features you need for your board and only add
>>> this code. Or do you not know what you need?
>>
>> Of course I know what I need.
> 
> OK, so please let's discuss it here, so we can review your patches
> in comparison with your requirements.

The requirements are:
1/ The boards are used in Air Trafic Control critical system. Therefore, 
EUROCAE ED153 and ESSAR6 standards apply.
(for those not familiar with SW in ATC, see 
http://opentechday.nl/wp-content/uploads/2017/05/20170420-OpenTechDay-Using-Linux-in-Air-Traffic-Control-002.pdf).
Using OpenSource SW in ATC is challenging. In order to reach the 
required SW assurance level, we have two main possibilities
a/ Ensure that the SW is developped following the V cycle with all the 
associated documentation.
b/ Ensure that a previous version of the SW has a good 'in-service 
experience' and the new version only introduces a reduced amount of 
modifications in source code.
2/ The SW has to be kept up to date (once a year) until at least 2027

Req 1/a/ not being an option here, 1/b/ is the only way.
For that, we need to be able to demonstrate that the 8xx support has 
been in the SW for several years WITHOUT any interruption. It means that 
the 8xx must be back as soon as possible (ideally before version 2017.07 
gets out) and with as little differences as possible and with 
traceability of the differences. Therefore, we can't re-introduce 
something that is different from what has been in for years, without the 
commits showing the incremental changes. If not, the certification is 
garantied to fail.

> 
> Please provide a list of features / drivers needed by your boards,
> and please also provide some information about the schedule you
> envision for the cleanup to take place.

The schedule: No discontinuity is U-boot support for 8xx.
In Septembre, we will start preparing the yearly SW update.

> 
> Please understand that we are concerned about re-adding old, crappy
> and in a number of places known to be broken code again.  We had a
> large number of such situations in the past, and with _very_ few
> exceptions in almost all cases he promised cleanup just never took
> place.

I have kept only the needed stuff in my soon-to come v5 version of the 
patch.

> 
> And if you look at your own arguments, you are actually feeding such
> concerns.
> 
>>>>> [In which way is the sil680 driver related to mpx8xx, btw?]
>>
>> If it is not related, then it will go when I do the clean up. Lets do
>> the things in order and perform atomic commits.
> 
> No, this makes no sense to me. This is exactly where you will
> continue to see my NAKs: the code has already been removed, so please
> do not re-add it now if you already anticipate that you will remove
> it later.
> 
> Remember Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)
> 
>          O, throw away the worser part of it,
>          And live the purer with the other half.
> 
> :-)
> 
> 
>> Here I really feel like being an hostage. Just because I didn't noticed
>> early enough that the 8xx code was about to go away, now I have to pay
>> the ransom of doing a huge cleanup to get it back ? To be honnest I
>> really find it unfair.
> 
> Please don't take this discussion on a personal level.  Please
> understand that I (and certainly also Heiko) would be more than
> happy to see 8xx survive in a clean and well maintained state.
> But this discussion is not about being fair or not, it is about
> good code or bad one.  Let's face it: apparently you never before
> cared much what is going on in U-Boot mainline, and now you attempt
> to jump into the job of a custodian.  This job carries both great
> responsibility and requires a lot of dedication and enthusiasm.
> Normally we require people to have a proven track record for working
> with the community before they are even considered for this job.
> 
> And frankly: nobody asked you to take this job.  If you step back,
> then 8xx is just gone, and that's it.  Nobody else here sheds a
> tear, not even me, the author of large parts of this code.
> 
>> I have volonteered to maintain the 8xx and I plan to perform the cleanup
>> that have been awaited. Why don't you welcome that and allow me to do as
>> if we were 2 weeks ago and the code had not go away yet ?
> 
> We welcome you, and we actually try to help you.  You lack
> experience with working in mainline, and with working with the
> community.  We've been here before and know pretty well what works
> and what is bound to cause trouble later.  Being new in this job,
> you should listen to such advice and not fight it.

Your advices are welcome. Now you know my requirements, so your help is 
of course more than welcome.

Christophe

> 
> 
>> But doing that way we loose the history, years of good work by
>> respective people. We take the risk to forget things to add back.
> 
> We don't lose any history.  It's all still available in git.
> If you forget to add anything, then only because you don't need it -
> and did we not agree to add only the stuff that is really needed and
> omit all the ugly warts?
> 
> Remember Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)
> 
>          O, throw away the worser part of it,
>          And live the purer with the other half.
> 
> :-)
> 
>> I prefer forgetting to remove something than forgetting to re-add
>> something. Doing as you suggest we loose any opportunity to bisect when
>> something that was working in previous versions is not working anymore.
>> etc ...
> 
> As Heiko suggested, you can do all this in a local, private
> repository.  When you have reached a clean, working state, then
> submit your clean and working patches to mainline.  More is not
> needed.
> 
>> git is all about doing atomic commits, to allow detailed explanation, to
>> allow bissects, to ease reviews, etc.
> 
> Yes.  But the existing code will not allow this.  You will end up
> with a large collection of mess which you don't dare to remove
> because you don't understand what it might be needed for.  You said
> this yourself several times before - see the discussion about this
> #undef thing.
> 
> But we don't want all this crap back.  The code that goes back in
> must be maintained by you, which includes it must be tested.  Which
> means you must use it on a regular base in production, or you will
> not be granted the needed resources for such unused and unneeded
> tests.
> 
>> You were looking for someone to take care of the 8xx, I'm here now. I
>> need 8xx to be maintained for at least the next ten years, so I will
>> take charge and do what needs to be done, but if it was not with a Knife
>> under the throat it would be more rewarding.
> 
> You completely misunderstand the job you are applying for. This is
> not about being rewarding in any way.  Working as a custodian is a
> pastime similar to banging one's head against a wall, but with fewer
> opportunities for reward.
> 
> This is work, lots of boring and frustrating work.  This is no fun
> job at all.
> 
> Nobody cared for the 8xx code for the past 8...10 years because
> there were no active users left.  There is a lot of work to do.
> 
>>> And your solution is reverting none 8xx patches? Come on! Why is this a
>>> problem for bringing 8xx back?
>>
>> Conflicts require manual actions, which often leads to human errors.
>> That's my haunt here.
> 
> It is much more likely that you will oversee tons of dead, unused
> and broken code once you got a configuration for your board up and
> running.  This might better meet your own interests, but it does not
> meet the interests of the community.
> 
>> Yes I handled it, I reverted everything then I re-did the removal of
>> 82xx etc ...
> 
> Sorry, but please accept that this approach will not be accepted.
> 
>>> Time to clean it up!
>>
>> Yes I'm here for that. Start from the existing and clean step by step,
>> with atomic commits so that everyone can see what has been done, how and
>> why.
> 
> The current status quo is that 8xx is gone.
> 
>> No, I mean we should get 8xx core back and allow cleaning it up in an
>> ordered manner that allows us to keep track of history. Yes U-boot code
>> changes from day to day, and that is exactly what I'd like to be allowed
>> to do with the 8xx, clean it up day by day and follow the evolution of
>> U-boot.
> 
> You did not care about this for the past decades, and the risk is
> that you will just do the minimum amount of work to satisfy your own
> needs.
> 
> The only way to prevent that tons of crap get added and never
> cleaned up or removed is to accept only such code which you require
> yourself.
> 
> This is the same like building a minimal root file system.  You can
> take a standard distribution and remove everything not needed, or
> you can take an empty system and add only what you need.  The
> results are TOTALLY different.
> 
> We ask you to go the additive route, because otherwise we will
> have tons of mess in mainline, no matter how hard or how long you
> work.
> 
>>> If you are working on this right now in a private repository branched
>>> from the current mainline tree, then it is really little effort to
>>> rebase your work tree every few hours against the then current
>>> mainline tree. The 8xx code is not used anywhere else, so you
>>> should see only a few merge conflicts in Makefiles or Kconfig files
>>> while you go, and all these would be trivial to fix.
>>
>> rebasing every few hours ? If I could use that time to do something more
>> usefull, wouldn't it be better for everyone ?
> 
> This statement scares me pretty much.  It sounds as if you also
> don't have much experience of working with git.  Rebasing a
> work-in-progress tree against mainline is usually (*) a trivial
> process which just takes seconds, and you _should_ do it anyway,
> because the longer you wait, the more work will accumulate and the
> more complex the merge conflicts will become.
> 
> * Exceptions are when your changes touch a lot of code all over the
>    place, in many different subsystems, like generic Kconfig rework,
>    global renames / cleanup or such.  but this is not the case here.
>    Your 8xx is nearly fully orthogonal to other work, so in most
>    cases you will see zero merge conflicts.
> 
> 
>> If for instance we re-introduce in a different place and with a
>> different name some files you have just removed, we definitly loose the
>> automatic history of those files. If we get it back at its original
>> place and move it after, the history is kept, 'git blame' will show it up.
> 
> You are right.  But we pay for this advantage the price of
> uncleanable and basically unmaintainable code - all the more so as
> the boards that once used it are gone.  From the mainline point of
> view this disadvantage is much more important.
> 
> For yourself of course it makes a lot of sense to proceed this way.
> As maintainer of the code you want to have all this, and you are
> free to do it.  As custodian, you can even do this in public in a
> branch of the mpc8xx repository (git://git.denx.de/u-boot-mpc8xx.git).
> 
> So no information will be lost - not for you, and not for the
> community.
> 
> But we do not want to do this mainline.
> 
> Please go on and wade through all the garbage and clean it up, and
> when the stuff is shiny and working, submit your patches to
> mainline.  Start small, with a minimal system, so reviewing is easy,
> and it will go in easily.
> 
>>> Which changes in core parts?
>>> Why do you need them?
>>
>> We most likely don't need them, I have to (re)move them, however it will
>> require some time.
> 
> Sorry, I don't want to have that.
> 
>> No, that's not correct. I want to adapt it, but again, I don't think it
>> is a good idea to do it in a few hours, in a hurry.
> 
> But that's exactly what you are pushing us for: we shall accept the
> old crap in a hurry.  No, take all the time you need and clean it up
> first, please!  It is not us who is pushing you.
> 
> 
> I really suggest that for a start you post your list of requirements
> and schedule, so we have a base for understanding why you re-add
> certain things.
> 
> Thanks.
> 
> Wolfgang Denk
>