Le samedi 14 juin 2014 à 15:15 +0200, Reindl Harald a écrit : > > Am 14.06.2014 15:04, schrieb Michael Scherer: > > Le samedi 14 juin 2014 à 12:55 +0200, Reindl Harald a écrit : > >>> That's why the developers do ask "what is missing". That's also why I > >>> ask for you what compatibility you exactly want, and you keep avoiding > >>> giving a clear answer > >> > >> *full* compatibility - is that so hard to understand and why? > > > > So basically, you want "full compatibility forever". Then I guess you > > cannot say that nobody ask for that, since you just did. > > > > https://lists.fedoraproject.org/pipermail/devel/2014-June/199991.html > > stop that trolling > > "to maintain yum in the long term" is a completly different thing than > keep *full compatibility* - compatibility is independet from the YUM > code itself Given there is no specification of what you mean by "full compatibility", the compatibility is the current behaviour in every details, and the current behaviour is therefore linked to the current code. Now, if someone do say "here is what we consider to be compatible" ( something that you have been asked 3 times and yet didn't provide, not even tried to provides ), then the compatibility would be separate from the code. But as long as "full compatibility" is "what yum does now", the 2 are linked by definition. But again, can you give a more precise definition of the behaviour that should be kept without having to refer to yum code ? You do not even say what version of the yum code should be used as reference. > > Yet, I still do not see you offering any help to achieve that, only you > > requiring it. > > as you do not offering to do the work of re-view and adopt > any existing script and howto out there I did intend to work on ansible to have it using dnf API, as that's a codebase I know quite well. > >>> Yes. And I would be in favor personally, so that let developers free to > >>> change the interface and anything if they see fit without having to keep > >>> old code for the old interface. > >> > >> why do you need to keep old code for compatible CLI interfaces? > > > > Because that's the easiest way, especially for plugins. > > interesting - guess what: the *easiest way* would have been > not rewrite YUM at all - do it anyways but than say "but > for all other things which don't match the cherry picking > it's easier not do to so" is hypocrisy So basically, that exactly what I said. It is is easier to keep the old code than to ask to keep compatibility in the new one, especially since compatibility is not specified at all. So if your goal is 100% compatibility over all, then indeed, not changing anything is the simplest way. Now, if you want to see some changes, then you are ok to have something change, so the goal is no longer 100%. So you have to explain what are the 90% that shouldn't changes at all, and what are the 10% that you are ok to see changes. > > Otherwise, any changes could result in unrelated side effects and > > regressions, and the more options you provides, the more stuff there is > > to break. And the QA cost of full compatibility is rather high, > > especially for python where there isn't much isolation or interface for > > the code ( ie, you can directly go to the internal structures, kinda > > like DOS years ago ) > > you understand that any compatibility break is a side effect for the user? Yes, I do. That doesn't mean that I care however. I am personally ok with having some breakages if the developers think this is the better choice given time, contraints and all real life issues, as I trust them to have thought about it. And I do not care also because I am fully able to adapt, that's part of my job as sysadmin. -- Michael Scherer -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct