On Wed, Jun 11, 2014 at 4:30 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 11.06.2014 16:20, schrieb drago01:
> On Wed, Jun 11, 2014 at 4:13 PM, Reindl Harald <h.reindl(a)thelounge.net> 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.