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

[Wolfgang Denk]

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

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

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.

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.

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.


> 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
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I think trash is the most important manifestation of culture we have
in my lifetime."                                      - Johnny Legend