On Wed, Jun 11, 2014 at 4:30 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: > > > Am 11.06.2014 16:20, schrieb drago01: >> On Wed, Jun 11, 2014 at 4:13 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: >>> >>> Am 11.06.2014 16:08, schrieb drago01: >>>> We should really just do the right think and properly obsolete yum >>>> without a compact package ... keeping yum serves no purpose. As for >>>> Matthew's mail ... I don't think people will forgot about Seth because >>>> yum is gone if that's the case it would be really sad.... also why >>>> maybe his biggest yum was not his only contribution >>> >>> if it obsoletes and replaces yum it has to provide /usr/bin/yum >> >> That's what I have said (just with the "if"). >> >>> [...] >>> and yes i think it would be a great idea install DNF only on >>> new F22 setups while obsolete and replace yum finally one >>> release later to get more widely testing and at the same >>> time avopid to break 5 and more years old server setups >>> with scripting around yum because some of the early bugs >>> maybe be reported by the users of new install and fixed >>> until F23 >> >> No I disagree here. We already have (and are still in) a "optional to >> test for user" and it gets active testing. Its time to flip the switch > > well, that's something different than have on a new setup DNF instead > YUM and if things are working properly you don't notice, make a reality > check: the way a optin-user tests and classifies things are completly > different as a random user not knowing about the replacement > > if sensible core components are replaced there should be a way back > in case of troubles and not a dry "there where testers live with it" > > those testers until now maybe not represent the relevant usecases > > if i replace software i do it always in steps and that is why > i did not breaks cumstomers setups the last 11 years: > > * internal tests > * asking some representative users for testing > * update a picked set of users without saying anything > * if they report troubles try to fix them within 2 up to 5 hours > * if that's not possible revert the change for them > * try to fix the problem without angry users > * roll it out again for the picked set > * and then roll it out for everybody > * and even in that last step there must exist a way back > > the golden rule for accepted big changes is *never* break users setup > and never make a abusive change with no way back and leave only > telling him he has to chew and adopt Sure but that should also applies to upgrades (i.e do not just upgrade on productive systems without prior testing on a replicated test environment; which you probably do anyway). I am not really opposed to having "a way back" if it is opt in and not simply split the userbase based on how the system got installed (this is a mess to support comparing to having a handful of users that opted to "go back"). Support aside at least the workstation prd states that upgrades should not have a worse expirence then new installs having a slower depsolver / package installer would fall into that. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
