Le samedi 14 juin 2014 à 03:55 +0200, Reindl Harald a écrit : > > Am 14.06.2014 03:36, schrieb Michael Scherer: > > Everybody I know who looked at the yum python api told me it was a bit > > horrible. So a cleanup was needed for that. There was demand from > > packagekit developers to have a cleaner API as well, and I would hope > > that tools like puppet/ansible would benefit as well. > > > > And since that's python, you also have the need to be python 3 > > compatible, which is a rather big task, as seen by the slow migration of > > the rest of the platform. > > > > The less code you have to port, the less time it take (same goes for > > testing, documenting, translating) > > the internal API is between developers > the options and CLI params are for users > > different worlds This divide is meaningless, since what affect developers affect non developers ( as code that is not ported will no longer work, even for API change ), and as people keep speaking of scripts on yum. The command line switches are part of the API for software like puppet, ansible. > >> if someone takes the word "improve" in his mouth i > >> don't see a place for "remove" in the same context > >> > >> the "dirty codebase grown" that way because previously unplanned > >> features where included and it it pretty silly to cleanup things > >> by step back from where it came which leads a few years later to > >> the same problems: options left and right are included in a > >> codebase originally not designed for it > >> > >> that's fine for developers because that way you can start every > >> few years from scratch with remove, re-write and cleanup but it > >> hardly gains anything for the users > > > > In fact, since developers can fix bug more easily with a code that is > > clean, it benefits to users as well. > > you ignore the bugs of missing functions which will be the first > so you postponed the work only 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. > >> a smart re-write is using the benefit knowing what all sort of options, > >> functions and configurations where added all the time before and > >> organize the codebase to implement it in a better, more generic way > >> with sane (API) interfaces > > > > Perfect, so are you leading the way, or do you continue to tell to > > people how to make a smart rewrite without being more specific and > > without putting any efforts? > > my effort is try to prevent thousands of bugreports Thousands ? I think you are exaggerating. Hyperbolic statements do not help. > did you realize that in this thread it was even suggested > to completly remove the yum command over the long even > if it is only a symlink? 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. People who want the old yum can keep it alive, the others can use the dnf name. > >> throwing all away, start with a minimum and be proud > >> it's faster and cleaner is only a short term solution > > > > You still didn't answer to the question I asked. > > How long do you want compatibility be kept, and what compatibility > > exactly ? [snip of yum help] That's neither the answer to : - how long - what -- Michael Scherer -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
