[CentOS-devel] SIGs, versions, and yum update

On 10 February 2016 at 10:00, George Dunlap <dunlapg at umich.edu> wrote:
> On Wed, Feb 10, 2016 at 4:36 PM, George Dunlap <dunlapg at umich.edu> wrote:
>> A couple of weeks ago I was just about to push an update of Xen 4.4 to
>> Xen 4.6 to the Virt SIG repositories, and I suddenly got some
>> push-back from the users, because Xen 4.6 has some fairly significant
>> changes -- particularly the removal of the old toolstack daemon called
>> xend.  (xend had been disabled by default and had lots of messages
>> warning about the upcoming deprecation, even in 4.4.)
>>
>> It seems some users have the expectation that they should be able to
>> run "yum update -y" on their servers on a regular basis, without
>> having to worry about accidentally updating to a new major version
>> that break things.
>>
>> So one thing that was proposed was that we make separate packages
>> somehow, such that users would have to actively request the newer
>> version rather than getting it automatically.  (This could be done
>> either by having a package named xen46, or by having separate
>> centos-release-xen-46 package that pointed to an entirely different
>> repository.)
>>
>> But of course, other users pushed back on that idea, saying they would
>> always rather have the latest version Just Work, and didn't like the
>> idea of having to manually keep track of what version was installed on
>> any given system, or of actually finding out that there's a new
>> package and what that new package name is.
>>
>> KB and I chatted about it at the Virt SIG meeting, and decided that we
>> should touch base with the other SIGs to have a consistent message.
>>
>> As for my own opinion: I can see both sides of the story, and as a
>> package maintainer I'd be willing to do either one.
>>
>> But on the whole I tend to side with the "latest version" crowd.  I
>> think you should always be looking at what "yum update" gives you
>> before installing it; even minor updates I can't guarantee are going
>> to break things.  And I'd rather the installation instructions be
>> simple (don't have to mess around with version numbers), and I'd
>> rather people not have to fish around for major updates (or run
>> packages with unpatched security vulnerabilities because they didn't
>> realize their packages were now obsolete).
>>
>> What do other SIGs think?
>
> Splitting the difference from a user point of view, here's another option:
>
> * Have a separate repo for each major version
> * Have the centos-release-xen-NN packages which always point to a specific repo
> * Have the centos-release-xen package always point to the most recent repo
>
> This is a tiny bit more infrastructure work, but makes it easier to
> test both minor releases and major releases; it also makes it easier
> for volunteers to step up and maintain older versions if they want.

If this is possible to do tooling wise then I would say this is your
"best" bet. However, if this is too much of a headache, then I would
stick with the latest push for multiple reasons:

1) People will assume you are still supporting/fixing 4.4 even when it
is not happening.
2) Sites which need extra stability that this problem showed need to
be aware this could have happened even in a 4.4.5 to 4.4.6 type
update.  [Too much software does this from Oracle, Microsoft to
joes-open-source-email-reader] That is the nature of a lot of software
which will bite you over and over again if you don't put in processes
to mitigate that.




-- 
Stephen J Smoogen.