Dear Christophe,
In message 71d351cb-2c42-99a0-0b4b-64cfa74ec254@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