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-64cfa74ec...@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

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to