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

[christophe leroy]

Hello Heiko,

Le 30/06/2017 à 06:15, Heiko Schocher a écrit :
> 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...

To be honest I don't understand either ...
Most likely people believe you only have to send bug fixes to Open 
Source community to keep a project alive ... and only your customer get 
to get the sources of what you do for them.

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

Did you have time to have a look already ? Am I going in the good 
direction ?

Thanks
Christophe

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus