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

[Heiko Schocher]

Hello Christophe,

Am 29.06.2017 um 18:51 schrieb 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.

So I do not understand why you didn't mainlined your boards, if you have
such constraints! Sorry, we didn't know that your hw exists, until my
remove patches...

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

Great. Thanks!

bye,
Heiko
>> 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
>>
>

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany