Le samedi 14 juin 2014 à 03:20 +0200, Reindl Harald a écrit : > Am 14.06.2014 03:10, schrieb Michael Scherer: > > Le samedi 14 juin 2014 à 03:03 +0200, Reindl Harald a écrit : > >> Am 14.06.2014 02:59, schrieb Michael Scherer: > >>> Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit : > >>>> On 06/13/2014 09:03 AM, drago01 wrote: > >>>> > >>>>> On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: > >>>>>> Am 13.06.2014 14:53, schrieb Jan Zelený: > >>>>>>> That being said, the reason for not renaming dnf to yum is that renaming this > >>>>>>> project to yum will do nothing else than to confuse its users, as they will > >>>>>>> think this is still yum and they should expect from dnf it what they expected > >>>>>>> from yum. They should not. And dnf is not yum, I'm really sorry if you think > >>>>>>> it is. > >>>>>> the user expects that anyways if you replace something he > >>>>>> did not asked for replace it and what just worked for him > >>>>> Well there are different levels of "works" i.e just because something works that > >>>>> something does not have to be the best possible implementation of > >>>>> "something" ... > >>>>> > >>>>> Horses worked too but at some point we decided that cars work better > >>>>> and moved on. > >>>> Yes but who is this better for? A few developers or the mass of people > >>>> and documentation that > >>>> are used to using "yum". > >>>> > >>>> With cars it was obviously better for me - dnf not so obvious. > >>> > >>> So far in this thread, I see no one stepping to maintain yum in the long > >>> term, just people asking to others to do it. > >>> > >>> But having someone volunteering to maintain it would be the solution. > >>> People who want to keep yum forever, just maintain it > >> > >> what are you talking about? > >> *nobody* asked that *nobody* > > > > Nobody did ask that explicitly. But if people want to keep all howto > > running, either we keep yum as is, or we define what exactly should be > > preserved and what can be removed > > why do functions and options need to be removed due a > code-rewrite/re-factoring? to clean up the code base? likely yes. Also because the more code you have, the more corner case you can face, the more time you spend on testing, reimplementing, etc, etc. the dnf developers did a very good job engaging the users to know what matter to them, to integrate likely better or more flexible solution, etc. 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) > 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. > 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 ? > 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 ? (remember, you said that no one want to have "everything" "forever", so let's be precise on what you want) And you can hardly complain to not be listened if you do not answer to precise questions when someone is willing to listen and try to find a solution. -- Michael Scherer -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
