From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Fri, 30 Jun 2017 06:15:26 +0200 Subject: [U-Boot] [PATCH v3] powerpc: Restore core of mpc8xx In-Reply-To: <7335469c-1e12-c59c-4ac4-3fda0f665ec1@c-s.fr> References: <20170621213804.C5ACA679C8@pc13941vm.idsi0.si.c-s.fr> <20170622073517.1BCAD120142@gemini.denx.de> <0784ad6e-86ab-9c1d-1b81-a5cacaf2b01f@c-s.fr> <20170622095924.E6D961206BD@gemini.denx.de> <5694c1c6-3fce-bc6b-c196-fae53ae86a48@c-s.fr> <594BC0F0.1070101@denx.de> <71d351cb-2c42-99a0-0b4b-64cfa74ec254@c-s.fr> <20170623121114.033D1120156@gemini.denx.de> <7335469c-1e12-c59c-4ac4-3fda0f665ec1@c-s.fr> Message-ID: <5955D05E.3080707@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 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@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... > >> >> 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! 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 >> > -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany