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
