What is the current update policy for EPEL? The stated one seems to be along the lines of "no major changes" ( http://fedoraproject.org/wiki/Updates_Policy ) but it seems more like "whatever the packager is willing to maintain" is the actual policy.
I ask because a bugzilla was just opened against a package I maintain ( https://bugzilla.redhat.com/show_bug.cgi?id=1201808 ) and I wanted to know how I should handle it.
Does it need to be closed as wontfix? Or should a "notice of upcoming major update" policy be put in place to handle things like this?
Thanks, Dave
On Tue, 17 Mar 2015 21:36:41 -0700 Dave Johansen davejohansen@gmail.com wrote:
What is the current update policy for EPEL? The stated one seems to be along the lines of "no major changes" ( http://fedoraproject.org/wiki/Updates_Policy ) but it seems more like "whatever the packager is willing to maintain" is the actual policy.
I ask because a bugzilla was just opened against a package I maintain ( https://bugzilla.redhat.com/show_bug.cgi?id=1201808 ) and I wanted to know how I should handle it.
Does it need to be closed as wontfix? Or should a "notice of upcoming major update" policy be put in place to handle things like this?
Rex already closed it as WONTFIX, however to expand on that:
The current policy is to not change the user experence or require manual intervention on updates if at all possible. There are some cases where there's not much choice (like when the version shipped has serious security or data loss bugs and a upgrade to a new version is the only answer), but in those cases theres announcements to the epel-announce list and lots of time in testing.
kevin
On Wed, Mar 18, 2015 at 6:34 AM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 17 Mar 2015 21:36:41 -0700 Dave Johansen davejohansen@gmail.com wrote:
What is the current update policy for EPEL? The stated one seems to be along the lines of "no major changes" ( http://fedoraproject.org/wiki/Updates_Policy ) but it seems more like "whatever the packager is willing to maintain" is the actual policy.
I ask because a bugzilla was just opened against a package I maintain ( https://bugzilla.redhat.com/show_bug.cgi?id=1201808 ) and I wanted to know how I should handle it.
Does it need to be closed as wontfix? Or should a "notice of upcoming major update" policy be put in place to handle things like this?
Rex already closed it as WONTFIX, however to expand on that:
The current policy is to not change the user experence or require manual intervention on updates if at all possible. There are some cases where there's not much choice (like when the version shipped has serious security or data loss bugs and a upgrade to a new version is the only answer), but in those cases theres announcements to the epel-announce list and lots of time in testing.
Is that really true? The Qt 5 package in EPEL 6 has been updated several times and I don't recall ever seeing an email/announcement/etc.
On Wed, 18 Mar 2015 08:00:35 -0700 Dave Johansen davejohansen@gmail.com wrote:
Is that really true? The Qt 5 package in EPEL 6 has been updated several times and I don't recall ever seeing an email/announcement/etc.
Were the upgrades incompatible? You have to manually intervene?
kevin
On Wed, Mar 18, 2015 at 10:39 AM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 18 Mar 2015 08:00:35 -0700 Dave Johansen davejohansen@gmail.com wrote:
Is that really true? The Qt 5 package in EPEL 6 has been updated several times and I don't recall ever seeing an email/announcement/etc.
Were the upgrades incompatible? You have to manually intervene?
Honestly, on the machines I'm using, I installed 5.2 and haven't updated since 5.3 was released because I didn't want to rebuild and re-test all of my stuff, but my understanding of the following is that the upgrades are not completely compatible: http://upstream.rosalinux.ru/versions/qt.html
Dave Johansen wrote:
On Wed, Mar 18, 2015 at 10:39 AM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 18 Mar 2015 08:00:35 -0700 Dave Johansen davejohansen@gmail.com wrote:
Is that really true? The Qt 5 package in EPEL 6 has been updated several times and I don't recall ever seeing an email/announcement/etc.
Were the upgrades incompatible? You have to manually intervene?
Honestly, on the machines I'm using, I installed 5.2 and haven't updated since 5.3 was released because I didn't want to rebuild and re-test all of my stuff, but my understanding of the following is that the upgrades are not completely compatible: http://upstream.rosalinux.ru/versions/qt.html
Fwiw, Qt upstream takes both api and abi stability pretty seriously (official public interfaces). If you experience any concrete incompatibilities after upgrading, it's arguably a bug worth fixing.
-- Rex
On Thu, Mar 19, 2015 at 5:52 AM, Rex Dieter rdieter@math.unl.edu wrote:
Dave Johansen wrote:
On Wed, Mar 18, 2015 at 10:39 AM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 18 Mar 2015 08:00:35 -0700 Dave Johansen davejohansen@gmail.com wrote:
Is that really true? The Qt 5 package in EPEL 6 has been updated several times and I don't recall ever seeing an email/announcement/etc.
Were the upgrades incompatible? You have to manually intervene?
Honestly, on the machines I'm using, I installed 5.2 and haven't updated since 5.3 was released because I didn't want to rebuild and re-test all
of
my stuff, but my understanding of the following is that the upgrades are not completely compatible: http://upstream.rosalinux.ru/versions/qt.html
Fwiw, Qt upstream takes both api and abi stability pretty seriously (official public interfaces). If you experience any concrete incompatibilities after upgrading, it's arguably a bug worth fixing.
Yes, but doesn't the change in the name of the .so require a rebuild?
On 19 March 2015 at 08:43, Dave Johansen davejohansen@gmail.com wrote:
On Thu, Mar 19, 2015 at 5:52 AM, Rex Dieter rdieter@math.unl.edu wrote:
Dave Johansen wrote:
On Wed, Mar 18, 2015 at 10:39 AM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 18 Mar 2015 08:00:35 -0700 Dave Johansen davejohansen@gmail.com wrote:
Is that really true? The Qt 5 package in EPEL 6 has been updated several times and I don't recall ever seeing an email/announcement/etc.
Were the upgrades incompatible? You have to manually intervene?
Honestly, on the machines I'm using, I installed 5.2 and haven't updated since 5.3 was released because I didn't want to rebuild and re-test all
of
my stuff, but my understanding of the following is that the upgrades are not completely compatible: http://upstream.rosalinux.ru/versions/qt.html
Fwiw, Qt upstream takes both api and abi stability pretty seriously (official public interfaces). If you experience any concrete incompatibilities after upgrading, it's arguably a bug worth fixing.
Yes, but doesn't the change in the name of the .so require a rebuild?
So we can't speak in circles for a bit longer... what .so are you seeing this happen with. Yes a changed so will break a build so if it is happening then it needs to be looked and dealt with. A library may update itself but not bump the .so
On Thu, Mar 19, 2015 at 9:02 AM, Stephen John Smoogen smooge@gmail.com wrote:
On 19 March 2015 at 08:43, Dave Johansen davejohansen@gmail.com wrote:
On Thu, Mar 19, 2015 at 5:52 AM, Rex Dieter rdieter@math.unl.edu wrote:
Dave Johansen wrote:
On Wed, Mar 18, 2015 at 10:39 AM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 18 Mar 2015 08:00:35 -0700 Dave Johansen davejohansen@gmail.com wrote:
Is that really true? The Qt 5 package in EPEL 6 has been updated several times and I don't recall ever seeing an email/announcement/etc.
Were the upgrades incompatible? You have to manually intervene?
Honestly, on the machines I'm using, I installed 5.2 and haven't
updated
since 5.3 was released because I didn't want to rebuild and re-test
all of
my stuff, but my understanding of the following is that the upgrades
are
not completely compatible: http://upstream.rosalinux.ru/versions/qt.html
Fwiw, Qt upstream takes both api and abi stability pretty seriously (official public interfaces). If you experience any concrete incompatibilities after upgrading, it's arguably a bug worth fixing.
Yes, but doesn't the change in the name of the .so require a rebuild?
So we can't speak in circles for a bit longer... what .so are you seeing this happen with. Yes a changed so will break a build so if it is happening then it needs to be looked and dealt with. A library may update itself but not bump the .so
Sorry, I let this topic go for a while. It appears that the change in the name of the .so didn't not require a rebuild for Qt Creator to continue working, so I guess it's not a problem.
On another note, a bugzilla was just opened to request that Qt Creator be updated inline with Qt 5 ( https://bugzilla.redhat.com/show_bug.cgi?id=1282668 ). I'm going to assume that since it appears that everyone is ok with Qt 5 being updated in EPEL that it's ok for Qt Creator to be updated as well.
Any objections?
epel-devel@lists.fedoraproject.org
-
Dave Johansen -
Kevin Fenzi -
Rex Dieter -
Stephen John Smoogen